[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.

[_hilro]

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]

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

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]

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

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]

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.