In the spirit of the new year, this article on the current state of Java tries to list a few resolutions for the platform. The author discusses his perceived weaknesses, and goes on to give a remedy.
His ideas include:
- Expand what ships with J2SE
- Best-of-breed everything
- Deliver a consistent technology message
- Embrace Windows as the client deployment platform of choice
- Position the Java platform as a blank canvas for other technologies
- JCP lite
What do you think of his ideas? Where is he missing the mark?
Read In pursuit of perfection: Can Java become the perfect technology platform?
Interesting article. The author seems to seek support for the occupational programmer. I conclude this from his call to make Java more accessible to both novices and experts
The "Occupational Programmer" is defined by many as the business user who knows enough programming logic to extend his/her documents or processes with some very specific, targeted application logic. Sun has actually alluded to this tactic in its stated goals of increasing the number of Java developers to 10 million over the next several years. However, this goal starts to change the accepted definition of what a "Java Developer" really is. If you're thinking of the obvious parallels with Microsoft and Visual Basic, then you're correct because that's exactly what they've done for many years by making Visual Basic available in their Office Products (and just lowering the entry point to VB in general).
It will be interesting to see if that ever plays out. The simplification and proliferation of Java Everywhere comes with a price, and that price is a dilution of the true programmer and developer community. I think this is a paradigm shift in the Java community that would receive the most widespread resistance (now you too can have secretaries creating applications :-) Of course, I really don't see Sun asking for permission to start enabling Java macros, etc. from within StarOffice documents.
in a nutshell - yes, although when I was writing the article I wasn't thinking along those terms. What I'm advocating is an entry point into Java programming, be it with StarOffice integration or a scripting language like Groovy or a "friendlier" IDE like BEA Weblogic Workshop for __beginners__.
Then, to borrow a phrase from eXtreme Programming, more experienced developers can turn all the complexity and power knobs up to ten via IDEs like Eclipse, Netbeans, using the JPDA, coding for the J2EE directly etc. Experienced developers still have access to the intricate platform details that they need, but occupational programmers gain a foothold too.
PS I'd like to clarify one point - I'm advocating that Java Swing applications provide much better support and performance on the Windows platform, but not at the expense of cross-platform compatibility. Ideally via a two-pronged approach:
* a modified J2SE implementation on Windows that embeds Java more deeply into the OS (a la SWT native look and feel + performance); and
* an extended API for Windows that allows developers to take advantage of Windows specific functionality when their application is run on a box running a Windows OS - javax.microsoft.windows.* or equivalent.
Hopefully it didn't sound as if I was trying to put words in your mouth, or article as the case may be. I was engaging in some derivative logic there with the response.
One thing I do wonder thought that you might clarify: does this approach not also threaten to fall into the trap of Java trying to be all things to all people, implied to me as a drawback in your section addressing weaknesses of Java. I definitely think that Java and J2EE can provide a more accessible entry point to gifted but inexperienced programmers than it does now, but how do you think would be the smartest way to do this without falling into the trap of "dumbing down" Java? Or do you disagree that lowered accessibility carries that negative connotation?
Didn't SUN sue MS for doing just that?
No, it was the delegate keyword that Sun sued MS for...
I agree with most of the java weaknesses you outlined except for the first; Having new "hourly" frameworks is mostly a good thing - even when they compete for the same space and confuse the java community.
Firstly, it is impossible to agree upon one framework and to rally around it as a community. I have a hard time getting 2 people to agree on tab sizes (3 or 4 spaces?) for coding standards. Secondly, developping frameworks is more of an art than a science. Determining the best way to do something is often a question of trial and error. The best ideas perculate to the top when hundreds of thousands of people use a technology and realize that after a year or 2 (and thousands of TSS posts), a better way may exists. You need to go thru the pain of unit testing an EJB to appreciate the beauty of POJOs and IoC based containers. That pain could not be predicted at Sun when the ejb spec was being designed.
So if it takes an "arms race" to get to better frameworks, at the cost of not always having all the answers as a J2EE architect, let the race begin.
Keeping it simple. That's the big one that I agree with completely. The J2SDK is becoming so bloated and app servers so heavyweight that it's becoming difficult to do rapid development. I'm almost for breaking up the J2SDK down to the 1.2.2 level again and just incorporating XML and even JDBC, etc as individual libraries again. Use only what you need.
I'd also like an app server that can mix and match only what you want. For example, if I were to build an application that required only JMS for messaging and JDBC for database interaction during messaging, I'd like an app server that only has a microkernel and allows me to plug in JMS, JDBC, and allows me to ignore the rest. Instead with any app server you get all this bloat re: configuration and loading of elements that you may not have to use based on your own specific business requirements.
Just my 2 cents.
Java surely needs a good dose of the KISS principal, but I fear by "dumbing down" the platform for the benefit of public image can only add to the overall confusion. For example, to a parametric user with a mobile handset Java is a cutesy game - to a desktop user it's a (sluggish) Swing application - to a developer it's a labrynth of API's and classpaths - and to an architect Java is a host of "what-if?'s".
<br> KISS, in my opinion, is about making things simpler, not simplistic. One should never imagine that the future success of Java will depend on whether everything about it is understood by everyone, or understood simply.
<br>What really matters is that someone knows which door to walk through, and then has help with which turns to take. I agree that Sun needs to take the lead, and forget how to dominate .NET in the political arena, and focus on helping guide the developer through the minefield of confusion (another web framework was published during the time it took me to read the article!), thereby implementing business cases more productively, which improves the final product, and satisfies the end user. Isn't that what it's about???
<br> With Java we have choice. Choice is good, but making GOOD choices is not easy.