Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
Page 2 of 5
I'm interested in analyzing Java as a platform, however; and in that context, the Java language actually plays a smaller role than the overall platform itself.
Having set the scope of the analysis, I now move on to define the most important features of any platform.
This list can either be very long and detailed or short and sweet. I'm going the short and sweet route. Interested readers can note that the very long and detailed list has a lot of words that end with "ility," also known as the ility matrix.
In my opinion, any potential candidate for the perfect technology platform must:
Now that I've defined a set number of characteristics, let's see how Java shapes up when compared to this list.
To be brutally honest, Java is not particularly easy to develop for. Simple projects are fine, but as projects grow in complexity, infrastructural issues cause more and more problems. A good example is working with Java 2 Platform, Enterprise Edition (J2EE) application servers. Proportionally, I spend more time tracking down issues such as classloading problems than debugging actual business logic coded in Java. In addition, the disquiet felt by programmers around Enterprise JavaBeans (EJB) in general (see my past article, "To EJB, Or Not To EJB?") is a clear warning sign that EJB may be simply too complex and has not taken root as the de facto persistence or business logic solution for J2EE applications. This point also speaks to tool support for the Java platform, as opposed to any weakness in Java technology itself. Bluntly speaking, Microsoft leads the way with Visual Studio, and Java needs to catch up.
My earlier reference to multiple access levels means allowing developers/users to work with Java technology as befits their level of technical expertise. Hard-core developers can use emacs/vi plus a command-line debugger to develop and deploy Java-based systems, while business analysts or even end users should be able to access and modify systems within reason using WYSIWYG tools.