10 ms·

Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear

Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. I’m not surprised that people seem to be leaving the ecosystem.

oauea 5y ago
> It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.
- Alupis 5y ago
  Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
  - _hilro 5y ago
    from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?
    - Alupis 5y ago
      > Not sure I follow why you had to turn to docker I didn't, and OP could have stuck with Java8 since it's LTS. So I'm not sure either where Docker comes into play. It seems the parent was deploying fat jars, and now due to the complications of all the various deps, they opted to use Docker images as a new "fat jar". Perhaps it simplified their build process, but that's just a guess. > The JVM is deterministic - I don't follow this statement? Custom classloading simply requires a string path and FQN of the class to attempt to load it from disk. Compile time checking doesn't validate the actual existence of the class, which is the point of runtime custom class loaders. A lot of plugin loaders are done this way, etc. So... your program might be humming along just fine until it classloads in a plugin (or whatever) that depends on Jaxb for example, then everything explodes since Jaxb is now a dep instead of built into the jdk.
      - _hilro 5y ago
        Sure but that's always been the case. Anyways, I had read your comment as: ~"Classloader loads class X fine one moment and then suddenly can't" which is why I mentioned deterministic.
        Alupis 5y ago
        > Sure but that's always been the case. Well, no it hasn't. Things like Jaxb, for example, have always existed in the JDK since they were introduced (java 1.2 in Jaxb's case). XML processing code compiled with jdk5 (circa 2004) still worked fine on java8, for example, with zero code or dep changes. Suddenly that assumption is broken with java9. > Anyways, I had read your comment as... It was just an admittedly contrived scenario where the upgrade path to jdk9+ wasn't as straight forward as just adding deps to maven and calling it a day, since you may not be aware of all code interactions, depending on the system you're upgrading. Your program might even have a dep on some jar that was compiled under jdk4 and the author and source are nowhere to be found (or went out of business a decade ago)... and suddenly it breaks under java9. Things like that are largely what prevented mass adoption of jdk9 immediately.
- AtlasBarfed 5y ago
  Simple Object Access Protocol... Simple: by the end I was dealing with self-signed bodies and validation, version hell, framework hell, and namespace super-hell. Object: um, not really. It was request/response. Nothing really "OOP" about it at all. Access: didn't really help much with access, that was all HTTP Protocol: There were so many protocols and frameworks attached to those protocols and versions of the protocols that ... in the end of the day, it had no protocol.
  - User23 5y ago
    The best thing about SOAP is that it drove industry-wide REST adoption. That had its own problems, but at least they were largely due to a failure of implementers to understand what using HTTP as an application rather than a transport protocol meant. And now we have GraphQL, which while it has its own faults[1] is far less unnecessarily complicated than SOAP and provides considerably more value. [1] Oh crap I’d forgotten about SOAP faults until I wrote that word. Please help me I’m having traumatic flashbacks.
native_samples 5y ago
Hmm, fat jars still work OK in latest Javas. What is the issue is with Jakarta multi-release JARs? A MR JAR is just a regular JAR with files in different directories. They should fat-jar together OK. There's certainly no requirement to start using Docker images!
- mumblemumble 5y ago
  The problem I've run into with mrjars is that they tend to break libraries that do a bunch of classpath scanning. Mrjars add some stuff to the classpath that the older tools didn't understand and would choke on. It's one of those things I would personally argue is a naughty hack that should be avoided if at all possible, but it's also something that's historically been ubiquitous within the Java ecosystem. It's frequently how convention-over-configuration dependency injection (as found in Spring Boot or Jersey) tends to be done, for example.
- pabl0rg 5y ago
  Specifically, I was unable to find the gradle shadow/maven shade rules needed to use the jdk9+ version of the multi-release dependency "com.sun.xml.ws:jaxws-rt:2.3.5". The reply I got on Stackoverflow from the person I think is the maintainer is "don't use fat jars", which is probably the correct solution, although most people use fat jars. Lately, I've been reading that layered docker images should be a faster way to build and deploy java apps that have many tens of MB of dependencies that never change. It only works if you don't use fat jars.
keymone 5y ago
The way to upgrade SOAP clients is to generously pour the office with gasoline and set it on fire.
- mirekrusin 5y ago
  It's a SOAP so flush down the toilet should do the trick.
  - occz 5y ago
    What are your gripes with SOAP? Genuinely interested. I've used it once professionally, and while there was an initial learning curve, it seemed to have some nice properties once you got past that.
    - keymone 5y ago
      http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
      - MathMonkeyMan 5y ago
        thank you for this
      - selcuka 5y ago
        That was exactly my sentiments back in 2000s. I had to use SOAP a few times, then switched to a semi-proprietary binary protocol called Hessian [1] (and its XML based sister, Burlap [2]) and it saved my day. [1] http://hessian.caucho.com/ http://hessian.caucho.com/ [2] http://hessian.caucho.com/doc/burlap.xtp http://hessian.caucho.com/doc/burlap.xtp
      - kaba0 5y ago
        This is a ridiculous website: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/ They should be using rocks instead of a computer with this mindset.
chrisseaton 5y ago
Can you give any concrete examples of what broke?
- avereveard 5y ago
  A lot of bcel/aspect code had to be rewritten. I've had to patch a couple transitive dependencies to bring a 2018 platform from Java 1.8 into Java 12 land, and it's stuck there forever since after 12 something else it depended on was removed. We're migrating to a simpler, saner runtime, but still, stuff takes time.
  - chrisseaton 5y ago
    > A lot of bcel/aspect code had to be rewritten. But why? What changed in the spec that forced a rewrite?
    - native_samples 5y ago
      Typical reason for this is that JVM changed bytecode parsing in a backwards-incompatible way (yes this happens frequently e.g. to fix validation bugs) and the fix for this was then only rolled into a new version of the bytecode manipulation library, but that in turn had its own set of API changes, regressions and bugfixes, meaning that now whatever code sits on top has to be changed, etc. Also most of the breaking changes from Java 8-11 are/were not spec changes. The spec leaves out many aspects of the Java platform that real apps rely on. This idea that only apps that used JVM internals broke is totally wrong. I think the guys who work on Java think this because they don't actually use or work on any Java apps themselves beyond the ones that are a part of the JDK itself.
      - avereveard 5y ago
        Exactly, it's not always easy to replace a transitive dependency and we're dismissing the platform anyway
      - chrisseaton 5y ago
pron 5y ago
> But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. The main backward incompatible changes between 8 and 9 were the changing of the version string to remove the "1." prefix, and the removal of a handful of methods hardly anyone had used. In other words, the chances of spec-compliant code that ran on 8 failing on 9 were slim. What happened was that in the long 8 timeframe, many libraries -- for various reasons, some reasonable -- have circumvented the Java spec and hacked into JDK internals, making themselves tightly coupled to 8. When internal classes changed in 9, those non-portable libraries broke, and so did their clients. Now that strong encapsulation is finally turned on (as of JDK 16), this shouldn't happen again. There were some significant breaking changes to the spec in 11, but those comprised separating modules from the JDK into external dependencies, and didn't require any code change.
- malfist 5y ago
  I remember there were a lot of libraries that were part of the jdk that got decoupled and no longer included in the move from java8 to java9. I specifically remember this impacting anyone who parsed xml or json. I vaguely remember it being something in the javax.validation package. My company migrated from 8 to 11 but we had a lot of headaches around those libraries that were pulled out of the jdk. To be fair, those should not have been coupled to the jdk in the first place, but it did break backwards compatibility which was a cardinal sin for java.
  - iainmerrick 5y ago
    For a lot of people, Java is mainly used to turn XML files into stack traces, so breaking backwards compatibility in XML parsing is a big deal! Although, if it gives you a stack trace even faster than before, I guess it could be considered a performance improvement...
    - vbezhenar 5y ago
      XML parsing works just fine. It's SOAP and some other classes that were dropped. I'm not sure if that's a real problem. All it takes is to add few dependencies to pom.xml.
ralphc 5y ago
Where are they going to? I've been out of the Java loop for a few years, maybe they landed where I did.
arid_eden 5y ago
They removed webstart - which is fundamental to how the apps we use are distributed. I believe that reason alone is why the distributor has stuck to Java 8/OpenWebStart.

oauea 5y ago

> It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.

Alupis 5y ago
Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
- _hilro 5y ago
  from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?
  - Alupis 5y ago
    > Not sure I follow why you had to turn to docker I didn't, and OP could have stuck with Java8 since it's LTS. So I'm not sure either where Docker comes into play. It seems the parent was deploying fat jars, and now due to the complications of all the various deps, they opted to use Docker images as a new "fat jar". Perhaps it simplified their build process, but that's just a guess. > The JVM is deterministic - I don't follow this statement? Custom classloading simply requires a string path and FQN of the class to attempt to load it from disk. Compile time checking doesn't validate the actual existence of the class, which is the point of runtime custom class loaders. A lot of plugin loaders are done this way, etc. So... your program might be humming along just fine until it classloads in a plugin (or whatever) that depends on Jaxb for example, then everything explodes since Jaxb is now a dep instead of built into the jdk.
    - _hilro 5y ago
      Sure but that's always been the case. Anyways, I had read your comment as: ~"Classloader loads class X fine one moment and then suddenly can't" which is why I mentioned deterministic.
      - Alupis 5y ago
        > Sure but that's always been the case. Well, no it hasn't. Things like Jaxb, for example, have always existed in the JDK since they were introduced (java 1.2 in Jaxb's case). XML processing code compiled with jdk5 (circa 2004) still worked fine on java8, for example, with zero code or dep changes. Suddenly that assumption is broken with java9. > Anyways, I had read your comment as... It was just an admittedly contrived scenario where the upgrade path to jdk9+ wasn't as straight forward as just adding deps to maven and calling it a day, since you may not be aware of all code interactions, depending on the system you're upgrading. Your program might even have a dep on some jar that was compiled under jdk4 and the author and source are nowhere to be found (or went out of business a decade ago)... and suddenly it breaks under java9. Things like that are largely what prevented mass adoption of jdk9 immediately.
AtlasBarfed 5y ago
Simple Object Access Protocol... Simple: by the end I was dealing with self-signed bodies and validation, version hell, framework hell, and namespace super-hell. Object: um, not really. It was request/response. Nothing really "OOP" about it at all. Access: didn't really help much with access, that was all HTTP Protocol: There were so many protocols and frameworks attached to those protocols and versions of the protocols that ... in the end of the day, it had no protocol.
- User23 5y ago
  The best thing about SOAP is that it drove industry-wide REST adoption. That had its own problems, but at least they were largely due to a failure of implementers to understand what using HTTP as an application rather than a transport protocol meant. And now we have GraphQL, which while it has its own faults[1] is far less unnecessarily complicated than SOAP and provides considerably more value. [1] Oh crap I’d forgotten about SOAP faults until I wrote that word. Please help me I’m having traumatic flashbacks.

native_samples 5y ago

Hmm, fat jars still work OK in latest Javas. What is the issue is with Jakarta multi-release JARs? A MR JAR is just a regular JAR with files in different directories. They should fat-jar together OK. There's certainly no requirement to start using Docker images!

mumblemumble 5y ago
The problem I've run into with mrjars is that they tend to break libraries that do a bunch of classpath scanning. Mrjars add some stuff to the classpath that the older tools didn't understand and would choke on. It's one of those things I would personally argue is a naughty hack that should be avoided if at all possible, but it's also something that's historically been ubiquitous within the Java ecosystem. It's frequently how convention-over-configuration dependency injection (as found in Spring Boot or Jersey) tends to be done, for example.
pabl0rg 5y ago
Specifically, I was unable to find the gradle shadow/maven shade rules needed to use the jdk9+ version of the multi-release dependency "com.sun.xml.ws:jaxws-rt:2.3.5". The reply I got on Stackoverflow from the person I think is the maintainer is "don't use fat jars", which is probably the correct solution, although most people use fat jars. Lately, I've been reading that layered docker images should be a faster way to build and deploy java apps that have many tens of MB of dependencies that never change. It only works if you don't use fat jars.

keymone 5y ago

The way to upgrade SOAP clients is to generously pour the office with gasoline and set it on fire.

mirekrusin 5y ago
It's a SOAP so flush down the toilet should do the trick.
- occz 5y ago
  What are your gripes with SOAP? Genuinely interested. I've used it once professionally, and while there was an initial learning curve, it seemed to have some nice properties once you got past that.
  - keymone 5y ago
    http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
    - MathMonkeyMan 5y ago
      thank you for this
    - selcuka 5y ago
      That was exactly my sentiments back in 2000s. I had to use SOAP a few times, then switched to a semi-proprietary binary protocol called Hessian [1] (and its XML based sister, Burlap [2]) and it saved my day. [1] http://hessian.caucho.com/ http://hessian.caucho.com/ [2] http://hessian.caucho.com/doc/burlap.xtp http://hessian.caucho.com/doc/burlap.xtp
    - kaba0 5y ago
      This is a ridiculous website: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/ They should be using rocks instead of a computer with this mindset.

chrisseaton 5y ago

Can you give any concrete examples of what broke?

avereveard 5y ago
A lot of bcel/aspect code had to be rewritten. I've had to patch a couple transitive dependencies to bring a 2018 platform from Java 1.8 into Java 12 land, and it's stuck there forever since after 12 something else it depended on was removed. We're migrating to a simpler, saner runtime, but still, stuff takes time.
- chrisseaton 5y ago
  > A lot of bcel/aspect code had to be rewritten. But why? What changed in the spec that forced a rewrite?
  - native_samples 5y ago
    Typical reason for this is that JVM changed bytecode parsing in a backwards-incompatible way (yes this happens frequently e.g. to fix validation bugs) and the fix for this was then only rolled into a new version of the bytecode manipulation library, but that in turn had its own set of API changes, regressions and bugfixes, meaning that now whatever code sits on top has to be changed, etc. Also most of the breaking changes from Java 8-11 are/were not spec changes. The spec leaves out many aspects of the Java platform that real apps rely on. This idea that only apps that used JVM internals broke is totally wrong. I think the guys who work on Java think this because they don't actually use or work on any Java apps themselves beyond the ones that are a part of the JDK itself.
    - avereveard 5y ago
      Exactly, it's not always easy to replace a transitive dependency and we're dismissing the platform anyway
    - chrisseaton 5y ago

pron 5y ago

> But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. The main backward incompatible changes between 8 and 9 were the changing of the version string to remove the "1." prefix, and the removal of a handful of methods hardly anyone had used. In other words, the chances of spec-compliant code that ran on 8 failing on 9 were slim. What happened was that in the long 8 timeframe, many libraries -- for various reasons, some reasonable -- have circumvented the Java spec and hacked into JDK internals, making themselves tightly coupled to 8. When internal classes changed in 9, those non-portable libraries broke, and so did their clients. Now that strong encapsulation is finally turned on (as of JDK 16), this shouldn't happen again. There were some significant breaking changes to the spec in 11, but those comprised separating modules from the JDK into external dependencies, and didn't require any code change.

malfist 5y ago
I remember there were a lot of libraries that were part of the jdk that got decoupled and no longer included in the move from java8 to java9. I specifically remember this impacting anyone who parsed xml or json. I vaguely remember it being something in the javax.validation package. My company migrated from 8 to 11 but we had a lot of headaches around those libraries that were pulled out of the jdk. To be fair, those should not have been coupled to the jdk in the first place, but it did break backwards compatibility which was a cardinal sin for java.
- iainmerrick 5y ago
  For a lot of people, Java is mainly used to turn XML files into stack traces, so breaking backwards compatibility in XML parsing is a big deal! Although, if it gives you a stack trace even faster than before, I guess it could be considered a performance improvement...
  - vbezhenar 5y ago
    XML parsing works just fine. It's SOAP and some other classes that were dropped. I'm not sure if that's a real problem. All it takes is to add few dependencies to pom.xml.

ralphc 5y ago

Where are they going to? I've been out of the Java loop for a few years, maybe they landed where I did.

arid_eden 5y ago

They removed webstart - which is fundamental to how the apps we use are distributed. I believe that reason alone is why the distributor has stuck to Java 8/OpenWebStart.