Consider deprecating `platform.java_ver` because it is only helpful for Jython

[sobolevn]

Feature or enhancement

What do you think about deprecating platform.java_ver? It is never used on CPython, it is a helper for Jython only, which is basically stuck on 2.7 for the last 10 years.

I think that we should deprecate and remove such compat parts with tools that no longer exist. In the future Jython can add its own implementation to its own stdlib, if ever.

cpython/Lib/platform.py

Lines 516 to 547 in a29998a

	def java_ver(release='', vendor='', vminfo=('', '', ''), osinfo=('', '', '')):
	""" Version interface for Jython.
	Returns a tuple (release, vendor, vminfo, osinfo) with vminfo being
	a tuple (vm_name, vm_release, vm_vendor) and osinfo being a
	tuple (os_name, os_version, os_arch).
	Values which cannot be determined are set to the defaults
	given as parameters (which all default to '').
	"""
	# Import the needed APIs
	try:
	import java.lang
	except ImportError:
	return release, vendor, vminfo, osinfo
	vendor = _java_getprop('java.vendor', vendor)
	release = _java_getprop('java.version', release)
	vm_name, vm_release, vm_vendor = vminfo
	vm_name = _java_getprop('java.vm.name', vm_name)
	vm_vendor = _java_getprop('java.vm.vendor', vm_vendor)
	vm_release = _java_getprop('java.vm.version', vm_release)
	vminfo = vm_name, vm_release, vm_vendor
	os_name, os_version, os_arch = osinfo
	os_arch = _java_getprop('java.os.arch', os_arch)
	os_name = _java_getprop('java.os.name', os_name)
	os_version = _java_getprop('java.os.version', os_version)
	osinfo = os_name, os_version, os_arch
	return release, vendor, vminfo, osinfo

I propose to depreacate / remove it in 3.13 / 3.15

Linked PRs

• gh-116349: Deprecate platform.java_ver function #116471

[AlexWaygood]

Jython is still maintained. Is there a chance that if they do add Python 3 compatibility one day, they'll ask for this function to be added back? It doesn't look hugely out of place with the other functions in the platform module, and we've accepted lots of PRs in recent years so that Python can run with fewer patches on platforms such as WASI, iOS and Android. On the Jython project's README, it says:

watch this space for a 3.x version

On Discord, you mentioned that this function might be confusing for users. Do we have evidence of users being confused by it?

[hugovk]

Some but not much use in the top 8k PyPI projects:

❯ python3 ~/github/misc/cpython/search_pypi_top.py -q . "\bjava_ver\b"
Found existing alias for "python3". You should use: "p3"
./clvm_rs-0.6.0.tar.gz: clvm_rs-0.6.0/venv/lib/python3.7/site-packages/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./appdirs-1.4.4.tar.gz: appdirs-1.4.4/appdirs.py: os_name = platform.java_ver()[3][0]
./jc-1.25.1.tar.gz: jc-1.25.1/jc/appdirs.py: os_name = platform.java_ver()[3][0]
./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/2/platform.pyi: def java_ver(release=..., vendor=..., vminfo=..., osinfo=...): ...
./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/3/platform.pyi: def java_ver(
./magicgui-0.8.1.tar.gz: magicgui-0.8.1/src/magicgui/_util.py: os_name = platform.java_ver()[3][0]
./mypy-1.8.0.tar.gz: mypy-1.8.0/mypy/typeshed/stdlib/platform.pyi: def java_ver(
./pex-2.2.1.tar.gz: pex-2.2.1/pex/vendor/_vendored/pip/pip/_vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./pex-2.2.1.tar.gz: pex-2.2.1/pex/vendor/_vendored/setuptools/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./Nuitka-2.0.3.tar.gz: Nuitka-2.0.3/nuitka/build/inline_copy/appdirs/appdirs.py: os_name = platform.java_ver()[3][0]
./pyinstrument-4.6.2.tar.gz: pyinstrument-4.6.2/pyinstrument/vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/prometheus_client/platform_collector.py: java_version, _, vminfo, osinfo = self._platform.java_ver()
./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/tests/test_platform_collector.py: def java_ver(self):
./numba-0.59.0.tar.gz: numba-0.59.0/numba/misc/appdirs.py: os_name = platform.java_ver()[3][0]
./pyLDAvis-3.4.1.tar.gz: pyLDAvis-3.4.1/pyLDAvis/lib/python3.11/site-packages/pkg_resources/_vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./Pint-0.23.tar.gz: Pint-0.23/pint/_vendor/appdirs.py: os_name = platform.java_ver()[3][0]
./pymongo-4.6.2.tar.gz: pymongo-4.6.2/pymongo/pool.py: _name, _ver, _arch = platform.java_ver()[-1]
./pytype-2024.2.13.tar.gz: pytype-2024.2.13/pytype/typeshed/stdlib/platform.pyi: def java_ver(
./pyre-check-0.9.19.tar.gz: pyre-check-0.9.19/typeshed/stdlib/platform.pyi: def java_ver(
./seaborn-0.13.2.tar.gz: seaborn-0.13.2/seaborn/external/appdirs.py: os_name = platform.java_ver()[3][0]
./utilmy-0.1.17078128.tar.gz: utilmy-0.1.17078128/utilmy/configs/util_dirs.py: os_name = platform.java_ver()[3][0]
./typeshed_client-2.4.0.tar.gz: typeshed_client-2.4.0/typeshed_client/typeshed/platform.pyi: def java_ver(

Time: 0:00:42.010103
Found 22 matching lines in 19 projects

11/22 are appdirs or vendored appdirs code. Its successor platformdirs has removed this code.

• Hard to know how much depends on this code.

7/22 are type stubs or similar.

The remaining 4 are:

./magicgui-0.8.1.tar.gz: magicgui-0.8.1/src/magicgui/_util.py: os_name = platform.java_ver()[3][0]
./prometheus_client-0.20.0.tar.gz: prometheus_client-0.20.0/prometheus_client/platform_collector.py: java_version, _, vminfo, osinfo = self._platform.java_ver()
./pymongo-4.6.2.tar.gz: pymongo-4.6.2/pymongo/pool.py: _name, _ver, _arch = platform.java_ver()[-1]
./utilmy-0.1.17078128.tar.gz: utilmy-0.1.17078128/utilmy/configs/util_dirs.py: os_name = platform.java_ver()[3][0]

[sobolevn]

we've accepted lots of PRs in recent years so that Python can run with fewer patches on platforms such as WASI, iOS and Android

This is different, java_ver is not about Java platform or any other platform that we run CPython on, it is specific for another language implementation - Jython.

watch this space for a 3.x version

I hope that this release will happen! Having Python in Java's ecosystem is great.
But, there are other implementations that do share our stdlib. Two comments:

• they don't have any special cases in our stdlib
• they have to share this property as well, example: https://github.com/RustPython/RustPython/blob/d0c827ed3837ca8dfde07063f8591878fa06bd57/Lib/platform.py#L466

We don't even document java to be a part of sys.platform:

.. c:function:: const char* Py_GetPlatform()

   .. index:: single: platform (in module sys)

   Return the platform identifier for the current platform.  On Unix, this is
   formed from the "official" name of the operating system, converted to lower
   case, followed by the major revision number; e.g., for Solaris 2.x, which is
   also known as SunOS 5.x, the value is ``'sunos5'``.  On macOS, it is
   ``'darwin'``.  On Windows, it is ``'win'``.  The returned string points into
   static storage; the caller should not modify its value.  The value is available
   to Python code as ``sys.platform``.

Do we have evidence of users being confused by it?

Me 😆

I can also find some code that looks suspicious to me in some rather popular projects:

• https://github.com/pytorch/pytorch/blob/de8af28083623fccd65751189da1f39ae867a92b/torch/_appdirs.py#L58-L72
• https://github.com/mongodb/mongo-python-driver/blob/af2d56c5b508003d564c25433613200583cb15d7/pymongo/pool.py#L222-L232

[hugovk]

See also:

• Deprecate / remove os.name=java #90613
• Which Jython version works with Python 3.9 jython/jython#312 for recent discussion about 3.x support in Jython (summary: no timeline)

And ping @jeff5 from Jython.

[AlexWaygood]

I consider my initial concerns to have been addressed, FWIW — thanks!

[vstinner]

❯ python3 ~/github/misc/cpython/search_pypi_top.py -q . "\bjava_ver\b"
...
./jedi-0.19.1.tar.gz: jedi-0.19.1/jedi/third_party/typeshed/stdlib/3/platform.pyi: def java_ver(

Usually, I remove manually .pyi files from a code search. Maybe I should modify my tool to ignore them by default? Removing the function is not going to "break" type annotations of PYI files.

[jeff5]

Sorry, I'm without access to a decent computer that would let me make fully informed contribution to the discussion. The idea that Java is a sort of os.name has been a source of problems. It should be possible within the platform module to determine the implementation name (PyPy etc.). Then knowing it is Jython, to ask the version of Java through Java API (I think). Ping @Stewori to check my logic.

[vstinner]

@jeff5: The question here is only if removing "Java/Jython code" from CPython is causing any trouble to Jython. Obviously, Jython is free to patch the platform module, os.name, etc. to behave differently than CPython. It would be very surprised if Jython has no change on the stdlib :-)

I don't see why CPython has to maintain "Jython support" outside its test suite. In the test suite, we should try to have the same code on all Python implementations. But it's rare to get freeback from Jython or PyPy about the test suite :-(

[sobolevn]

One more detail. java_ver uses this API:

def _java_getprop(name, default):

    from java.lang import System
    try:
        value = System.getProperty(name)
        if value is None:
            return default
        return value
    except AttributeError:
        return default

which is Jython's internal API, I guess. It is clearly untested in CPython and can be changed by a 3rd party at any moment.

[Stewori]

I think @jeff5 's latest comment summarizes it well.
It should be clarified that java_ver is not to support Jython or needed by Jython (it uses a shaded STL) but is a service to libraries/applications/users to access that information within official Python API. AFAIK it was introduced as part of a roadmap to an implementation-independent Python STL, which we now know has been failed to achieve. IMO, a more generic name vm_ver or so would have been a better choice since it could have also hosted e.g. .net version for IronPython. Such a generic name would likely not be disputed for deprecation now.

The "java" os name indeed caused more trouble to Jython than benefit. Libraries that check os.name in order to implement platform-specific behavior most usually have a dysfunctional fallback for that case, even though often enough their behavior for the original platform name would have actually worked well also in Jython case. We had to apply some serious trickery to work around that issue, but we hesitated to change that spec since it is part of the reference STL. The plan was to apply that change with the major version 3.

So, from Jython perspective, I would say these values are already deprecated in the 3.x-branch (actually plainly removed).
So the deprecation attempt is actually overdue (retrospectively speaking, should have been part of the entire 3.x-STL, if that information had been available earlier).

[vstinner]

I'm curious, what's the progress on Jython port to Python 3?

[Stewori]

The thing is, it is not just a port, but a redesign (of the core, at least) to incorporate lessons learned, address technical debt and take advantage of new Java features. A major version increment is a unique opportunity for such a breaking redesign. Jython 3 has to deal not only with Python progress, but also with Java progress. At the same time, some continuation with the Jython 2 sources shall be kept to reuse code where feasible and to retain the project's history and attributions. @jeff5 is doing a fantastic job with the redesign, but progress is naturally slow due to limited resources and difficulty of the challenge. See https://www.jython.org/jython-3-mvp, https://www.jython.org/jython-3-roadmap and https://the-very-slow-jython-project.readthedocs.io/en/latest/ for details or get in touch on the jython-dev mailing list.