Modify

Opened 3 years ago

Closed 16 months ago

Last modified 2 months ago

#11390 closed enhancement (fixed)

Switch to Java 8

Reported by: Don-vip Owned by: Don-vip
Priority: major Milestone: 16.07
Component: Core Version:
Keywords: java8 Cc: stoecker, bastiK, simon04, skyper, Klumbumbus

Description (last modified by Don-vip)

This ticket is the successor of #8465 :)

Like for Java 7 two years ago, Oracle released their final versions of Java 7 (7u79 and 7u80), and the same auto-update feature for Windows and OSX users. We already have a significant majority of users who run JOSM with Java 8:

All users:

Java Main Version --> 6 (598,  4.3%) 7 (5128, 37.3%) 8 (8009, 58.2%) 9 (22,  0.2%)

Recent versions (>=7001):

Java Main Version --> 6 (37,  0.3%) 7 (4370, 35.7%) 8 (7818, 63.8%) 9 (22,  0.2%)
OS:  FreeBSD (2,  0.0%) Linux (2749, 22.6%) Mac (911,  7.5%) OpenBSD (1,  0.0%) SunOS (3,  0.0%) Windows (8500, 69.9%)

Java 7 users:

OS:  FreeBSD (2,  0.0%) Linux (2394, 49.5%) Mac (129,  2.7%) OpenBSD (3,  0.1%) SunOS (3,  0.1%) Windows (2310, 47.7%)

Java 8 users:

OS:  Linux (567,  7.1%) Mac (786,  9.9%) Windows (6613, 83.0%)

Linux is clearly behind. Main distributions of Java 7 users are:

O        251 ( 5.2%) Linux Debian GNU/Linux 8.0 (jessie)
O        157 ( 3.2%) Linux Mint 17.1 Rebecca
O        102 ( 2.1%) Linux Ubuntu 14.04.1 LTS
O        809 (16.7%) Linux Ubuntu 14.04.2 LTS
O        154 ( 3.2%) Linux Ubuntu 14.10
O        222 ( 4.6%) Linux Ubuntu 15.04

Java 8 is not yet available in Debian Jessie or Ubuntu LTS, but it will be released soon in Jessie backports then Trusty backports.

The transition will be easier than Java 7:

  • Java 8 is available and stable on all platforms
  • There's no need this time to build a new package for OSX
  • JOSM is built and tested daily with Java 8 for quite some time. It works fine and there's even a large performance gain in rendering: see Java 7 results vs Java 8 results

So, what's new?

Other useful links:

Proposed plan:

  1. Restore informative message "JOSM will soon no longer work with this version of Java..." on server side
  2. Ask OSX and Windows users to switch (revert/update this and this): done in r8923
  3. Wait for Debian Jessie backport: done
  4. Wait for Ubuntu Trusty backport It seems it will never happen
  5. Ask Linux users to switch (revert/update of this): done in r10166
  6. Switch about one month after that

Attachments (4)

java8.patch (73.6 KB) - added by Don-vip 18 months ago.
Java 8 migration patch
java8_depends.patch (73.7 KB) - added by sebastic 18 months ago.
Java 8 migration patch keeping OpenJDK dependency for Ubuntu package
java8-utils.patch (7.4 KB) - added by simon04 16 months ago.
java8-utils-v2.patch (9.1 KB) - added by simon04 16 months ago.

Download all attachments as: .zip

Change History (168)

comment:1 Changed 3 years ago by stoecker

I think it's too early now in my eyes. But we can already think about a time-frame. A possible target could be that first version 2016 is Java 8? Maybe start Windows nagging in summer and Linux in autumn. That sounds like enough time.

For the Linux version I hope you remember the openSUSE Java 8 issues until few weeks ago and our resulting suggestion to use Java 7 instead.

Regarding the need for a switch - Is there anything where we say: "We want this" like it was for Java 7, which had a lot of useful new stuff?

comment:2 Changed 3 years ago by bastiK

I agree that it is too early to nag if there is no viable option for a Java upgrade.

Interesting new stuff:

  • Parallel sort could be used in StyledMapRenderer to speed up painting a little.
  • New JavaScript engine "Nashorn":
    With the "Rhino" engine in Java 7, I don't feel comfortable putting scripts on the wiki like we do for map styles and presets and allow unmoderated changes. It would be too easy to add malicious code which gains access to the user's file system and basically takes over the computer.
    In contrast, the new engine has a switch to turn off Java classes in JavaScript code entirely, so it looks as if it can be sandboxed and made air-tight.
    This means we can think of new uses of JavaScript in other parts of JOSM (currently used in CustomConfigurator for automated preference fixes).

comment:3 in reply to:  1 Changed 3 years ago by Don-vip

Description: modified (diff)

Replying to stoecker:

For the Linux version I hope you remember the openSUSE Java 8 issues until few weeks ago and our resulting suggestion to use Java 7 instead.

I totally forgot that, but I see the bug is fixed, so that's not a problem anymore.

Regarding the need for a switch - Is there anything where we say: "We want this" like it was for Java 7, which had a lot of useful new stuff?

Java 8 is a major release, there are a lot of good new stuff we can use:

  • Lambdas, method references, default and static interface methods: powerful new syntaxes allowing to write more compact code
  • Stream API: more compact code for iterations
  • Paraller sorting: improve performance
  • Predicate, Function: may replace/simplify our own Predicate and Function classes
  • Base64: may replace our own Base64 class
  • new Date/Time API: simplify all date-related stuff. May replace our DateUtils class
  • String joining: may replace Utils.join()
  • Optional parameters: may simplify null-handling
  • HTTP URL Permissions: may be useful to enforce imagery blacklist

Java 8 also contains:

  • new javascript engine for better performance
  • lot of security/crypto enhancements
  • Unicode/CLDR improvements

I'm sure there are even more stuff I did not see yet :)

comment:4 Changed 3 years ago by stoecker

Last points ... don't argue with stuff which a user with Java 8 gets also in case we don't switch our code base. That's unfair :-)

comment:5 Changed 3 years ago by mdk

I install josm and josm-latest from repository http://josm.openstreetmap.de/apt/
The dependencies are:
Depends: openjdk-7-jre
So even if I have installed Java8, always Java7 is used. That may be the reason, why Linux normally use Java 7.

Isn't there a possibility to define a dependency like "use any Java >=1.7"?
I found something like
Depends: java-runtime-headless (>= 1.7),
but I couldn’t test it.

Edit: If we need an complete JRE, perhaps something like
Depends: java-runtime (>= 7)
would work.

Last edited 3 years ago by mdk (previous) (diff)

comment:6 Changed 3 years ago by Don-vip

In 8317/josm:

see #11390 - accept openjdk-8-jre in Debian control file, prefer Java 8 runtime over Java 7 in launch script

comment:7 Changed 3 years ago by mdk

I updated to 8319, but it still uses Java Version 1.7.0_79.
Also the Package dependency is still openjdk-7-jre, even after reinstalling JOSM. Has ​the package definition really changed on http://josm.openstreetmap.de/apt/?

The start scripts /usr/bin/josm and /usr/bin/josm-latest have in line 14 a list of possible Java installations. In this list openjdk-8 (and oracle-9) are missing. So add:
/usr/lib/jvm/java-8-openjdk/bin/java /usr/lib/jvm/java-8-openjdk-$ARCH/bin/java /usr/lib/jvm/java-9-oracle/bin/java

But as fare as I understand /etc/alternatives/java is always preferred. As long as we follow the preferred Java version, we have to wait until Debian or other distributions will change this default to openjdk-8.

comment:8 Changed 3 years ago by bastiK

Please try the next version, an update on the server was missing.

comment:9 Changed 3 years ago by Don-vip

I wasn't sure if a commit was enough :) concerning java 9 I won't add it yet because it's way too early for that :)

comment:10 Changed 3 years ago by stoecker

Shouldn't it at least start when java 9 is there only? The openSUSE version only requests a minimum version, no max.

comment:11 Changed 3 years ago by Don-vip

The point is Java 9 is still in very early development phase and not expected until 2016 at best. We can wait a few months before supporting it officially :)

comment:12 in reply to:  7 ; Changed 3 years ago by Don-vip

Replying to mdk:

I updated to 8319, but it still uses Java Version 1.7.0_79.

Can you please try again now? I have rebuilt a new version (r8327).

comment:13 in reply to:  10 Changed 3 years ago by Don-vip

Replying to stoecker:

The openSUSE version only requests a minimum version, no max.

By the way OpenSUSE is not really the example to follow regarding how they messed up their packaging of Java 8 and the time they needed to fix it.

comment:14 in reply to:  12 Changed 3 years ago by mdk

Replying to Don-vip:

Can you please try again now? I have rebuilt a new version (r8327).

On a default Ubuntu 15.04 installation r8327 is still running with Java Version 1.7.0_79
Package is now requiring openjdk-7-jre | openjdk-8-jre (fixed)
/usr/bin/josm-latest now also checks for java-8-openjdk and java-8-openjdk-$ARCH (fixed)

But as long as I would not change the default Java with sudo update-alternatives --config java from

* 0            /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java   1071      automatischer Modus

to

  4            /usr/lib/jvm/java-8-openjdk-i386/jre/bin/java   1069      manueller Modus

I have to wait for Ubuntu to change the default or manually override.
When I change the default Java to option 4, JOSM runs with Java Version 1.8.0_45-internal.

As Java 7 is not longer supported with bug fixes, I hope the Linux distributions will change the default Java version recently.

But for all people which not want to tweak their installation, we have to wait ...

Last edited 3 years ago by mdk (previous) (diff)

comment:15 Changed 3 years ago by Don-vip

Ok thanks. Java 7 on Linux should still receive security updates backported from openjdk8.

comment:16 Changed 3 years ago by Don-vip

In 8333/josm:

see #11390 - prefer Java 8 runtime over Java 7 in launch script

comment:17 Changed 3 years ago by mdk

r8333: Now JOSM uses java 8 even if Debian alternatives is configured to openjdk-7.
I think this overruling is ok.

So the users of repository ​http://josm.openstreetmap.de/apt/ will now switch to openjdk-8, if installed.

Does anybody has influence on JOSM packages for Debian, Ubuntu or other distributions? They often use quite old versions.

Actual supported Ubuntu versions are:

  • 12.04 (LTS): JOSM 4878
  • 14.04 (LTS): JOSM 6502
  • 14.10: JOSM 6502
  • 15.04: JOSM 7995
  • 15.10 (planed): JOSM 7995

Debian uses:

  • squeeze (oldoldstable): JOSM 3376
  • wheezy (oldstable): JOSM 5267
  • jessie (stable): JOSM 7643
  • stretch (testing): JOSM 7643
  • sid (unstable): JOSM 7643
  • experimental (rc-buggy): JOSM 8159

Should we invite Ubuntu users (which use JOSM from universe) to add repository on openstreetmap.de instead of some manually update or installation?

Last edited 3 years ago by mdk (previous) (diff)

comment:18 in reply to:  17 Changed 3 years ago by Don-vip

Replying to mdk:

r8333: Now JOSM uses java 8 even if Debian alternatives is configured to openjdk-7.
I think this overruling is ok.

I think too.

Does anybody has influence on JOSM packages for Debian, Ubuntu or other distributions? They often use quite old versions.

There is no backport for old distribs but Sebastian does a great job to keep up to date the Debian package in the experimental branch, which can be reused by Ubuntu.

Should we invite Ubuntu users (which use JOSM from universe) to add repository on openstreetmap.de instead of some manually update or installation?

I don't think this is needed. There's still time to see if Ubuntu 15.10 switches to Java 8 by default. I hope Wheezy, Jessie and Trusty will have openjdk8 backported before that.

comment:19 Changed 2 years ago by Don-vip

Description: modified (diff)

Status update:

Good news is that it includes OpenJFX. So maybe we could try to give a look to JavaFX as well.

comment:20 Changed 2 years ago by Don-vip

For those interested, Oracle offers a free 3-week MOOC on Java 8 / Lambdas:

https://apexapps.oracle.com/pls/apex/f?p=44785:145:0::::P145_EVENT_ID,P145_PREV_PAGE:4887,143

comment:21 Changed 2 years ago by shinigami

So, is it time to move to jdk8?:)

comment:22 Changed 2 years ago by bastiK

Currently 62% of all JOSM users are running with Java 8.

I feel that the PPA for Ubuntu 14.04 is not really a great solution, but would be a measure of last resort. Personally, I'd rather install the Oracle package.

The conservative approach is to wait until openjdk8 is included in the official backport repository of Ubuntu 14.04 ( ticket) or until the next LTS version is released in April 2006 (whatever comes first). But I'm not sure you guys what to wait that long. ;)

comment:23 Changed 2 years ago by Don-vip

Agreed with bastiK, I don't want to force Ubuntu users to install a PPA. And I'd like to have some progress from Oracle on these bugs before switching:

comment:24 Changed 2 years ago by Don-vip

Milestone: 16.04

Java 8 is now used by 65% of all JOSM users.

It's however very unlikely to see Java 8 become available for Ubuntu 14.04 LTS. The ticket is starving for more than a year, clearly Canonical doesn't give a shit about Java.

So I target the code migration to April 2016, in coincidence with the availability of the next LTS.

To ensure a smooth migration, I'll however implement the migration suggestion for Windows and OSX users, like previously for Java 7. They really need to switch anyway because Oracle does not provide binaries anymore since April 2015, so they do not receive security fixes.

I have joined the Quality Outreach OpenJDK project and will use JavaBugs as a coordinating wiki page with Oracle. I hope it will have a benefic impact on the resolution of our bug reports.

comment:25 Changed 2 years ago by Don-vip

In 8923/josm:

see #11390 - invite Windows and OSX users to update to Java 8

comment:26 in reply to:  25 Changed 2 years ago by rickmastfan67

Replying to Don-vip:

In 8923/josm:

see #11390 - invite Windows and OSX users to update to Java 8

Is there any way to add an 'OK' button so that we can select an option in the dialog without having to hit the 'Update Java' button and have our browser open up to Java's website?

comment:27 Changed 2 years ago by Don-vip

of course :)

comment:28 Changed 2 years ago by Don-vip

In 8934/josm:

see #11390 - rework update dialog

comment:29 Changed 2 years ago by mdk

Is it correct, that actually JSOM starts by default again with Java 7 inseat of 8? I testet it with actually josm-latest (9062) and the stable version (9060).

comment:30 Changed 2 years ago by Don-vip

No. Did you set a JAVA_HOME? Can you please look if a path on your system would be missing from r8970?

comment:31 in reply to:  30 Changed 2 years ago by mdk

I din't change anything at JAVA_HOME. I just update Java 7 and JOSM on my Ubuntu system.

But I try to analyse the start script and I don't understad it compleatly:
ALTERNATIVE_JDK contains /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
and JAVA_CMDS contains:

/bin/java 
/usr/lib/jvm/java-8-openjdk/bin/java 
/usr/lib/jvm/java-8-openjdk-i386/bin/java 
/usr/lib/jvm/java-8-oracle/bin/java 
/usr/lib/jvm/java-7-openjdk/bin/java 
/usr/lib/jvm/java-7-openjdk-i386/bin/java 
/usr/lib/jvm/java-7-oracle/bin/java 
/usr/lib/jvm/java-9-openjdk/bin/java 
/usr/lib/jvm/java-9-openjdk-i386/bin/java 
/usr/lib/jvm/java-9-oracle/bin/java

After the first loop (with if [ "z$ALTERNATIVE_JDK" = "z`readlink -n -f $jcmd`" ] && [ -z "${JAVACMD}" ]; then}) JAVACMD contains /usr/lib/jvm/java-7-openjdk-i386/bin/java, so the second loop is skipt and ends with
Using /usr/lib/jvm/java-7-openjdk-i386/bin/java to execute josm-latest.

But also /usr/lib/jvm/java-8-openjdk-i386/bin/java exists in my system but is not choosen (has to do with ALTERNATIVE_JDK?).

When I remove the first loop, the second one (with if [ -x "$jcmd" -a -z "${JAVACMD}" ]; then) returns the correct
Using /usr/lib/jvm/java-8-openjdk-i386/bin/java to execute josm-latest.

comment:32 Changed 2 years ago by Don-vip

In 9066/josm:

see #11390 - drop support for ALTERNATIVE_JDK in Debian startup scripts

comment:33 Changed 2 years ago by Don-vip

Description: modified (diff)

comment:34 Changed 2 years ago by bastiK

Do we really want to ignore the user's update-alternatives configuration? This is the standard way to set the default Java version system-wide (i.e. what path is selected if you just type java).

@mdk: You can run update-alternatives --config java on the command line to select the Java version.

comment:35 in reply to:  34 Changed 2 years ago by mdk

Replying to bastiK:

Do we really want to ignore the user's update-alternatives configuration? This is the standard way to set the default Java version system-wide (i.e. what path is selected if you just type java).

@mdk: You can run update-alternatives --config java on the command line to select the Java version.

I know (see discussion above).

To summarise: The goal is switching to Java 8. JOSM works fine with Java 8. We don't want to wait until Java 8 is default (ALTERNATIVE_JDK) in Debian, Ubuntu, Mint, etc. We don't want to treat every of these users to change the default (running update-alternatives --config java).

Conclusion: (see comment 18) The JOSM start script should ignores ALTERNATIVE_JDK and search for the first existing of Java 8, Java 7, Java 9.

Since r8333 the start script prefers Java 8, if existing. But since refectoring of the script in r8970 Java 7 is preffered again. Now since r9066 Java 8 is preferred again.

comment:36 Changed 2 years ago by stoecker

Description: modified (diff)

comment:37 Changed 2 years ago by Don-vip

Users can still override the default behaviour by setting JAVA_HOME or JAVACMD environment variables.

comment:38 Changed 2 years ago by bastiK

All right then...

comment:39 Changed 2 years ago by Don-vip

Description: modified (diff)

comment:40 Changed 2 years ago by mdk

I'm not sure what happend, but I noticed, that both, josm and josm-latest, still using Java 7. Both start scripts still contain the part with ALTERNATIVE_JDK. I use the http://josm.openstreetmap.de/apt repository. Even reinstalling didn't change the script.

comment:41 Changed 2 years ago by mdk

OK, since r9146 JOSM uses 1.8 by default.

comment:42 in reply to:  34 ; Changed 23 months ago by sebastic

Replying to bastiK:

Do we really want to ignore the user's update-alternatives configuration? This is the standard way to set the default Java version system-wide (i.e. what path is selected if you just type java).

Ignoring the configured default JDK when JOSM still supports it is not a good thing.

@mdk: You can run update-alternatives --config java on the command line to select the Java version.

Changing the default JDK (all executables, not only /usr/bin/java) should be done with update-java-alternatives from the java-common package, e.g. for OpenJDK 8:

update-java-alternatives -s java-1.8.0-openjdk-amd64

Use update-java-alternatives -l to list all available alternatives.

comment:43 in reply to:  42 Changed 23 months ago by mdk

Ignoring the configured default JDK when JOSM still supports it is not a good thing.

There are two alternative scenarios:

  • wait until Debian (or Ubuntu) change the default JDK. This would be ok. If a problem occure with JOSM the user can manually switch back to 7.
  • wait until JOSM requires Java 8 and dosn't work wit 7. If now a user encounter a problem according to Java 8, he is lost.

The acual approach with using Java 8 for JOSM, even if the user configuration prefers Java 7 for other prgramms, allows us to test JOSM with Java 8 and having Java 7 as fallback. So we hopefully find problems with Java 8 early.

comment:44 Changed 23 months ago by sebastic

Another option is to print a notice suggesting the user to switch their alternatives to Java 8 (including the update-java-alternatives command to do so) when 7 is still configured as the default.

You're not going to get many distribution package users providing feedback with Java 8, because it won't be installed on most systems. The dependencies still pull in OpenJDK 7, only users who have explicitly installed Java 8 (too) will have it used for JOSM. Those users who explicitly choose to use Java 8 can also easily update their alternatives or specify the appropriate JAVACMD to use Java 8 for JOSM as long as it's not the distribution default yet.

comment:45 Changed 23 months ago by mdk

Sorry, I don't understand this discussion!

As far as I understand Java alternatives is for applications which don't care about the java version. On the other hand a Java application can explicitly require a Java version (package dependency).

I think it's the wrong way to treat the user to change the default Java for ALL of his Java applications.

And it's also the wrong way (yet) to force the user to install Java 8 (via package dependency).

What is the problem if the devellopers of JOSM say: "If the user has installed Java 7 and Java 8, JOSM should prefer Java 8."? Why do you insist in changing Java version for other applications too?

comment:46 Changed 23 months ago by mdk

@Don-vip: BTW do you have newer statistics about the used Java version?

comment:47 in reply to:  45 Changed 23 months ago by sebastic

Replying to mdk:

As far as I understand Java alternatives is for applications which don't care about the java version. On the other hand a Java application can explicitly require a Java version (package dependency).

I think it's the wrong way to treat the user to change the default Java for ALL of his Java applications.

I agree that users should not be encouraged to change the default Java for all applications.

It is also the wrong way to treat the user by ignoring his configured Java version.

And it's also the wrong way (yet) to force the user to install Java 8 (via package dependency).

Then why is the alternatives support removed from the josm launcher? Those that wish to use Java 8 can do so by exporting the appropriate JAVACMD in the environment. You can even have the packaging install a profile.d snippet that has the export command commented to make it easy for the users to use Java 8 (only) for JOSM by uncommenting the export command.

What is the problem if the devellopers of JOSM say: "If the user has installed Java 7 and Java 8, JOSM should prefer Java 8."? Why do you insist in changing Java version for other applications too?

The problem is that JOSM doesn't need to require Java 8 yet, and so should adhere to the system configuration for which Java to use. The ability to use Java 8 for JOSM already existed (exporting JAVACMD), there is no need to remove the support for the alternatives system.

comment:48 Changed 23 months ago by mdk

Sorry, I still don't understand this discussion!

What is the problem if the devellopers of JOSM say: "If the user has installed Java 7 and Java 8, JOSM should prefer Java 8."?

comment:49 Changed 23 months ago by mdk

Java alternatives is for applications which don't care about the Java version.

All the above is about JOSM do care about the used Java version (prefer 8 over7)!

comment:50 in reply to:  46 ; Changed 23 months ago by Don-vip

Replying to mdk:

@Don-vip: BTW do you have newer statistics about the used Java version?

Here they are:

All users:
Java Main Version --> 6 (381,  3.3%) 7 (2693, 23.6%) 8 (8341, 73.0%) 9 (9,  0.1%)
OS:  FreeBSD (13,  0.1%) Linux (2914, 26.8%) Mac (792,  7.3%) OpenBSD (2,  0.0%) Windows (7151, 65.8%)

Recent versions (>= 7001):
Java Main Version --> 6 (10,  0.1%) 7 (2170, 21.0%) 8 (8155, 78.8%) 9 (9,  0.1%)
OS:  FreeBSD (13,  0.1%) Linux (2763, 26.7%) Mac (781,  7.5%) OpenBSD (2,  0.0%) Windows (6800, 65.6%)

Java 7 users:
OS:  FreeBSD (2,  0.1%) Linux (1708, 66.8%) Mac (40,  1.6%) OpenBSD (2,  0.1%) Windows (805, 31.5%)

Java 8 users:
OS:  FreeBSD (11,  0.1%) Linux (1231, 14.8%) Mac (746,  9.0%) Windows (6332, 76.1%)

Java 9 users:
OS:  Linux (28, 77.8%) Mac (1,  2.8%) Windows (7, 19.4%)

Nearly all Windows and OSX users are now using Java 8. Linux still remains behind but I note a significant progress.

I will revert r9066 after the switch. If it's really important for Debian, it's easy to patch it, but we need a majority of users running Java 8 before switching, to ensure a smoother transition in April (after the release of next Ubuntu LTS since Ubuntu maintainers refuse to backport Java 8 to current LTS, and we have many LTS users).

comment:51 in reply to:  48 Changed 23 months ago by sebastic

Replying to mdk:

What is the problem if the devellopers of JOSM say: "If the user has installed Java 7 and Java 8, JOSM should prefer Java 8."?

Because the application developers ignore the system configuration on the systems where their application runs. The users should be the ones to decide that they want to use Java 8 (not the system default) for JOSM and they can do that by exporting JAVACMD or using update-java-alternatives.

By removing the alternatives support but not actually requiring Java 8, the application developers communicate that they don't care about the user and system preference expressed via the alternatives system. But they don't care enough about Java 8 to have their PPA packaging actually install OpenJDK 8 instead of 7.

Replying to mdk:

Java alternatives is for applications which don't care about the Java version.

This is wrong, where did you get that idea?

All the above is about JOSM do care about the used Java version (prefer 8 over7)!

The packaging doesn't, only the startup page recommends the use of Java 8.

The packaging for the PPA still prefers Java 7 over 8 and 9:

$ grep Depends linux/*/DEBIAN/control 
linux/latest/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre
linux/tested/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre

The josm package in Debian just depends on the default-jre or any other java package that provides java7-runtime the minimum required for JOSM:

Depends: default-jre | java7-runtime,

comment:52 in reply to:  50 ; Changed 23 months ago by sebastic

Replying to Don-vip:

Nearly all Windows and OSX users are now using Java 8. Linux still remains behind but I note a significant progress.

This makes sense because they tend to use the Oracle JDK, and not packages from their distribution. Since you cannot easily get JDK 7 updates from Oracle any more, having users on those systems switch to Java 8 is a good thing.

OpenJDK 7 still gets updates on the Linux distributions that have it as their default. Switching away from that default by removing its support from the launcher, disadvantages those users. The JOSM developers already have a large userbase on other systems using Java 8, they don't need the package users for that too.

I will revert r9066 after the switch. If it's really important for Debian, it's easy to patch it, but we need a majority of users running Java 8 before switching, to ensure a smoother transition in April (after the release of next Ubuntu LTS since Ubuntu maintainers refuse to backport Java 8 to current LTS, and we have many LTS users).

As I wrote in our short email conversation, I wasn't annoyed enough to revert r9066 for the josm Debian package. I would like to see r9066 reverted because it's not the appropriate change to get more Linux users to use Java 8.

comment:53 in reply to:  52 ; Changed 23 months ago by Don-vip

Replying to sebastic:

By removing the alternatives support but not actually requiring Java 8, the application developers communicate that they don't care about the user and system preference expressed via the alternatives system.

We care about our users a lot. If we didn't we would have switched to Java 8 already. We don't switch because Ubuntu maintainers don't care to backport openjdk-8, refraining us to switch transparently because Ubuntu LTS does not provide Java 8.

But they don't care enough about Java 8 to have their PPA packaging actually install OpenJDK 8 instead of 7.

I don't understand that part. I'm a total newbie about packaging: is there a way to update our packaging so openjdk-8 is installed if available, without causing an error with Ubuntu LTS (referencing a non-existing package) ?

The packaging for the PPA still prefers Java 7 over 8 and 9:

$ grep Depends linux/*/DEBIAN/control 
linux/latest/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre
linux/tested/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre

I did not know order was important. So if no version of Java is installed, the first one is automatically installed?

Replying to sebastic:

The JOSM developers already have a large userbase on other systems using Java 8, they don't need the package users for that too.

Other systems don't count. Unresolved Java 8 bugs that impact JOSM identified today mainly concern Linux, see JavaBugs. Today Linux users are a small part (~25%) of our user base. Java 8 Linux users are a minority (~40%) of those. Users willing to provide feedback are then again a smaller minority. We really need as most as testing as possible.

I would like to see r9066 reverted because it's not the appropriate change to get more Linux users to use Java 8.

I will revert it after we switch, so it's only for 3 months. If it's not the appropriate change, I am listening to any other mean to increase the adoption of Java 8 without user intervention.

comment:54 in reply to:  53 Changed 23 months ago by sebastic

Replying to Don-vip:

Replying to sebastic:

But they don't care enough about Java 8 to have their PPA packaging actually install OpenJDK 8 instead of 7.

I don't understand that part. I'm a total newbie about packaging: is there a way to update our packaging so openjdk-8 is installed if available, without causing an error with Ubuntu LTS (referencing a non-existing package) ?

Newbies to Debian packaging should read the relevant documentation, most importantly:

For Java applications like JOSM the Debian policy for Java is also relevant. For upstream developers in general the Upstream Guide is another important reference.

Debian Policy Manual 7.1 Syntax of relationship fields is the relevant section documenting alternative dependencies:

In the Depends, Recommends, Suggests, Pre-Depends, Build-Depends and Build-Depends-Indep control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols |. In such a case, that part of the dependency can be satisfied by any one of the alternative packages.

The dependencies of the josm binary package should match the preference expressed in the josm launcher script:

        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-8-openjdk/bin/java /usr/lib/jvm/java-8-openjdk-$ARCH/bin/java /usr/lib/jvm/java-8-oracle/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-7-openjdk/bin/java /usr/lib/jvm/java-7-openjdk-$ARCH/bin/java /usr/lib/jvm/java-7-oracle/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-$ARCH/bin/java /usr/lib/jvm/java-9-oracle/bin/java"
Depends: openjdk-8-jre | openjdk-7-jre | openjdk-9-jre

Because no virtual java runtime package is included in the alternatives, custom java packages like those created with make-jpkg from the Oracle JDK/JRE tarballs don't satisfy the dependency. Adding | java7-runtime will allow those packages to satisfy the dependency too, because the packages created by make-jpkg provide the javaN-runtime virtual package, but they still won't be used until their paths are added in the josm launcher script too. The Web Upd8 oracle java pacages also provide the javaN-runtime virtual packages. Because the webupd8 package are supported by the josm launcher script, the better Depends for the josm PPA packaging is the same as used for the josm Debian package:

Depends: default-jre | java7-runtime

If you want to express the supported JREs by the launcher in the dependencies you should use:

Depends: openjdk-8-jre | oracle-java8-installer | openjdk-7-jre | oracle-java7-installer | openjdk-9-jre | oracle-java9-installer | java7-runtime

To force the installation of OpenJDK 8 if available you can use:

Depends: openjdk-8-jre | java7-runtime

Because the javaN-runtime virtual package is provided by all proper JDK & JRE packages, the user can prevent the installation of the first alternative by specifying a different package that provides javaN-runtime, e.g.:

apt-get install josm oracle-java8-installer

If you don't have openjdk-8-jre installed yet, you can also specify its removal along with the installation of josm & oracle-java8-installer to hint the resolver:

apt-get install josm oracle-java8-installer openjdk-8-jre-


The packaging for the PPA still prefers Java 7 over 8 and 9:

$ grep Depends linux/*/DEBIAN/control 
linux/latest/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre
linux/tested/DEBIAN/control:Depends: openjdk-7-jre | openjdk-8-jre | openjdk-9-jre

I did not know order was important. So if no version of Java is installed, the first one is automatically installed?

Alternative dependencies are tested in the order in which they are specified, this is an implementation detail of the resolver, not policy defined behavior. Autobuilders like those used for the Debian archive and Launchpad generally only consider the first dependency in a list of alternatives.

The first package of the alternatives that can be installed (because its dependencies can also be installed, and none conflict with other packages to be installed) will be chosen by the resolver, unless another package that is also specified to be installed satisfies the dependency too.

comment:55 Changed 23 months ago by Don-vip

Thank you for your detailed explanations, I understand better now. Still, I have a question.Why don't you depend only on java7-runtime? It should be enough, no?

comment:56 in reply to:  55 Changed 23 months ago by sebastic

Replying to Don-vip:

Why don't you depend only on java7-runtime? It should be enough, no?

Depending on only the java7-runtime virtual package is sufficient, but including a real package before the virtual package is a best practice.

Specifying a default choice of the packages providing the virtual package is recommended in Debian Policy Manual 7.5 Virtual packages - Provides:

To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one.

These real packages can also include a version requirement, which virtual packages don't support as documented in section 7.5 too:

If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. The package manager will assume that a package providing that virtual package is not of the "right" version. A Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be considered when considering a dependency on or conflict with the virtual package name.(52)

But this is not relevant for the javaN-runtime virtual packages.

comment:57 Changed 23 months ago by Don-vip

ok it makes perfect sense to me now, thank you :)
Then I'm going to change our dependencies as follows:

Depends: openjdk-8-jre | java7-runtime

comment:58 Changed 23 months ago by stoecker

Wouldn't openjdk-8-jre | java8-runtime | java7-runtime be correct? We want Java8 and Java7 should only be the last resort.

comment:59 Changed 23 months ago by Don-vip

In 9237/josm:

see #11390 - Make Debian control scripts depend on openjdk-8-jre as a preffered choice of Java runtime

comment:60 in reply to:  58 Changed 23 months ago by sebastic

Replying to stoecker:

Wouldn't openjdk-8-jre | java8-runtime | java7-runtime be correct? We want Java8 and Java7 should only be the last resort.

Adding | java8-runtime has not real benefit over the openjdk-8-jre dependency, all JDK/JRE 8 packages also provide java7-runtime.

$ apt-cache show openjdk-8-jre | grep Provides
Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime
$ apt-cache show openjdk-9-jre | grep Provides
Provides: java-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime, java9-runtime

comment:61 Changed 23 months ago by stoecker

It would prefer a non-openjdk java version 8 over an openjdk version 7 Java. Don't know if non-openjdk (oracle?) exists for Debian.

Last edited 23 months ago by stoecker (previous) (diff)

comment:62 Changed 23 months ago by sebastic

On Debian OpenJDK & GCJ (for the architectures that don't have a proper support for OpenJDK) are the only JREs available.

If you want to use the Oracle JDK on Debian, creating the package yourself from the Oracle tarball with make-jpkg is the best option.

Since the JOSM PPA is only relevant for Ubuntu users, adding oracle-java8-installer for the WebUpd8 PPA packages is a better choice than adding two virtual packages, i.e.:

Depends: openjdk-8-jre | oracle-java8-installer | java7-runtime

The josm Debian package doesn't use the control file included in the JOSM source, because it needs to be a proper source package to build the binary packages and account for the additional dependencies not embedded in the JOSM JAR. The josm Debian package does use the josm launcher, icons, desktop & appdata files to share their maintenance between the JOSM upstream developers and package maintainers in Debian. This way the upstream packaging benefits from the expertise of the Debian package maintainers (like the Icon Theme Specification changes for example), because upstream developers generally lack that expertise. Since JOSM 8800 the packaging is not completely separate any more.

comment:63 Changed 23 months ago by Don-vip

In 9249/josm:

see #11390 - resolve last javadoc warnings with Java 8. "ant javadoc" now produces 0 warning \o/

comment:64 Changed 22 months ago by Don-vip

update on stats:

Recent versions (>= 7001):
Java Main Version --> 6 (9,  0.1%) 7 (2442, 22.1%) 8 (8601, 77.8%) 9 (4,  0.0%)
OS:  FreeBSD (10,  0.1%) Linux (2744, 24.9%) Mac (804,  7.3%) OpenBSD (4,  0.0%) SunOS (1,  0.0%) Windows (7466, 67.7%)

Java 7 users:
OS:  FreeBSD (2,  0.1%) Linux (1756, 60.8%) Mac (32,  1.1%) OpenBSD (4,  0.1%) SunOS (1,  0.0%) Windows (1093, 37.8%)

Java 8 users:
OS:  FreeBSD (8,  0.1%) Linux (1165, 13.3%) Mac (775,  8.9%) Windows (6796, 77.7%)

Some interesting OS stats:

O        155 ( 1.4%) Linux Arch Linux [7: 21.3%, 8: 78.7%]

O         71 ( 0.6%) Linux Debian GNU/Linux 8.2 (jessie) [7: 73.2%, 8: 26.8%]
O        127 ( 1.1%) Linux Debian GNU/Linux 8.3 (jessie) [7: 75.6%, 8: 24.4%]

O         58 ( 0.5%) Linux Debian GNU/Linux testing (stretch) [7: 44.8%, 8: 55.2%]
O         43 ( 0.4%) Linux Debian GNU/Linux unstable (sid) [7: 60.5%, 8: 39.5%]

O         72 ( 0.6%) Linux Fedora release 23 (Twenty Three) [8: 100.0%]

O         67 ( 0.6%) Linux Mint 17.2 Rafaela [7: 77.6%, 8: 22.4%]
O        114 ( 1.0%) Linux Mint 17.3 Rosa [7: 82.3%, 8: 17.7%]

O        941 ( 8.5%) Linux Ubuntu 14.04.3 LTS [7: 67.1%, 8: 32.8%, 9: 0.1%]

O        353 ( 3.2%) Linux Ubuntu 15.10 [7: 50.9%, 8: 48.6%, 9: 0.6%]

O         68 ( 0.6%) Linux openSUSE 13.2 (Harlequin) (x86_64) [7: 10.3%, 8: 89.7%]
O         38 ( 0.3%) Linux openSUSE Leap 42.1 (x86_64) [8: 100.0%]

O        171 ( 1.5%) Mac OS X 10.10.5 [7: 4.1%, 8: 95.9%]
O         70 ( 0.6%) Mac OS X 10.11.1 [7: 5.7%, 8: 94.3%]
O        203 ( 1.8%) Mac OS X 10.11.2 [7: 3.0%, 8: 97.0%]
O        178 ( 1.6%) Mac OS X 10.11.3 [7: 1.7%, 8: 98.3%]

O        103 ( 0.9%) Windows 10 32-Bit [8: 100.0%]
O       1477 (13.4%) Windows 10 64-Bit [8: 100.0%]
O        706 ( 6.4%) Windows 7 32-Bit [7: 10.1%, 8: 89.9%]
O       3363 (30.4%) Windows 7 64-Bit [7: 14.6%, 8: 85.4%, 9: 0.1%]
O        218 ( 2.0%) Windows 8 64-Bit [7: 29.8%, 8: 70.2%]
O       1055 ( 9.6%) Windows 8.1 64-Bit [7: 5.6%, 8: 94.4%]
O        325 ( 2.9%) Windows XP 32-Bit [7: 32.6%, 8: 67.4%]

comment:65 Changed 22 months ago by sebastic

Quoting Emmanuel Bourg on the debian-java list:

OpenJDK 8...

...is now the default Java runtime in unstable! I just uploaded
java-common/0.55 to unstable and it switched the default-jre/jdk to
openjdk-8 for all the architectures previously defaulting to openjdk-7.

I expect a few packages to FTBFS after this update (most notably
eclipse) but the main compatibility issues have already been fixed.

Enjoy :)

The OpenJDK 8 stats for Debian and Ubuntu should start to rise now that it has been made the default. Ubuntu should include this change in the upcoming LTS release (xenial), the DebianImportFreeze is not planned until February 18th.

comment:66 Changed 20 months ago by Don-vip

Milestone: 16.0416.05

comment:67 Changed 19 months ago by Don-vip

Stats update:

Recent versions (>= 7001):
Java Main Version --> 6 (14,  0.2%) 7 (1653, 18.0%) 8 (7535, 81.9%) 9 (1,  0.0%)
OS:  FreeBSD (6,  0.1%) Linux (1915, 21.0%) Mac (666,  7.3%) Windows (6535, 71.6%)

Very recent versions (>= 9329):
Java Main Version --> 6 (14,  0.2%) 7 (1017, 13.7%) 8 (6380, 86.1%) 9 (1,  0.0%)
OS:  FreeBSD (6,  0.1%) Linux (1669, 22.8%) Mac (571,  7.8%) Windows (5085, 69.4%)

Current versions (>= 9979):
Java Main Version --> 6 (14,  0.2%) 7 (816, 13.2%) 8 (5333, 86.5%) 9 (1,  0.0%)
OS:  FreeBSD (3,  0.0%) Linux (1409, 23.2%) Mac (480,  7.9%) Windows (4191, 68.9%)

Java 7 users:
OS:  FreeBSD (1,  0.0%) Linux (1203, 54.4%) Mac (21,  0.9%) Windows (987, 44.6%)

Java 8 users:
OS:  FreeBSD (7,  0.1%) Linux (1649, 17.3%) Mac (789,  8.3%) Windows (7062, 74.3%)

Main OS:

O        129 ( 1.1%) Linux Arch Linux [7: 18.4%, 8: 81.6%]
O        177 ( 1.5%) Linux Debian GNU/Linux 8.4 (jessie) [7: 54.8%, 8: 45.2%]
O        120 ( 1.0%) Linux Mint 17.3 Rosa [7: 79.2%, 8: 20.8%]
O        126 ( 1.1%) Linux Ubuntu 14.04.3 LTS [7: 83.3%, 8: 16.7%]
O        716 ( 6.1%) Linux Ubuntu 14.04.4 LTS [7: 58.1%, 8: 41.9%]
O        254 ( 2.2%) Linux Ubuntu 15.10 [7: 45.3%, 8: 54.7%]
O        358 ( 3.1%) Linux Ubuntu 16.04 LTS [7: 2.0%, 8: 98.0%]

O        171 ( 1.5%) Mac OS X 10.10.5 [7: 3.5%, 8: 96.5%]
O        368 ( 3.1%) Mac OS X 10.11.4 [7: 1.1%, 8: 98.9%]

O        119 ( 1.0%) Windows 10 32-Bit [8: 100.0%]
O       1944 (16.6%) Windows 10 64-Bit [8: 100.0%]
O        785 ( 6.7%) Windows 7 32-Bit [6: 0.1%, 7: 15.0%, 8: 84.8%]
O       3034 (25.9%) Windows 7 64-Bit [6: 0.1%, 7: 11.9%, 8: 87.9%, 9: 0.1%]
O        217 ( 1.9%) Windows 8 64-Bit [7: 29.5%, 8: 70.5%]
O       1016 ( 8.7%) Windows 8.1 64-Bit [7: 4.3%, 8: 95.7%]
O        728 ( 6.2%) Windows XP 32-Bit [6: 0.1%, 7: 47.1%, 8: 52.7%]

About a third of Ubuntu LTS users have already upgraded to 16.04 (and so to Java 8).

@Dirk: I plan to do the same next week with JOSM server, if that's OK for you. I see Ubuntu has now switched to Python 3 only, is it going to be a problem for Trac?

comment:68 Changed 19 months ago by Don-vip

In 10166/josm:

see #11390 - ask some Linux users to switch to Java 8 (partial revert/update or r7001)

comment:69 Changed 19 months ago by Don-vip

Description: modified (diff)

comment:70 Changed 19 months ago by stoecker

I don't think Trac will work with python 3 in the current state.

comment:71 Changed 19 months ago by bastiK

Python 2 is still in the repository. The only thing they changed is the default, i.e. the symbolic link /usr/bin/python now points to python3 and not to python2.7.

comment:72 Changed 19 months ago by stoecker

Probably it's not a good idea to test this in a live system? Can we try somewhere else first? If you can wait 2-3 weeks I probably have a server usable for this some days before it ends. I'm step-by-step updating some older machines in our company.

comment:73 Changed 19 months ago by Don-vip

I can wait :)

comment:74 Changed 19 months ago by aseerel4c26

In https://help.openstreetmap.org/questions/49311/josm-java8-on-mac-os-x we saw people sticking to Java 7 probably because of the the wording on the JOSM homepage. Could you please change those phrases:

  • "written in ​Java 7" -> for Java 7+
  • "requires ​Java 7" -> requires ​Java 7 or newer

While "written in Java 7" might me true technically, it is quite confusing for non-programmers who do not know that the Java VM is backwards compatible.

comment:75 in reply to:  74 Changed 19 months ago by aseerel4c26

Replying to aseerel4c26:
I made the homepage wording change myself – did not see that it is a wiki page. :-) I hope you're fine with it.

comment:76 Changed 19 months ago by Don-vip

Didn't see this huge change. Ubuntu 16.04 does not provide openjdk-7 anymore! So the server upgrade will automatically make us switch to java 8 :)

Any news regarding the test server?

Changed 18 months ago by Don-vip

Attachment: java8.patch added

Java 8 migration patch

comment:77 Changed 18 months ago by Don-vip

Summary: Switch to Java 8[PATCH] Switch to Java 8

comment:78 in reply to:  76 Changed 18 months ago by stoecker

Replying to Don-vip:

Any news regarding the test server?

I plan to switch a server this week and server contract ends at 28th giving us one week for test use. Thought the customer did not yet give his OK and timetable for the server switch.

comment:79 Changed 18 months ago by Don-vip

Milestone: 16.0516.06

OK thanks. So let's release 16.05 as the last Java 7 release, then we upgrade the server and switch to Java 8 :)

comment:80 Changed 18 months ago by alexkemp

Debian Jessie 8.4 (current stable) still has openjdk-7-jre as the default (presumably due to the Priorities assigned within Debian alternatives) (the following was checked just now):—

(package: default-jre):
This dependency package points to the Java runtime,
or Java compatible runtime recommended for the amd64
architecture, which is openjdk-7-jre for amd64.

Unfortunately, and in addition to the above, whilst openjdk-8-jre is available, and for whatever reason, manual selection of openjdk-8 through update-alternative fails to cause Jessie to use java8 when launching JOSM.

The above is currently documented in horrifying detail here:
https://wiki.openstreetmap.org/wiki/JOSM/Linux#help_text_4_.28Debian.29

As a Jessie user, I would appreciate you waiting until Java-8 becomes the Debian default.

comment:81 Changed 18 months ago by sebastic

You need to use the update-java-alternatives command to change the preferred java on Debian. It updates the symlinks for all the executables, not just bin/java.

comment:82 in reply to:  80 Changed 18 months ago by Don-vip

Replying to Alex Kemp <modem.help.co.uk@…>:

As a Jessie user, I would appreciate you waiting until Java-8 becomes the Debian default.

Sorry, it's not going to happen. Please follow sebastic's command to configure java 8 as default if needed.

comment:83 Changed 18 months ago by alexkemp

Replying to Don-vip (himself quoting sebastic):—

You need to use the update-java-alternatives command...

Yes, and that would be perfectly splendid if it worked. Except that, as explained in horrifying detail, it does not.

Debian have deliberately set the update-alternative Priority such that Java-7 is the current default.

Debian have placed incompatible groups into /usr/lib/jvm/.java-1.8.0-openjdk-amd64.jinfo, ensuring that jdk groups (which includes 'jar' apps) are unaffected by ​update-java-alternatives.

My assumption is that these two items are why but, whatever is the reason, use of neither ​update-java-alternatives nor ​update-alternatives will produce a situation where the latest Debian stable can run JOSM under Java-8.

Sun/Oracle have been developing Java for countless years for Windows, and have succeeded in producing new binaries every few weeks, each riddled with security bugs. Debian are working steadily to produce a stable, secure, open-source JDK-8. They are not there yet.

I would ask you, most respectfully, to allow Debian to opportunity to produce a secure openjdk-8 that can be used under Debian stable. You have waited this long, and can surely wait a few weeks more, so that open-source users are not forced to use the closed, security-bug-ridden horror known as JAVA-8. I spent countless years forced to do that under Windows, and do not wish to be back under the same yoke.

comment:84 in reply to:  83 Changed 18 months ago by sebastic

My assumption is that these two items are why but, whatever is the reason, use of neither ​update-java-alternatives nor ​update-alternatives will produce a situation where the latest Debian stable can run JOSM under Java-8.

You're obviously doing it wrong. For starters you're replacing the files provided by the josm package with your own, there is no use installing the josm package if you're using the JAR from josm.openstreetmap.de instead.

The /usr/bin/josm launcher included in josm package in jessie doesn't include OpenJDK-8 in its list of supported JREs, so changing the alternative to OpenJDK-8 has no effect, because it doesn't match a known good.

If you're using the JAR instead of the package, you need to create your own launcher for it. This can be as simple as the following shell script:

$ cat /usr/local/bin/josm-tested
#!/bin/sh

java -Djosm.home="$HOME/.josm-tested" -jar $HOME/josm/josm-tested.jar $@

This is a good option if you have both the josm package installed and the latest tested JAR. If you don't care for the packaged version, you can use the launcher from JOSM SVN and change the path to your josm-tested.jar instead of /usr/share/josm/josm.jar.

Even with the josm launcher from the jessie package, you can run josm with any JRE not explicitly listed among the supported by specifying the JAVACMD:

JAVACMD=/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java josm

comment:85 Changed 18 months ago by alexkemp

Thanks for your input, sebastic, but you obviously do not run Debian stable nor have read my links.

You wrote:

You're obviously doing it wrong. For starters you're replacing the files provided by the josm package with your own...

That sentence is profoundly insulting.

The original JOSM package for Debian Jessie is hopelessly out-of-date (7643 cf 10168), and cannot possibly be used with JAVA-8. As the Debian package hasn't been updated since 2014 & I do not have the time to rewrite it myself, what choice other than use the official josm-tested JAR do I have? And in particular, that is the specific advice given within JOSM, via the constant emphasis upon JOSM-version + the URLs that it sends me to. So, to criticise me for simply following the advice given is profoundly insulting, and I demand an apology, sir.
 

so changing the alternative to OpenJDK-8 has no effect, because it doesn't match a known good.
The /usr/bin/josm launcher included in josm package in jessie doesn't include OpenJDK-8 in its list of supported JREs

Not true, at least on my fast reading of the wrapper script at /usr/bin/josm it is perfectly prepared to accept JAVA-8 if set as such by Debian alternatives. Exactly where does that script have a “list of supported JREs”, because I cannot see any?

change the path to your josm-tested.jar instead of /usr/share/josm/josm.jar

If you had bothered to read the links supplied you would have seen that I've already done that:

:~$ ls -Al /usr/share/josm
total 15820
drwxr-xr-x  4 root root     4096 May 17 16:44 data
drwxr-xr-x 15 root root     4096 May 17 16:44 images
-rw-r--r--  1 root root  5367501 Oct 24  2014 josm-0.0.svn7643+dfsg1.jar
lrwxrwxrwx  1 root root       40 May 17 20:26 josm.jar -> /usr/share/josm/josm-tested-svn10168.jar
-rw-r--r--  1 root root 10811189 May 17 20:21 josm-tested-svn10168.jar
drwxr-xr-x  3 root root     4096 May 17 16:44 styles


Even with the josm launcher from the jessie package, you can run josm with any JRE not explicitly listed among the supported by specifying the JAVACMD:

JAVACMD=/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java josm

It would truly have saved us both a lot of time if you had bothered to read the links I've supplied.

:~$ ls -Al /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root 15 Apr 22 18:01 /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java -> ../jre/bin/java

You see, I've already set the system to use JAVA-8, but it does not want to know. I've edited the following to just show 'java'. The full list is at the earlier link:

:~$ update-alternatives --get-selections | fgrep -i java
...
java                           manual   /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
...
Last edited 18 months ago by alexkemp (previous) (diff)

comment:86 in reply to:  85 Changed 18 months ago by sebastic

Replying to alexkemp:

Thanks for your input, sebastic, but you obviously do not run Debian stable nor have read my links.

You assumptions are wrong, I run Debian jessie on all my systems except my development workstation which runs unstable.

You wrote:

You're obviously doing it wrong. For starters you're replacing the files provided by the josm package with your own...

That sentence is profoundly insulting.

The wiki you linked documents the procedure to replace the package provided josm.jar symlink, doing that is wrong. If you consider that statement of fact insulting, I'm sorry to hear you feel that way but I cannot sugarcoat the facts.

The original JOSM package for Debian Jessie is hopelessly out-of-date (7643 cf 10168), and cannot possibly be used with JAVA-8. As the Debian package hasn't been updated since 2014 & I do not have the time to rewrite it myself, what choice other than use the official josm-tested JAR do I have? And in particular, that is the specific advice given within JOSM, via the constant emphasis upon JOSM-version + the URLs that it sends me to. So, to criticise me for simply following the advice given is profoundly insulting, and I demand an apology, sir.

Because the various JOSM dependencies are also used by other packages in Debian (metadata-extractor most importantly), providing josm backports for stable is problematic, because we need to backport the other reverse dependencies too making the maintenance burden too large.

Like resistance to the Borg, your demand for an apology is futile.

so changing the alternative to OpenJDK-8 has no effect, because it doesn't match a known good.
The /usr/bin/josm launcher included in josm package in jessie doesn't include OpenJDK-8 in its list of supported JREs

Not true, at least on my fast reading of the wrapper script at /usr/bin/josm it is perfectly prepared to accept JAVA-8 if set as such by Debian alternatives. Exactly where does that script have a “list of supported JREs”, because I cannot see any?

The JAVA_CMDS variable holds the list of known good JREs, for the jessie version of the launcher that's defined on line 14:

https://sources.debian.net/src/josm/0.0.svn7643%2Bdfsg1-1/debian/josm.sh/#L14

The for loop on line 21 checks if any of the JAVA_CMDS match the one configured in the alternatives system, the first match will be used unless JAVACMD is set in the environment.

The for loop on line 27 will use the first executable java command it find unless JAVACMD is set in the environment or because it was previously found in the for loop starting on line 21.

Hence only $JAVA_HOME/bin/java and the OpenJDK 7 java commands are considered by the josm launcher in the jessie package.

If you want to use something else you need to set JAVACMD in the environment.

change the path to your josm-tested.jar instead of /usr/share/josm/josm.jar

If you had bothered to read the links supplied you would have seen that I've already done that:

:~$ ls -Al /usr/share/josm
total 15820
drwxr-xr-x  4 root root     4096 May 17 16:44 data
drwxr-xr-x 15 root root     4096 May 17 16:44 images
-rw-r--r--  1 root root  5367501 Oct 24  2014 josm-0.0.svn7643+dfsg1.jar
lrwxrwxrwx  1 root root       40 May 17 20:26 josm.jar -> /usr/share/josm/josm-tested-svn10168.jar
-rw-r--r--  1 root root 10811189 May 17 20:21 josm-tested-svn10168.jar
drwxr-xr-x  3 root root     4096 May 17 16:44 styles

Modifying files in /usr/share/josm is wrong, you need to change the path in your copy of the launcher script like /usr/local/bin/josm-tested in my example. Modying the /usr/bin/josm provided by the josm package is likewise wrong. These files are management by the package manager, making modifications like your results in the package manager being unable to remove the /usr/share/josm directory when uninstalling the josm package because there are still unowned files left in the directory the package manager doesn't know about.

Distribution provided software lives in /usr, your locally installed software should live in your homedirectory or in /usr/local to make it available to other users.

Even with the josm launcher from the jessie package, you can run josm with any JRE not explicitly listed among the supported by specifying the JAVACMD:

JAVACMD=/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java josm

It would truly have saved us both a lot of time if you had bothered to read the links I've supplied.

I have, and your linked documentation only talks about using update-alternatives which is wrong when you want to change the default java. It mentions update-java-alternatives but subsequently fails to use the proper tool for the job. This issue was discussed earlier in this issue too, but you obviously didn't bother to read that.

comment:87 Changed 18 months ago by bastiK

You have java 8 installed, so you can simply call:

/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java -jar ~/Download/josm/josm-tested-svn10168.jar

What is the problem?

Besides, I would recommend to install the Debian package we offer in the Download section. Please file a bug report if that package doesn't pick up your java 8 installation.

comment:88 Changed 18 months ago by alexkemp

Hello sebastic

Hmm. I take it that your reference to The Borg is an indication of the fact that you are unable to think outside of the Cube?
 

I run Debian jessie on all my systems except my development workstation

I am used to being wrong, and pleased to be corrected.

(difficulties in providing backports for JOSM)

In that case, any method that I choose for updating JOSM is fine, since you do not/cannot provide an upgrade to the available package in stable.

I have zero problems with the fact that no-one can provide an up-to-date JOSM package for the stable distribution. I am allowed to arch one eyebrow at that statement, whether you like it or not. However, you have zero authority in those circumstances to tell me that my current method of upgrading “is wrong”. You can tell me that it will have unfortunate consequences (and what those consequences will be), you can suggest that doing xyz would be a better option, but there isn't now a “right” option, so there cannot be a “wrong” way to fix it, only better or worse options to proceed.

In other words, change your attitude. The current one is not helpful.

I'm sick & tired of this. The following was helpful:

Distribution provided software lives in /usr, your locally installed software should live in your homedirectory or in /usr/local to make it available to other users.


Final comment:

your linked documentation only talks about using update-alternatives

I was attempting to document Debian for the benefit of other folks with even less understanding of Debian than me. There is zero point in documenting something that does not yet work. update-java-alternatives is ineffective in Debian Jessie with openJDK-8 installed. Or did you not get that far? Or perhaps you have not yet grasped the fact that ‘reading’ & ‘understanding’ are not necessarily linked?

comment:89 in reply to:  88 Changed 18 months ago by stoecker

Replying to alexkemp:

In other words, change your attitude. The current one is not helpful.

You're the one who has an issue and when told you're doing wrong and how to do right feel insulted. Probably you're the one needing to rethink about your attitude. This is no cuddle group but a bug tracker - you actually should feel grateful that you get help here at all, as this is no support forum and it's relatively clear from the beginning, that your request is a support and not a bug issue! And nevertheless sebastic probably spent more than half an hour total time answering to your issues and you complain about the wording.

Sometimes I really feel that developing open source is not worth the effort when I see such behaviour.

comment:90 Changed 18 months ago by alexkemp

I had to step away from this & do some mapping whilst I still can with my current setup. I was getting so upset at the attitudes displayed that I was liable to start using language that would not help.

For the record, I do not personally need support on Linux nor, most of the time, on JOSM. However, I was studying Maths/Physics at university before Linux or graphical systems were even conceived (1968), so am always pleased to be given informed direction on Linux conventions, as I have had zero formal instruction in Unix/Linux/programming/JOSM.

I'm a long-term (1973) informal programmer (C/C++/database/PHP, etc.), have produced brochures on early macs (late 1980s) and have done some open-source hacking, although most of it was in connection with modems, and most of my linux work was command-line server & network-related business (15 years). My first experience of graphical Linux was in March 2016.

My desire has been to provide guidance for those that do not want to be Linux gurus in order to use JOSM under Debian. I installed Debian for the first time in order to get to grips with JOSM, so my experience should be invaluable in assisting others attempting to do a similar thing. Hence my efforts to bring the JOSM-Linux|Debian Wiki up to date. It was a response to those early efforts that brought me here, as it was pointed out to me that JAVA-7 support was due to end very soon, and a link was given to this ticket.

When I first met the JOSM Wiki I could not understand why the help provided was so little, so old & out-of-date (JAVA-6). Having tried to mitigate this disastrous decision to cast naïve Debian users into the outer darkness I now understand – nobody working on JOSM seems capable of seeing very much outside of the narrow confines of their personal experience. In a nutshell, JOSM developers expect other JOSM users to be programmers like themselves (though obviously, not as expert).

Nobody likes being told that their attitude stinks, but someone has to do it:—

Your attitude stinks.

Consider:—

  1. The Stable distribution is the place for stable applications.

Is the current JOSM stable? If so...

  1. Why is there not a current version of JOSM within Jessie?
  2. Why is the current version in Jessie 2 years old?
  3. Since no-one can be bothered to keep the Jessie JOSM current, why is there not a statement saying that?

(there will be soon; I'll put it there)

I understand the desire to pursue the bright glitter of tomorrow. That is a very masculine thing, and what allows tomorrow to approach closer to today. However, we have a Martha & Mary thing going on here. Someone needs to do the 'drudge' work but, looking at the Wiki & the state of the Distros, no-one is interested in cleaning the house.

No wonder there are so few women interested in OpenStreetMap.

In reply to bastiK...
Many thanks for the link to the Download page. I'll follow that one up to see if I can keep Jessie until Squeeze becomes the Stable distro.

comment:91 Changed 18 months ago by alexkemp

Update for bastiK:
The update from the Download page was (almost) trouble-free. The single, tiny glitch was a need to install apt-transport-https first (Synaptic gave zero clue, just an error; sudo apt-get update was better). I selected alldist & it was trouble-free. Also, no more complaint about JAVA-7 on JOSM load (hooray!) so - it seems we have a minimal-extra method to use JOSM under Jessie + keep it updated. Phew!

Many thanks again to bastiK for the pointer, and to the APT maintainers for a well-worked setup.

I'll add all this info to the Wiki.

PS
My JAVA alternatives setup seems to be untouched. Does anybody know if the APT setup makes any changes to java?

comment:92 Changed 18 months ago by stoecker

Again: This is the JOSM bug tracker! It is about the development of JOSM. If you have have issues with Debian go to the Debian bug tracker. If you want support go to the forums or mailing lists. If you want to provide help improve the wiki pages. If you feel misunderstood go to therapy.

You are completely off-topic here and I'll remove any further off-topic entries here.

Changed 18 months ago by sebastic

Attachment: java8_depends.patch added

Java 8 migration patch keeping OpenJDK dependency for Ubuntu package

comment:93 in reply to:  77 ; Changed 18 months ago by sebastic

Replying to Don-vip:

Java 8 migration patch

attachment:java8.patch drop the real openjdk-8-jre package from the dependencies and only increments the dependency on the virtual java8-runtime package:

--- linux/tested/DEBIAN/control (revision 10202)
+++ linux/tested/DEBIAN/control (working copy)
@@ -5,7 +5,7 @@
 Homepage: https://josm.openstreetmap.de
 Priority: extra
 Architecture: all
-Depends: openjdk-8-jre | java7-runtime
+Depends: java8-runtime
 Conflicts: josm-plugins
 Replaces: josm-plugins
 Description: Editor for OpenStreetMap

As discussed in comment:54 & comment:56 a real package should always be the first option when alternative dependencies are specified. This is the default choice to install when multiple packages provide the virtual package.

Because only openjdk-8-jre is available in Ubuntu by default, keeping it as the default JRE to install for JOSM is better than only depending on the virtual java8-runtime package also provided by the oracle-java8-installer packages from the WebUpd8 PPA and JRE/JDK packages created from the Oracle tarballs with make-jpkg. Users who prefer the Oracle ones over OpenJDK can prevent the installation of openjdk-8-jre by specifying their preferred JRE package when installing JOSM, e.g. for the WebUp8 packages:

apt-get install josm oracle-java8-installer openjdk-8-jre-

I've updated the java8.patch to keep the openjdk-8-jre dependency in attachment:java8_depends.patch

comment:94 in reply to:  93 Changed 18 months ago by Don-vip

Replying to sebastic:

I've updated the java8.patch to keep the openjdk-8-jre dependency in attachment:java8_depends.patch

Thanks! This is highly appreciated :)

comment:95 Changed 18 months ago by michael2402

What is the status of this? What is the current timeline for applying the patch?

comment:96 Changed 18 months ago by Don-vip

The patch will be applied as soon as we upgrade our server to latest Ubuntu LTS. We need to test the upgrade on another server first, which is only available since yesterday. I don't know yet when I'll have time to test and switch.

comment:97 Changed 18 months ago by bastiK

We could create a Subversion branch for the Java 8 switch and the queued patches with Java 8 dependency. Later, when the server is ready, merge the changes into trunk.

Michael, would that be helpful for the progress of your GSoC project? (If not, there is no reason to do this.) Your patches would get code review and be "in", but no daily build and user testing.

comment:98 Changed 18 months ago by michael2402

I don't think this is necessary. I can continue writing code for Java 7. Java 8 is more convenient, but my work does not depend on it.

comment:99 Changed 18 months ago by Don-vip

I began to test the server upgrade. A package is missing, I'd like to see it released first: https://github.com/RazrFalcon/SVGCleaner/issues/29

comment:100 Changed 18 months ago by Don-vip

If not fixed soon I'll fork the repo and create my own PPA. I expect to upgrade the server next week on 16th June evening.

comment:101 Changed 17 months ago by Don-vip

Milestone: 16.0616.07

JOSM is too unstable right now (108 unit tests failing) to think about a Java 8 switch, I wait for the layer management code to become stable.

comment:102 Changed 17 months ago by Don-vip

I plan to upgrade the server tomorrow, 12pm. But I won't switch to Java 8 yet (we will still provide JAR files built with Java 7), I'm waiting for the resolution of these tickets before releasing 16.06, then switch to Java 8:

  • #9995 (the blocking part)
  • #12987 (major regression, maybe only for OSX users)
  • #12937 / #13071 (unit tests must be fixed)

Here are the stats updates:

Recent versions (>= 7001):
Java Main Version --> 6 (20,  0.0%) 7 (17072, 18.1%) 8 (77045, 81.8%) 9 (15,  0.0%)
OS:  FreeBSD (115,  0.1%) Linux (24535, 26.1%) Mac (6357,  6.8%) OpenBSD (19,  0.0%) SunOS (10,  0.0%) Windows (62905, 67.0%)

Very recent versions (>= 9329):
Java Main Version --> 6 (20,  0.0%) 7 (13139, 15.7%) 8 (70597, 84.3%) 9 (13,  0.0%)
OS:  FreeBSD (115,  0.1%) Linux (23029, 27.6%) Mac (5833,  7.0%) OpenBSD (16,  0.0%) SunOS (7,  0.0%) Windows (54557, 65.3%)

Current versions (>= 10168):
Java Main Version --> 6 (20,  0.0%) 7 (8837, 13.4%) 8 (57160, 86.6%) 9 (11,  0.0%)
OS:  FreeBSD (86,  0.1%) Linux (19485, 29.6%) Mac (4710,  7.2%) OpenBSD (12,  0.0%) SunOS (7,  0.0%) Windows (41491, 63.1%)

comment:103 Changed 17 months ago by Don-vip

Let's go!

comment:104 Changed 17 months ago by Don-vip

OK we're now running 16.04 LTS, with native packages for Java 8 and Java 9 :)
Let me know if something is not working anymore.

comment:105 Changed 16 months ago by Don-vip

Owner: changed from team to Don-vip
Status: newassigned

comment:106 Changed 16 months ago by Don-vip

r10526 is the last Java 7 version. To ease migration for Ubuntu LTS users I'll switch the code base on 21st July to match Ubuntu 16.04.1 LTS point release.

comment:107 Changed 16 months ago by Don-vip

In 10580/josm:

see #11390 - switch to Java 8

comment:108 Changed 16 months ago by Don-vip

Summary: [PATCH] Switch to Java 8Switch to Java 8

comment:109 Changed 16 months ago by Don-vip

In 10581/josm:

see #11390, fix #12472 - Use error-prone in build (patch by simon04, modified) - requires java 8

comment:110 Changed 16 months ago by Don-vip

In 10582/josm:

see #11390, fix #12908 - Java 8: Move to java Predicates (patch by michael2402) - gsoc-core

comment:111 Changed 16 months ago by Don-vip

In 10583/josm:

see #11390, fix #12952 - Java 8: Disable auto boxing for hashCode/equals (patch by michael2402) - gsoc-core

comment:112 Changed 16 months ago by Don-vip

In 10585/josm:

see #11390, fix #12905 - Add more information to the bug report (patch by michael2402) - gsoc-core - requires java 8

comment:113 Changed 16 months ago by Don-vip

In 10586/josm:

see #11390, fix #13190 - Allow Lambda bug report parameters (patch by michael2402) - gsoc-core

comment:114 Changed 16 months ago by Don-vip

In 10588/josm:

see #11390, fix #13120 - Use a new memory manager for imagery layers (patch by michael2402) - gsoc-core - requires java 8

comment:115 Changed 16 months ago by Don-vip

In 10590/josm:

see #11390, fix #13191 - Documentation and migration to java 8 of preset code (patch by michael2402) - gsoc-core

comment:116 Changed 16 months ago by Don-vip

In 10592/josm:

see #11390, fix #13192 - Update LayerPositionStrategy to be a java 8 functional interface (patch by michael2402, modified) - gsoc-core

comment:117 Changed 16 months ago by Don-vip

In 10593/josm:

see #11390 - sonar - squid:S2293 - improved use of diamond operator thanks to Java 8 (JEP 101: http://openjdk.java.net/jeps/101)

comment:118 Changed 16 months ago by Don-vip

In 10594/josm:

see #11390, see #12908 - sonar - squid:S1612 - Lambdas should be replaced with method references

comment:119 Changed 16 months ago by Don-vip

In 10596/josm:

see #11390, see #13120, see #13190 - sonar - squid:S1612 - Lambdas should be replaced with method references

comment:120 Changed 16 months ago by Don-vip

In 10599/josm:

see #11390 - sonar - squid:S1610 - Java 8: Abstract classes without fields should be converted to interfaces

comment:121 Changed 16 months ago by Don-vip

In 10600/josm:

see #11390 - sonar - squid:S1609 - Java 8: @FunctionalInterface annotation should be used to flag Single Abstract Method interfaces

comment:122 Changed 16 months ago by Don-vip

In 10601/josm:

see #11390 - sonar - squid:S1604 - Java 8: Anonymous inner classes containing only one method should become lambdas

comment:123 Changed 16 months ago by Don-vip

In 10607/josm:

see #11390 - sonar - squid:S1609 - Java 8: Make Condition a functional interface

comment:124 Changed 16 months ago by Don-vip

In 10608/josm:

see #11390 - sonar - squid:S1604 - Java 8: Anonymous inner classes containing only one method should become lambdas

comment:125 Changed 16 months ago by Don-vip

In 10611/josm:

see #11390 - sonar - squid:S1604 - Java 8: Anonymous inner classes containing only one method should become lambdas

comment:126 Changed 16 months ago by Don-vip

In 10612/josm:

see #11390, fix #12910 - Clean WMS Imagery (patch by michael2402) - gsoc-core - requires java 8

comment:127 Changed 16 months ago by Don-vip

In 10614/josm:

see #11390, see #12472 - Update to error-prone 2.0.11

comment:128 Changed 16 months ago by Don-vip

In 10615/josm:

see #11390 - sonar - squid:S1604 - Java 8: Anonymous inner classes containing only one method should become lambdas

comment:129 Changed 16 months ago by stoecker

Startup page Java version check now marks Java 7 as deprecated version.

comment:130 Changed 16 months ago by Don-vip

In 10616/josm:

see #11390 - sonar - squid:S1604 - Java 8: Anonymous inner classes containing only one method should become lambdas

Changed 16 months ago by simon04

Attachment: java8-utils.patch added

comment:131 Changed 16 months ago by simon04

Some Utils function can nicely be rewritten using Java 8 streams → attachment:java8-utils.patch​. A few functions are oneliners, making a dedicated utility function useless.

I'm posting the patch to avoid interfering with the Java 8 updates and for some discussion.

comment:132 Changed 16 months ago by michael2402

@simon04

Have a look at StreamUtils.toStream(Iterator<? extends T> iterator) ;-)

I prefer having a new utils class for all that stream stuff. The current Utils class is pretty long already.

I'd also deprecate the find() methods. You should rewrite your code as:

Optional<?> item = list.stream().filter(...).findFirst();
if (!item.isPresent()) {
    // handle error.
}

It gives programmers the ability to search whatever they prefer (findFirst(), findAny() or the reduce((a, b) -> throw new Exception()) hack to get exactly one element) and to do a nicer error handling using orElseThrow, orElseGet or other methods. It would remove a lot of != null checks. And since those methods depend on JOSM predicate, we need to deprecate them any way.

Last edited 16 months ago by michael2402 (previous) (diff)

comment:133 Changed 16 months ago by simon04

Ah, it's already there. According to https://stackoverflow.com/a/23936723/205629, StreamSupport.stream(iterable.spliterator(), false) is preferred over Spliterators.spliteratorUnknownSize.

I mostly rewrote (and deprecated) functions that were already in Utils.

comment:134 Changed 16 months ago by michael2402

I updated my comment to include the find() methods.

You can use iterable.spliterator() if you have an Iterable, not an Iterator. But since we use iterables most of the time, we could change that and then simply use toStream(() -> iterator) whenever we have an iterator.

Last edited 16 months ago by michael2402 (previous) (diff)

Changed 16 months ago by simon04

Attachment: java8-utils-v2.patch added

comment:135 Changed 16 months ago by simon04

Sorry, I confused Iterator and Iterable. However, () -> iterator is a nice way to convert the former into the latter. I updated the patch w.r.t. StreamUtils#toStream(Iterable) and marking Utils.filter also deprecated.

comment:136 Changed 16 months ago by Don-vip

In 10618/josm:

see #11390 - Java 8: use java.util.Base64

comment:137 Changed 16 months ago by Don-vip

In 10619/josm:

see #11390 - Java 8: use List.sort(Comparator) instead of Collections.sort(list, Comparator)

comment:138 Changed 16 months ago by Don-vip

In 10625/josm:

see #11390 - Java 8: use more lambdas / method references

comment:139 Changed 16 months ago by Don-vip

In 10638/josm:

see #11390, fix #13206 - Migrate Function interface to java 8 (patch by michael2402, modified) - gsoc-core

comment:140 Changed 16 months ago by Don-vip

In 10643/josm:

see #11390 - use method reference

comment:141 Changed 16 months ago by Don-vip

In 10647/josm:

see #11390 - use functional comparators

comment:142 Changed 16 months ago by Don-vip

In 10657/josm:

see #11390, see #12890 - use Java 8 Predicates

comment:143 Changed 16 months ago by Don-vip

In 10658/josm:

see #11390, see #12890 - use Java 8 Predicates (forgot some)

comment:144 Changed 16 months ago by Don-vip

In 10689/josm:

see #11390, see #12890 - Use Java 8 Function

comment:145 Changed 16 months ago by Don-vip

In 10691/josm:

see #11390, fix #12890 - finish transition to Java 8 predicates/functions

comment:146 Changed 16 months ago by simon04

In 10714/josm:

see #11390 - Use CompletableFuture for async image loading

comment:147 Changed 16 months ago by simon04

In 10715/josm:

see #11390, see #12890 - Deprecate Predicates class

comment:148 Changed 16 months ago by simon04

In 10716/josm:

see #11390, see #12890 - Deprecate predicates in OsmPrimitive class

comment:149 Changed 16 months ago by simon04

In 10717/josm:

see #11390, see #12890 - Lambda can be replaced with method reference

comment:150 Changed 16 months ago by simon04

In 10718/josm:

see #11390 - Simplify StreamUtils

comment:151 Changed 16 months ago by Don-vip

In 10728/josm:

see #11390 - fix checkstyle violations

comment:152 Changed 16 months ago by Don-vip

Resolution: fixed
Status: assignedclosed

comment:153 Changed 16 months ago by Don-vip

In 10746/josm:

see #11390, see #11924 - replace javax.xml.bind.DatatypeConverter (not visible by default in Java 9) by java.util.Base64 (new in Java 8)

comment:154 Changed 16 months ago by skyper

There used to be a user friendly message about an unsupported java version in the .jar file but now I only get an exception (see below). As in Debian jessie openjdk-1.8 is still only available through backports which is not available with default settings a user friendly message instead of an exception would be appropriate. Thanks

user@host:~$ java -jar Downloads/josm-latest.jar --help
Exception in thread "main" java.lang.UnsupportedClassVersionError: JOSM : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:803)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
Last edited 16 months ago by skyper (previous) (diff)

comment:155 Changed 16 months ago by Don-vip

Indeed it was created in r3417 with the explicit message "The following classes need to be Java 5 compatible for this message box to show up: JOSM, MainApplication, I18n".

This is not the case anymore, the source code is Java 8 everywhere.

@team: what do you think we should do? Invest some time to make a Java-7 compliant bootstrap, or drop this feature?

comment:156 Changed 16 months ago by sebastic

While I'm not part of the team, I don't think it's worth it to invest in Java 7 support to notify users about the need to use Java 8.

The website is quite clear that Java 8 is needed, the changelog for r10526 is also quite clear that it was the last version to support Java 7.

The UnsupportedClassVersionError exception is not as clear as it could be, that's a shame but outside of the scope for JOSM. Searching the web for that error message shows that you need Java 8 to fix it, that should be sufficient.

comment:157 Changed 15 months ago by simon04

In 10774/josm:

see #11390, see #12890 - Drop Match.{existsMatch,forallMatch} in favour of stream API

comment:158 Changed 15 months ago by Don-vip

Thanks sebastic :) Any other opinion? Dirk, Paul, Simon?

comment:159 Changed 15 months ago by stoecker

If we can get it working again it would be fine, but I think we don't loose much when we drop that warning.

comment:160 Changed 15 months ago by michael2402

One problem is that MainApplication has many dependencies.

It would not be much work to create a new class that provides it's own main() method. It checks for Java8 and then calls the real main() of MainApplication

comment:161 Changed 15 months ago by simon04

If I understand correctly, the main class (MainApplication at the moment) would need to be compiled using Java 7, making the build process more complex. I doubt that it's worth the effort, since, as sebastic pointed out, a quick internet search reveals the problem.

comment:162 Changed 15 months ago by Don-vip

OK I'm not really in favor of complexifying the build, so let's remove this non-working feature.

comment:163 Changed 15 months ago by Don-vip

In 10786/josm:

see #11390 - remove non-working java version check as it would need to compile some classes with JDK7

comment:164 Changed 2 months ago by Don-vip

In 12865/josm:

see #11390 - SonarQube - squid:S3824 - "Map.get" and value test should be replaced with single method call

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Don-vip.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.