posted 2 months ago
One of the signal strengths of Java was the development of the POJO - the Plain Old Java Object.
As Sun originally envisioned them, there were indications that toolkits would be available to allow Java development to be done DDD-style (Drag, Drop, Drool), similar to efforts such as those by Microsoft. But for whatever reason, that concept was never actively pursued.
Enterprise JavaBeans, on the other hand, were horrible in large part because they were not POJOs. They were extremely delicate and could only be used in limited environments. Sun realized their error and future efforts such as EJB3 and JavaServer Faces were designed to be POJO-based.
However, as this was happening, third-party frameworks with similar ideals were being developed. Spring is arguably the best-known of them. At its core, it provided a central factory for POJOs - plus had the ability to source many types of non-POJO pbjects. Then they leveraged that by adding module families such as Spring Data until a complex but very usable ecosystem had emerged.
EJB had its own redeeming moments, the greatest of which was the fact that you could subset it and use the Java Persistence Architecture part in virtually any runtime environment. And in fact, Spring Data can itself leverage that via the Spring JPA module which I have used for many a successful project.
Spring did have another virtue over the original EJB at least, which was that it was purported to provide better persistence transaction management. As to whether that still applies or not, I cannot say, since I've never needed them myself.
Java retains its popularity because it has always enjoyed the support of Big Business. It offers better security than almost any other language, good performance, lots of libraries from both commercial and open-source offerings and - from a business standpoint - has one of the best "future-proofing" capabilities around. What made me give up in disgust on Microsoft languages more than anything was that a program you ran last week might not execute at all this week, as their tools were constantly mutating with little-to-no legacy support. Java, on the other hand has marked the Day(month, day, year) constructor as deprecated for probably 2 decades or more and the worst that will happen if you use it anyway (old code, of course, you'd never use it in new code, right?) is that the compiler will whine at you. And that's not even considering the backwards-compatibility computer and runtime options.
It's possible that in another Universe, we might be saying this about the Ada programming language, instead, but Ada came out around 5 years before Java and it made similar demands on hardware, though the hardware of the day was less capable. I took an Ada course around 1989 and the load it put on a mid-sized IBM mainframe just to compile was about what I got compiling Fortran on a 4MHz Z-80 microcomputer.
But there's a lot to like about Ada despite its relative lack of popularity and anyone interested in exploring can use the "gnat" system available on most PC platforms.
The problem with getting rid of the "undesirables" is that sooner or later someone will decide that YOU are an undesirable.
1
