Moreover, Java on the web (first in the form of JSPs, later Spring-based frameworks) was largely a reaction the shortcomings of LAMP, which was largely a reaction to the shortcomings of Perl5 CGI-BIN (what I consider to be the first widely-used web framework). The great irony is that Perl had an advanced dependency management system in CPAN in the mid-1990s and PHP had nothing for years. Ruby on Rails succeeded largely by combining a CPAN-like dependency management system with a web-native development framework.

I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.

Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.

Yet, java was (as someone recently disparagingly put it) "designed by adults". By people familiar with state of the art language research, what was needed and workable, comprehensive specs of language and VM, and complete stdlibs, docs and tools from the get-go. (That is, disparaging to other languages)

And it's also managed to keep up to date, much better than I'd ever have thought: fast JVMs, language evolution, stdlib extended - and perhaps the greatest number of 3rd party libraries of any language ever(?).

Oracle is wrecking that for EE, and may wreck more.

Then, there's the Sun/Oracle thing... While Sun was still pretty respected, being associated with Oracle feels like a wolf trying to befriend a chicken. Especially coming from the open-source perspective, I'd rather not deal with them. If design-by-committee wasn't bad enough, the control of a company like Oracle should set off some alarms...

Old version had almost all the logic in PL/SQL, some Qt forms for high-level management, and C++ console apps (warehouse processes) running on portable terminals through telnet (so in reality these were running on the server, and portable clients were telneting to it to control it).

First we introduced XML-based protocol between C++ app and portable terminals, and a .net client running on these terminals to replace telnet. This allowed for a simple graphical interface instead of text-only, so there was a good motivation for customers to upgrade. Also it separated the parts clearly and allowed to mix and match new and old parts in the system.

Then we introduced J2EE application server, exposed the database through hibernate, and new processes were written in java (jbpm to be specific). They still used the same XML protocol and .net client, so old C++ processes could call java processes and vice-versa.

New processes required the possibility to call PL/SQL logic so the features that were needed were exposed through J2EE services to the java processes.

Finally we added a way to write new management forms in Eclipse RCP.

We also planned on moving the logic from PL/SQL to J2EE completely, and becoming database independent, but we never got to that.

The rewrite was never completed, there was a merger in the meantime, and we switched tech again, at which point most of the team left :)

But what we finished was working reliably, no features were lost, and as far as I know some customers still use the old system, some use both, some use the new system.

The thing that made it easy to do, but also hard to finish - was the logic in PL/SQL. As long as we left that be it made moving everything else easy. But at the same time it was a constant temptation to just call the old PL/SQL function instead of writing a new J2EE service, and finish the task at hand faster.

The other problem is that Smalltalk is pretty alien to a Java programmer (image vs. text, block based control flow vs. traditional control flow). Garnett and Forester's recommendations might be key.

Although, I still would argue the premise and say most of these institutions know Oracle and understand dealing with them. I don't see people giving up their Oracle databases and having bundled, recommended Java might make Java more of a lock.

But then Oracle moved their Forms client to Java, creating all kinds of versioning headaches and security risks. They should have stuck with the dedicated stand-alone EXE Forms client: a kind of GUI browser. It was a very practical tool for in-house and specialty apps, but Oracle ruined it with Java.

This makes me thing that Java is better for this kind of big "enterprise" application, not because it's faster or more enterprise or somesuch, but because it's more limited, and therefore less things can go wrong.

I worked in two banks, developing web banking in one and middleware service in the other, and while there were some strange things (what's with banks and XML, really?) there was nothing that terrible here.

But then I'm pretty sure that someone will share their Java horror story.

I don't think you actually have much understanding of enterprise environments otherwise you would know how ridiculous the idea that Go or C# is going to take over from Java anytime soon.

But was your choice to learn Java somehow related to it being popular in industry?

More so in the past, portability - meaning not being locked-in to a specific vendor who could then screw you - was a big deal in industry. Today, there's much less heterogeneity (x86, ARM and...?).

Part of Oracle's pitch for their database was that they ported it to different machines, so users weren't locked in (even if they didn't actually use it on different machines).

The long short of it is we aren't a booming industry and we do it for the money so one less vendor we have to send a 7 figure check to will only increase the bonus pool.

Back then I did devops for a moderately sized stocks platform with real time ticks and charting, the works. We had two large code bases, one in perl, one in Java.

They both were bad times.

Java, because the java coders didn't quite understand how threading worked, leaking all over the place. My job was to migrate the systems from AIX 64bit machines (that could deal with the memory leaks with only one restart per hour) to x86 Linux. It was kind of fun (because everything was pretty contained) until the stuff went into production, and the servlets died after 4-5 requests each under non synthetic load.

And Perl, because the perl coders thought it was of benefit to write code that nobody could read but the author, and that it was OK to have dependencies on very old and very new libraries at the same time.

I gotta admit, the Perl stuff ran more stable. But it was still hell to upgrade the machines or debug even the smallest issues.

And Java wasn't always the enterprise thundergod we know and respect today.

But in general, sure. It's not as common as other migrations.

All I am saying is that good management is to look at the risks of sticking with Java and find a migration path earlier, because the longer you wait the more expensive it becomes to move away. And one day you will find you have no choice, and then it will be very expensive.

It is possible to maintain and even add essential features to a legacy system whilst migrating to a new system. Happens all the time.

During the explosion of the web, enterprises moved much of their development into web solutions using an existing workforce that had skills in different technologies - often client-server desktop-to-RDBMS tech. Java was a popular choice for these new projects. Those developers would range in their general aptitude - some were quite good, some weren't - but they all came onto these projects with existing skills and knowledge in patterns and architectures that weren't particularly well aligned with web development. They were expected to adapt and deliver at pace consistent with their previous projects. So they did what they could to get the job done, even though that meant that their solutions were not well suited to the web environment. That doesn't have a lot to do with Java specifically, except that it was a common language for that situation. It was far more common for enterprises to take VB/PowerBuilder/Delphi/etc Devs and move them into Java than something like PHP.

But Java was more likely to produce this horrible implementation for a couple of reasons.

Firstly, as a general purpose language (that also happened to have decent web capabilities?) it was easy to design? an application using your traditional patterns and then just shoe-horn the web UI on top. You were far less likely to do that in a web-oriented platform like PHP or ColdFusion (!).

Secondly, the Java servlet spec makes sessions really easy (because it stores standard, stateful, Java objects) and didn't offer a lot for managing complex page state. You could spend several days trying to build something to page through database search results with query parameters, only to find that the back button broke your design. Or you could just throw it all into the session, and call it "done".

That probably peaked about 15 years ago, but inertia is a strong force, particularly in government and large enterprises. Some of those developers are probably still working like that. Some of them trained others. And many others know that it's a bad design, but there's no budget to fix it.