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

pythongh-116349: Deprecate `platform.java_ver` function

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

PR is now merged. Thanks everyone, especially Jython team for their quick response and the work they do on Jython3 😃 👍 🎉

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.

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. I would not want to remove this support, unless the Jython developer specifically ask for it.

IronPython has since added the stdlib to their code base directly, and they maintain the IronPython parts of the platform module in their version: https://github.com/IronLanguages/ironpython3/blob/master/Src/StdLib/Lib/platform.py

Jython may go with the same approach, but I would want to hear from the developers, rather than make assumptions.

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. It is being used in the platform module itself for uname() and platform().

And finally, the platform module is intended to be a single source for platform information. Of course, you can reach out to OS or system APIs to get the same information, but that's not the point. When writing cross platform code, you want to be able to access this information in a standard and cross-platform way. That's why we have the platform module.

@malemburg

@malemburg:

I would not want to remove this support, unless the Jython developer specifically ask for it.

Did you see previous comments from Jython developers?

@Stewori (emphasis is mine):

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

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

sobolevn commented on Mar 8, 2024

malemburg commented on Mar 8, 2024

vstinner commented on Mar 8, 2024

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