[pabl0rg]

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.

[pron]

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

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.

[mbfg]

things like jaxb were removed, which i'm guessing plays a part in the soap discussion above. Not that it is difficult to fix, but...

[pabl0rg]

Unfortunately, the only explanation I found for my troubles with SOAP and java 11 is found in the comments to this answer in StackOverflow: https://stackoverflow.com/questions/58319199/java-lang-class...

[baud147258]

> the removal of a handful of methods hardly anyone had used

when we moved from java 7/8 to java 11 two years ago, we didn't had any issue with our third-party libraries, but we had a few pieces of code, mostly related to encryption libraries, that failed to compile with the newest JDK

[keymone]

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

[mirekrusin]

It's a SOAP so flush down the toilet should do the trick.

[native_samples]

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]

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]

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.

[oauea]

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

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.

[AtlasBarfed]

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.

[chrisseaton]

Can you give any concrete examples of what broke?

[avereveard]

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.

[arid_eden]

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.

[ralphc]

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