PHP RFC: Always available JSON extension

• Version: 0.3
• Date: 2020-04-29
• Author: Tyson Andre tandre@php.net
• Status: Implemented
• Target version: PHP 8.0
• Implementation: https://github.com/php/php-src/pull/5495
• First Published at: https://wiki.php.net/rfc/always_enable_json

Currently, it's possible to disable the json extension with ./configure --disable-json. However, JSON is extremely useful to have because it's widely used for many use cases (web sites, logging output, and as a data format that can be used to share data with many applications and programming languages), so it would be useful for PHP maintainers and users to guarantee that json is always enabled.

Examples of where this would be useful:

• Allowing internal classes to implement JsonSerializable, which currently requires a hard dependency on the JSON extension.
  (e.g. DateTime already has custom JSON serialization behavior, but is unable to implement JsonSerializable because that interface doesn't always exist.)

• Allowing PHP users to publish single-file scripts that use json_encode and json_decode and don't require polyfills or less readable var_export output.
  (polyfills are less efficient and may have issues with recursive data structures)

• Letting php-src's own modules, tools and .phpt test cases start using JSON if it's a good choice for representing a value. (same for PECLs)

The reasons for allowing JSON to be disabled appear to be historical, and no longer apply. https://wiki.php.net/rfc/jsond mentions that:

The current Json Parser (for PHP 5) in the json extension does not have a free license
which is a problem for many Linux distros.
This has been referenced at Bug #63520.
That results in not packaging json extension in the many Linux distributions.

Starting in php 7.0 with the switch to jsond, it looks like licensing is no longer an issue.

Extensions have been made always-on by default. For example, e.g. https://wiki.php.net/rfc/permanent_hash_ext did this for the hash extension.

Make it impossible to disable the JSON extension through configuration or build options. Require that JSON be built statically instead of as a shared library.

Build configurations that contain --enable-json or --disable-json will have to be updated, as the argument will cease to exist.

Because JSON would always be built statically to guarantee it can be used, package maintainers for OSes such as Fedora would need to create stub packages for the php-json package, or to remove the package in php 8 (or mark it as provided by the core php package).

Some other installations already use JSON statically by default (e.g. the zips published on windows.php.net, or the default when building php from source)

8.0

PECL extensions can now always rely on the json extension to be available and use its API and PHP interfaces such as JsonSerializable.

Minimal builds of PHP will slightly grow in size.

Any already existing userland code will continue to work as before. Userland code may remove calls to extension_loaded('json') as they will now always return true.

The json extension does not have any external dependencies, so this will not add any more dependencies for a minimal build of PHP.

• Make internal classes that already have custom JSON serialization behavior (ZEND_PROP_PURPOSE_JSON in property array getters) start implementing JsonSerializable, and add implementations of jsonSerialize() returning arrays (e.g. for DateTime, DateTimeZone, DateTimeImmutable, DateTimeZone. (Changing ArrayObject wouldn't make sense, because php users rely on php serializing those with object syntax (e.g. {} instead of [])))

• Start using JSON in more places within PHP's own functions. For example, adding additional conversion specifiers for printf() such as %j or %v to PHP to call JSON with the default options.

• Add alternative options to use JSON to dump debug output in an easily machine-readable form. (e.g. opcache.opt_debug_level debug output is plaintext right now)

Voting started 2020-05-13 and ends 2020-05-27.

Make the JSON extension impossible to disable
Real name	Yes	No
alcaeus (alcaeus)
asgrim (asgrim)
ashnazg (ashnazg)
beberlei (beberlei)
bmajdak (bmajdak)
bwoebi (bwoebi)
carusogabriel (carusogabriel)
chregu (chregu)
cmb (cmb)
colinodell (colinodell)
dams (dams)
derick (derick)
dmitry (dmitry)
dragoonis (dragoonis)
duncan3dc (duncan3dc)
duodraco (duodraco)
ekin (ekin)
galvao (galvao)
girgias (girgias)
guilhermeblanco (guilhermeblanco)
jasny (jasny)
jbnahan (jbnahan)
jhdxr (jhdxr)
kalle (kalle)
kguest (kguest)
kocsismate (kocsismate)
lcobucci (lcobucci)
levim (levim)
lstrojny (lstrojny)
marandall (marandall)
marcio (marcio)
mariano (mariano)
mfonda (mfonda)
nicolasgrekas (nicolasgrekas)
nikic (nikic)
ocramius (ocramius)
patrickallaert (patrickallaert)
petk (petk)
pmjones (pmjones)
pollita (pollita)
ramsey (ramsey)
reywob (reywob)
rtheunissen (rtheunissen)
ruudboon (ruudboon)
salathe (salathe)
santiagolizardo (santiagolizardo)
sebastian (sebastian)
sergey (sergey)
svpernova09 (svpernova09)
tandre (tandre)
till (till)
trowski (trowski)
villfa (villfa)
wyrihaximus (wyrihaximus)
yunosh (yunosh)
zimt (zimt)
Final result:	56	0
This poll has been closed.

0.3: Keep the HAVE_JSON constant in config.m4, to avoid a backwards compatibility break.

https://externals.io/message/109783 “Moving json extension to core?”

https://wiki.php.net/rfc/jsond

https://wiki.php.net/rfc/permanent_hash_ext