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

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

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?

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]

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:

@jeff5

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.

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

❯ 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.

@Stewori

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.

@jeff5

@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 :-(

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.

@jeff5

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).

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

@jeff5

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.

I did, but I also did not get the impression that the purpose of having this support in the platform module was being understood.

Scripts that work on multiple Python platforms may still want to access the Java version in a cross-platform way and deprecation of the support will break this. E.g. uname() will stop returning useful information on Jython. Same for platform().

@sobolevn

Hmm, it would have been nice to ask a review from me as (one of the) platform module authors and maintainer before merging the PR.

By the way, since you have been inactive for the past decade, it didn't occur to me to ping you on the issue. (I'm still mentoring somehow @sobolevn after he got promoted.)

Hmm, it would have been nice to ask a review from me as (one of the) platform module authors and maintainer before merging the PR.

Sorry, I didn't know that you maintain this module!

I think you might want to add yourself to https://github.com/python/cpython/blob/main/.github/CODEOWNERS This way you can be automatically notified on all Lib/platform.py changes :)

It would be easier for new devs to know who to ask as well.

The interface java_ver() uses is the same as most other APIs in the platform module. I don't see how this could be confusing.

I don't quite understand this part. In my mind, it is different, because it uses import java.lang which is not the part of CPython. So, right now it basically does nothing (especailly considering the fact that Jython3 does not exist right now).

It is being used in the platform module itself for uname() and platform().

Yes, this is the second step: to deprecate Java platform, because right now we have sys.implementation which can show Jython or CPython or any other alternative implementation.

Right now java_ver is used there, but it is never doing any useful work, because again, it uses import java.lang construct.

By the way, since you have been inactive for the past decade,..

I have not actively worked on code changes, but have been rather active in discussions, reviews and guiding other devs, including yourself.

I think you might want to add yourself to https://github.com/python/cpython/blob/main/.github/CODEOWNERS This way you can be automatically notified on all Lib/platform.py changes :)

Indeed, I should add myself there. It didn't occur to me that I wasn't listed in that file, since I am listed for the platform module in https://devguide.python.org/core-developers/experts/

I don't quite understand this part. In my mind, it is different, because it uses import java.lang which is not the part of CPython. So, right now it basically does nothing (especailly considering the fact that Jython3 does not exist right now).

Right. Like I said: this code was added for Jython, so would only be used on that platform (or any other Java implementation where Python runs).

The key point is that the platform module defines an API which should continue working on other implementations as well. If Jython decides to vendor its own stdlib, and continue to support this API in their vendored copy, all is fine. OTOH, keeping the definition of the APIs in one place, does help a lot, since people writing cross-platform code can then expect this API to also work on other Python implementations.

Mark, there are many inactive and semi-inactive people listed in the experts file, so it was decided that codeowners would be an add-yourself or occasionally by-request file.

@malemburg

@malemburg , thx for the support and thorough consideration of other implementations' needs :)

As I pointed out earlier, Jython already maintains its own copy of the STL (the python-written part).
In the early days it may have workd with the original CPython stl files, but that hasn't been the case any more for a while (since somewhen before I joined the project).
The shaded stl was once a regularly updated patched copy of the stl but that became infeasible because CPython was changing it too rapidly to keep up with fixing the breakage (just speaking about the 2.x branch). So we ended up updating only cherry-picked parts, e.g. in security-critical cases or if new features could be adopted smoothely.

Jython 3 may start over with a new attempt to use the original STL, but those decisions are still to be made, because the redesigned core is not yet sufficiently mature to tackle STL.

However, the decision to discard os.name=='java' has been made since it was a constant source of trouble. Too many lib maintainers implement a completely dysfunctional fallback (dummy code that just fails fast with some error message "unsupported platform") if os.name is not from a small list of known values, usually not aware of Jython. We had to monkeypatch such barriers away for some crucial libs because the issue propagated through the dependency tree of too many other libs, making crucial stuff (I think even pip) unworkable.

API/interface considerations: I still think it would be good to have some hook in the platform module where users can obtain the information that java_ver used to provide within official Python API. I agree that java_ver is too specific since the platform module generally has specific x_ver functions only for platforms addressed by CPython.

I suggest to consider adding some general version function that can (optionally) be implemented by alternative Python implementations to provide version information of the running vm or middleware if applicable.
Jython would return the tuple similar to java_ver, IronPython can provide some similar info about the .net version and e.g. a browser-based Python could provide the browser name, version, etc. info. Pythons that do not run on a middleware would return an empty tuple or some other well-defined default value for that case.
Name could be vm_ver or middleware_ver or something. Such a hook would be useful independently from Jython 3 availability. Would such a change require a PEP? (Removing java_ver apparently does not.)

@malemburg

@malemburg

keeping the definition of the APIs in one place, does help a lot, since people writing cross-platform code can then expect this API to also work on other Python implementations.

I come from RustPython background, where some extra APIs are also present. For example, RustPython was the first Python implementation to support WASM builds. But, I think that it was intergrated smoothly: there was a clear separation of "this is CPython's regular APIs" and "this is our own RustPython's ones that only exist and make sense here".

I don't think that anybody would accept a rust_ver function to platform.py these days.

The java_ver() API was added specifically for Jython, since at the time it reused the Python stdlib, similiar to how IronPython also reused it

This is once again an argument to deprecate it. java_ver function that returns a version of C#? Very confusing.

or any other Java implementation where Python runs

This is indeed a thing for other platforms, like GraalVM: https://www.graalvm.org/latest/reference-manual/python/Jython/

But, again, it has lots of notes about how unsupported of all this is, quotes:

Most Jython code that uses Java integration will be based on a stable Jython release, and these only come in Python 2.x versions. GraalPy, in contrast, is only targeting Python 3.x. GraalPy does not provide full compatibility with these earlier 2.x versions of Jython. Thus, a significant migration step will have to be taken to migrate all your code to Python 3.
Note that some features of Jython have a negative impact on runtime performance, and are disabled by default. To make migration easier, you can enable some features using a command line option: --python.EmulateJython.
Additionally, importing Java packages as Python modules is only supported under very specific circumstances.

I tried this locally, but GraalVM does not support m2 macs, so I will call it a failure :(

Here's my docker output:

» docker run --rm -it ghcr.io/graalvm/graalpy-community sh   
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
sh-5.1# graalpy
Python 3.10.8 (Mon Jan 08 10:59:17 UTC 2024)
[Graal, GraalVM CE, Java 21.0.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, platform
>>> print(1, os.uname())
1 posix.uname_result(sysname='Linux', nodename='d71df3245931', release='5.15.49-linuxkit', version='#1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022', machine='x86_64')
>>> print(2, platform.uname())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/graalpy-23.1.2/lib/python3.10/collections/__init__.py", line 441, in __repr__
    return self.__class__.__name__ + repr_fmt % self
TypeError: not all arguments converted during string formatting
>>> print(3, platform.platform())
2 3 Linux-5.15.49-linuxkit-x86_64-with-glibc2.16
>>> print(4, platform.java_ver())
4 ('21.0.2', 'GraalVM Community', ('Substrate VM', '21.0.2+13', 'GraalVM Community'), (None, None, None))

So, it can work on GraalVM as well, due to the fact that import java.lang is emulated there.
But, when working with GraalVM they have lots of other support packages (like polyglot). I think adding an extra function there would be more helpful: they can test it at least. Unlike us. Or using a future proposed API instead.

The TypeError above clearly demostrates my point: if we don't test something, we cannot claim to support it in the long run.

Also notice the (None, None, None) part, which does not follow the docs: Values which cannot be determined are set to the defaults given as parameters (which all default to '').

And the last thing: it does not use Java as its system attribute, which would be important later.

All in all, this looks like a source of trouble, rather than a source of truth.
Let's work on a better API instead :)

@Stewori Thanks a lot for the feedback!

I suggest to consider adding some general version function that can (optionally) be implemented by alternative Python implementations to provide version information of the running vm or middleware if applicable.

This is a good idea, I fully support this. It can be just empty in CPython and return None, RustPython can return rustc version, Jython can return javac version, etc.

I think that it would require a PEP 👍

I took a look at PEP 1 and conclude from

Most enhancements and bug fixes don’t need a PEP and can be submitted directly to the Python issue tracker.

that a PEP would likely be an overkill for the proposed enhancement. So, here we go (worth a try).

Related discussion about deprecating 'Java' as platform.system(): https://discuss.python.org/t/lets-deprecate-platform-system-java/48026

The second step after deprecating java_ver 🎉 😄

If this reply seems terse it's because of device limitations not mood. For the same reason I'm unable to read up on the Python API as I'd like.

As long as the stdlib provides a standard way to detect Jython, one can ask everything else via specific API in code guarded by the test.

Accepted os.name is for questions about the file system not the Python implementation.

One needs to discover Jython, not just Java, since as the Graal quote shows, not all implementations allow you to ask the next question (e.g. Java version) the same way. A common way to discover Java and its version might be useful but I can't immediately identify a use case. (What could I do without also knowing it's Jython?)

@jeff5

@jeff5 I assume Jython can still be discovered via sys.implementation as @sobolevn has pointed out (the implementation would have to change though, not relying on java_ver any more). Then, there is also platform.python_implementation which provides the same, apparently.

I don't see why CPython has to maintain "Jython support" outside its test suite.

Nor me. I think that Python only has to maintain support for the possibility of other implementations than CPython. But I think that is satisfied already by being able to ask the implementation, and the places (mainly tests) where the stdlib guards on the outcome.

It is welcome not to have to have to maintain variants of a large module just to exclude a small implementation-specific method. But I expect we can contribute to that.

pythongh-116349: Deprecate `platform.java_ver` function (python#116471)

Navigation Menu

Repository navigation

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

Feature or enhancement

Linked PRs

7 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	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

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

Description

Feature or enhancement

Linked PRs

Activity

AlexWaygood commented on Mar 5, 2024

hugovk commented on Mar 5, 2024

sobolevn commented on Mar 5, 2024

hugovk commented on Mar 5, 2024

AlexWaygood commented on Mar 6, 2024

vstinner commented on Mar 6, 2024

jeff5 commented on Mar 6, 2024

vstinner commented on Mar 7, 2024

sobolevn commented on Mar 7, 2024

Stewori commented on Mar 7, 2024

vstinner commented on Mar 7, 2024

Stewori commented on Mar 7, 2024

7 remaining items

malemburg commented on Mar 8, 2024

vstinner commented on Mar 8, 2024

sobolevn commented on Mar 8, 2024

malemburg commented on Mar 8, 2024

terryjreedy commented on Mar 8, 2024

Stewori commented on Mar 8, 2024

sobolevn commented on Mar 8, 2024

Stewori commented on Mar 8, 2024

sobolevn commented on Mar 9, 2024

jeff5 commented on Mar 9, 2024

Stewori commented on Mar 9, 2024

jeff5 commented on Mar 17, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

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