PHP RFC: Always available JSON extension
Currently, it's possible to disable the json extension with
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.
DateTimealready has custom JSON serialization behavior, but is unable to implement
JsonSerializablebecause 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
.phpttest 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
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.
Backward Incompatible Changes
Build configurations that contain
--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
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)
Proposed PHP Version(s)
To SAPIs and Existing Extensions
PECL extensions can now always rely on the
json extension to be available and use its API and PHP interfaces such as
Minimal builds of PHP will slightly grow in size.
Unaffected PHP Functionality
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
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_JSONin property array getters) start implementing
JsonSerializable, and add implementations of jsonSerialize() returning arrays (e.g. for
ArrayObjectwouldn't make sense, because php users rely on php serializing those with object syntax (e.g.
- Start using JSON in more places within PHP's own functions. For example, adding additional conversion specifiers for
%vto 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_leveldebug 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.