Let's deprecate `platform.system() == 'Java'`

Core Development
1

Right now there are some left-over of Jython support in stdlib.
Jython2 is long dead, Jython3 is still under development.
See this message from Jython3 devs: Consider deprecating `platform.java_ver` because it is only helpful for Jython · Issue #116349 · python/cpython · GitHub

Problem: having 'Java' as a platform.system() is very strange. It does not represent the reality and is not even needed for the project it was designed for anymore.

Right now there are 0 platforms that I know of that use Java to identify themselfs.
I recently tried GraalPy to see what does it do. Result of platform.uname() on GraalPy:

>>> print(list(platform.uname()))
['Linux', 'd71df3245931', '5.15.49-linuxkit', '#1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022', 'x86_64', 'x86_64']

We also don’t use it inside our code base (some unrelated parts are removed):

» ag '["'\'']java' 
Lib/test/support/__init__.py
521:is_jython = sys.platform.startswith('java')

Lib/test/test_platform.py
167:            ('Jython', 'trunk', '6107'), "java1.5.0_16")
170:                 ('trunk:6107', 'Mar 26 2009'), "java1.5.0_16"),
323:            "'java_ver' is deprecated and slated for removal in Python 3.15"

Lib/platform.py
523:    warnings._deprecated('java_ver', remove=(3, 15))
530:    vendor = _java_getprop('java.vendor', vendor)
531:    release = _java_getprop('java.version', release)
533:    vm_name = _java_getprop('java.vm.name', vm_name)
534:    vm_vendor = _java_getprop('java.vm.vendor', vm_vendor)
535:    vm_release = _java_getprop('java.vm.version', vm_release)
538:    os_arch = _java_getprop('java.os.arch', os_arch)
539:    os_name = _java_getprop('java.os.name', os_name)
540:    os_version = _java_getprop('java.os.version', os_version)
956:        elif system[:4] == 'java':
958:            system = 'Java'
984:    """ Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.
1080:    if sys.platform.startswith('java'):
1274:    elif system == 'Java':

Lib/pydoc_data/topics.py
13761:          'Java implementation) for the accepted range and handling of '

Doc/library/platform.rst
148:   Returns the system/OS name, such as ``'Linux'``, ``'Darwin'``, ``'Java'``,

Doc/library/os.rst
60:   ``'java'``.

My proposal:

  1. Collect feedback about this change here: tag anyone who might be interested
  2. Provide better ways of working with alternative implementations: improve platform.python_implementation and work on Introduce platform.vm_info (or similar) as a replacement for recently deprecated platform.java_ver. · Issue #116504 · python/cpython · GitHub
  3. Deprecate platform.system() == 'Java', platform.platform().system == 'Java', and os.name == 'java' in 3.13
  4. Announce its removal
  5. Remove it in 3.15

Affected code paths:

  1. cpython/Lib/platform.py at c951e25c24910064a4c8b7959e2f0f7c0d4d0a63 · python/cpython · GitHub
  2. cpython/Lib/platform.py at c951e25c24910064a4c8b7959e2f0f7c0d4d0a63 · python/cpython · GitHub

Context:

Please, share your feedback!

4 Likes
2

Both this and the java_ver deprecation talk of adding vm_info as a replacement, possibly to be introduced in 3.13, and to remove the deprecations in 3.15.

PEP 387 says two releases of deprecation is the minimum but also:

  • If the deprecated feature is replaced by a new one, it should generally be removed only after the last Python version without the new feature reaches end of support.

Does that apply here? If so, and if the replacement is added in 3.13, then the removals should be when 3.13 is EOL in October 2029, meaning removal in 3.18.

3

I am not sure that this applies :thinking:
However, we can do both technically.
But, it feels like keeping it for 5 more years is too long.

4

Not really. Python 2 is dead. Jython 2 gets minimal fixes until Jython 3 can replace it, which of course I’d rather be doing.

As discussed on related issues/PRs, we have found treating Jython or Java as a platform, OS or system, on a par with Windows or Linux, to be problematic in practice. Modules ask “is it Windows” and then assume a Unix-like file system. This breaks Jython on Windows.

java_ver alongside win32_ver is part of the same philosophy.

I’m content with the change in Python 3 stdlib because I can see no impact in Jython 2, and I currently think we don’t want it for Jython 3.

platform.implementation and platform.python_version should tell an application it can do Java specific things, then it can ask Java about its version if it needs to.

I have little to say about depreciation speed as I cannot be sure no one is using it. No one running Jython 3 is using it. :slight_smile:

2 Likes
5

Chiming in for GraalPy, back when we got started and we did identify as “java” we ran into endless problems of the sort described above (people checking “is this Windows” and otherwise assuming unix). So we would also be happy to see this go :slight_smile:

7 Likes
6

The “correct” check for path format would be os.name or type(pathlib.Path),[1] but of course we can’t do anything about the vast quantity of code that doesn’t use these.

I would like to be able to determine this from the sys module though, so perhaps sys.implementation is the best place. In general, information that is available at compile time should end up in sys, rather than platform.

  1. Or even better, don’t test this type and just use Path/PurePath. ↩︎