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:
JsonSerializable, which currently requires a hard dependency on the JSON extension. DateTime already has custom JSON serialization behavior, but is unable to implement JsonSerializable because that interface doesn't always exist.).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.
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 [])))printf() such as %j or %v to PHP to call JSON with the default options.opcache.opt_debug_level debug output is plaintext right now)Voting started 2020-05-13 and ends 2020-05-27.
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?”