4 ms·

Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that mus

Perhaps it's not fair to blame the language, but the javax -> jakarta EE transition and Oracles license changes have broken a lot of faith in stability that must be frustrating as a language researcher with that goal.

pron 4y ago
Oracle's "license change" was to open source the entire JDK for the first time in Java's history (although many people tried to make sure this was misunderstood, which wasn't helped by Oracle's poor communication -- now that's frustrating), and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. Even Oracle only uses the java/javax namespaces for JCP APIs. They claimed it was too inefficient, but Java SE churns out two specification versions a year through the JCP, despite them being bigger and more complex than Jakarta EE.
- cesarb 4y ago
  > Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/ https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments. > and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer https://github.com/eclipse/transformer).
  - pron 4y ago
    > things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license AFAIK, the change to the pricing model for support was done at the request of Oracle's support customers, as it's easier for them to track. I don't know why non support customers would care one way or another. > but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK The OpenJDK website's downloads link links here: https://jdk.java.net https://jdk.java.net Of course, you can download any of the other builds if you prefer. > which could expose the company to huge licensing costs That's incorrect. The Oracle JDK is free to use. > all the users see is a pointless namespace change That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. Allowing a library that chooses not to be an official Java standard to pretend that it is is also unfair. The maintainers of that library have decided that it would be better to inflict that change on their users rather than remain a Java standard, and maybe they know what's best for their users.
    - cesarb 4y ago
      > That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. The libraries which did the namespace change are things like JAXB and JAX-RS and JAX-WS, which have been part of Java since Java 6. It's not some random third-party library, and Oracle did have control over them, until one day they decided they didn't want them anymore. As a part of Java, users did expect them to keep working (other than small changes like adding or removing a couple of methods, which became even less of a risk of breakage once Java 8 introduced default methods). The use of these libraries is pervasive all over the Java ecosystem, which leads to the complaint mentioned in the comment above: by first removing them on Java 11, and then forcing their new maintainer to rename the packages (instead of grandfathering them as an exception, or even better, providing an aliasing mechanism so that the renaming wouldn't break binary compatibility), Oracle broke some of the faith people had on Java's stability and backwards compatibility.

pron 4y ago

Oracle's "license change" was to open source the entire JDK for the first time in Java's history (although many people tried to make sure this was misunderstood, which wasn't helped by Oracle's poor communication -- now that's frustrating), and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. Even Oracle only uses the java/javax namespaces for JCP APIs. They claimed it was too inefficient, but Java SE churns out two specification versions a year through the JCP, despite them being bigger and more complex than Jakarta EE.

cesarb 4y ago
> Oracle's "license change" was to open source the entire JDK for the first time in Java's history The parent comment is most likely not talking about that. The "Oracles license changes" (plural) in question are things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license (see for instance https://houseofbrick.com/blog/oracle-java-pricing/ https://houseofbrick.com/blog/oracle-java-pricing/), or IIRC an earlier change to require a paid license for newer releases of Oracle JDK 8 (which AFAIK is the version most companies use). It's true that it's easy to avoid all of that by exclusively using OpenJDK instead of the Oracle JDK (but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK, and then you find out that it's no longer called AdoptOpenJDK, and now has an even weirder name), but it's also true that it's easy for an employee to end up downloading the Oracle JDK (especially when it's someone who learned Java back when the recommendation was to prefer the Sun JDK instead of an open alternative), which could expose the company to huge licensing costs. It can be less risky to just forbid the use of Java outside of carefully curated environments. > and we had no control over Jakarta's insistence to leave the JCP, Java's standards body that controls the javax namespace. It doesn't matter who is at fault; all the users see is a pointless namespace change, which breaks both source and binary compatibility for something which had been part of the JDK for many releases. To make things worse, it's not something which can be easily be worked around; when providing a library which can run with either the old or the new namespace, you have to provide two separately compiled JARs, and I've seen several popular projects take that path. It's very similar to the Python 2 to Python 3 transition, except that Python allows you to dynamically import a module at runtime (so you can easily create a compatibility shim), while with Java, the package names are fixed in the bytecode. The best workaround I've seen so far (though I haven't played with it yet) manipulates the class bytecode at load time to change the package names (https://github.com/eclipse/transformer https://github.com/eclipse/transformer).
- pron 4y ago
  > things like the recent change to count all employees (even the ones who do not use Java) when calculating the price for an Oracle JDK license AFAIK, the change to the pricing model for support was done at the request of Oracle's support customers, as it's easier for them to track. I don't know why non support customers would care one way or another. > but then you find out that you have to download from AdoptOpenJDK instead of downloading directly from OpenJDK The OpenJDK website's downloads link links here: https://jdk.java.net https://jdk.java.net Of course, you can download any of the other builds if you prefer. > which could expose the company to huge licensing costs That's incorrect. The Oracle JDK is free to use. > all the users see is a pointless namespace change That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. Allowing a library that chooses not to be an official Java standard to pretend that it is is also unfair. The maintainers of that library have decided that it would be better to inflict that change on their users rather than remain a Java standard, and maybe they know what's best for their users.
  - cesarb 4y ago
    > That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. The libraries which did the namespace change are things like JAXB and JAX-RS and JAX-WS, which have been part of Java since Java 6. It's not some random third-party library, and Oracle did have control over them, until one day they decided they didn't want them anymore. As a part of Java, users did expect them to keep working (other than small changes like adding or removing a couple of methods, which became even less of a risk of breakage once Java 8 introduced default methods). The use of these libraries is pervasive all over the Java ecosystem, which leads to the complaint mentioned in the comment above: by first removing them on Java 11, and then forcing their new maintainer to rename the packages (instead of grandfathering them as an exception, or even better, providing an aliasing mechanism so that the renaming wouldn't break binary compatibility), Oracle broke some of the faith people had on Java's stability and backwards compatibility.