I'm surprised that it's now common for software to require a certain (old) Java version.
Wasn't the whole "write once run anywhere" promise about backwards compatibility too?
Wasn't the whole "write once run anywhere" promise about backwards compatibility too?
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.
> 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.
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.
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?
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.
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.
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.
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.
[1] Oh crap I’d forgotten about SOAP faults until I wrote that word. Please help me I’m having traumatic flashbacks.
There's certainly no requirement to start using Docker images!
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.
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.
http://harmful.cat-v.org/software/
They should be using rocks instead of a computer with this mindset.
Why would it be ad hominem (which is not even that)? Also, the link I posted is even about the same topic, not unrelated - so a logical flow in that one (and it has plenty) will easily apply just as well to an elaboration of one of the listed contenders on this page.
Just getting code updates on our old java websites makes me realize why all the new stuff is arguably slower php and python..
As long as you're running the same code on both ends it sort of works. It's still over engineered to the moon and back, and a major pita to deal with, but at least the damn thing works.
Anything beyond that fails in spectacular ways.
It will not be missed.
Delving under the XML hood can be painful.
It's very easy to overengineer. Both the SOAP WS-* extensions, and the underlying XML.
The tooling and ecosystem suck. I found it a lot more difficult to use clients like soapUI as opposed to just banging on a REST API with curl. The libraries are mostly java, with at least one c/c++ implementation. I had a lot of trouble getting different libraries to work together. And that's literally the entire point of SOAP. It's supposed to be the enterprise grade interoperability (of course, a huge oxymoron) compared to REST.
I spent a few years working on SOAP for a telecom. Not pleasant.
Please mention a few of these problems, I'm curious to hear.
The problem I see with REST/JSON-APIs is that they lack features that have to be tacked on after, creating an endless bikeshedding nightmare and instead of having one well-thought out solution, you get three or four solutions sloppily hacked together. Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language, i.e. really bad) or tack them on after the fact with something like OpenAPI, which is honestly not great as far as schema languages go.
Again, I say this as someone who has professionally used SOAP only once, and very briefly at that. Not advocating that we should re-adopt SOAP - I think that ship has sailed since long ago - but I really want to understand its opponents opposition to the positive qualities it appears to have.
> Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language)
The problem with SOAP is that it seemed to be designed by multiple committees with different agendas. From my imperfect memory, it's not just different versions of SOAP you have to contend with, but also different variants of schema flavors. Consequently, different languages and even libraries would have implementations that might support x but not y schema feature. It was an annoying compatibility nightmare, where you needed an additional complicated tool to verify it all.
Yes, JSON/REST have their own issues, but it's nothing that good documentation can't solve, and it's supported across most if not all major programming languages. Simplicity is often very underrated.
I’m no fan of that, but unfortunately we are forced to use some such SOAP services.
But why? What changed in the spec that forced a rewrite?
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.
People don't execute specs, they execute implementations. In the end whether something is or is not fully compliant with the spec doesn't change the costs involved in fixing it.
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.
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.
Although, if it gives you a stack trace even faster than before, I guess it could be considered a performance improvement...
I'm not sure if that's a real problem. All it takes is to add few dependencies to pom.xml.
But it was worth it. Got us access to the java flight recorder which is an awesome debugging tool.
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
1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE
2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break
3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck.
4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8.
Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things.
At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap.
[1]: https://docs.gradle.org/current/userguide/toolchains.html
There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them.
Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.
Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up.
It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that.
> JavaEE stuff was removed from the JDK and then re-namespaced,
JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere.
> they moved some stuff out of Unsafe
out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx).
It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
> The answer to this question is almost certainly "no".
For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI.
The older version we had used HTML.
I wonder how effective ancient monitoring software is.
The workaround is actually part of the software itself (there are instructions right below the login box).
My understanding is they're only upgrading because the old version didn't support modern versions of TLS, and there's a big push to get off of those. Finding new monitoring software would be probably be more work. At a minimum, the new version probably supports all the features we're using, and at best all our configuration can be automatically migrated. I don't know the details: I'm not part of the project, I just have an some apps with some monitors setup for them.
> I wonder how effective ancient monitoring software is.
It gets the job done.
If you ever peek at the software some industries are running, you may find yourself extremely surprised. A lot of it is incredibly specific, and truly terrible.
edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license
It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.