Over-design and dependencies

I've read some discussions lately about over-design. I think it started with a rather funny post by Adam Bien, and it is currently a hot topic at JavaLobby.

Although I hardly ever participate in these discussions, it is good to have them. From time to time, we need to think about our methodologies, approaches, code, (anti-)patterns.

In general, I think there is some improvement. I see less and less code that is in my opinion over-designed. One of my favorite over-design criteria is a separate package for Exceptions, and using these Exceptions as control-flow logic. I almost immediately remove these projects from my hard disk, and I don't have to do this too often lately — compared with some 5 years ago.

One of the comments on the article on JavaLobby confirms my issue number one (although it doesn't really belong in the category over-design):
10. Your project is going to end up with half of this planet's jar-files in tow.
I agree. I don't understand why a 50-line piece of code needs 50+ MB's external jar-files, that contains functionality that is mostly covered by the standard Java classes. The Java SE API's are very rich today, I really recommend using them instead of some legacy libraries that originated during the JDK 1.1 life.

Inside or outside the browser? I don’t care.

Recently, I have been following some discussions about the browser being the center of the Internet experience or not. Are we going to see more functionality available in browsers, or are we moving to a world where more stand-alone applications are running outside the browsers? To be honest, I don't care.

I still remember the first time I saw the NCSA Mosaic Web Browser, almost 15 years ago. This product was a milestone in Internet history. End-users could easily browse web-pages and navigate from one site to another. At that moment, few realized that this piece of software would become the master-piece in PC environments.
After 15 years, however, I think it is time to reconsider the role of web-browsers in the networked environment. Downloadable software often comes in two variants: a browser-based version, that acts as a plugin in a browser, and a stand-alone version, that runs outside the browser.

What we see is that two of the most important "plugins" to the browsers, Adobe's Flash/Flex/Air and Sun's Java Virtual Machine, are both offered in a browser-environment as well as in a standalone environment. I think this is really smart. Developers (both Air as well as Java developers) do not have to worry too much in which environment their application is running.

Java SE 6 Update 10 is a major step in this direction (see the early access page for more info about the features of Java SE6U10). Two of the most important features are the "Next-Generation Java Plug-In" and the "Unify Browser and Desktop Experience". With the latter feature, users can drag an Applet from the browser to the desktop. From a technical point, this makes sense. The Virtual Machine that is launched by the browser is exactly the same VM that can be launched manually. As a consequence, Java programs that run in a browser can also run stand-alone, and vice versa.
The demonstrations that I have seen so far mainly focus on the usability of this feature: users drag an applet from the browser to the desktop, close the browser and continue working with the applet.

If you think about it, it is also a major step into the direction of "Write once, Run Anywhere". As a Java developer, you don't have to worry about whether your application is going to be executed inside a browser or as a standalone application.
Also, the browser is not a competitor of a standalone Java application. In a number of mobile projects that I am aware of, the browser is considered as a candidate for the heart of the user experience. As long as this browser is capable of launching a JVM, this is no threat to a complete Java-based environment.
The point is, users need interactivity, dynamic capabilities, and other features that are available in the Java language. How they are presented (in a browser or stand-alone) is probably extremely important from a usability point of view. But for a developer, it doesn't matter that much.

Why Java? Because it’s everywhere.

As a Java developer, this discussion sounds familiar to you. Every now and then, you have to answer this question from customers, your marketing people, fellow developers,… . My personal answer on this question is shifting a bit from the "Enterprise advantages" to the "Mobile opportunities". I see the same shift in other pieces of software, including GlassFish v3.

One of the most important advantages that Java has over e.g. scripting languages is the built-in infrastructure allowing for transactions, clustering, scaling. These are mainly the benefits of the Java EE platform, and they can not be underestimated.
One of the characteristics that I tend to value more and more, is the transaction management. I can hardly imagine not to have a rollback of a complete method. If you call a method on a session bean, and something goes wrong at the very end of the method, you often want the system to be in the state it was in before the start of the operation. Easily solved with transactions in JavaEE, but I wonder how people solve this in other languages?

The value of this enterprise capabilities is still very high, and in my opinion, it is one of the most important differentiators of Java. Once you know how to deal with it, it saves you lots of time in development and production.

In the near and mid-term future, I expect that the "write once, run anywhere" principle becomes more important. For a long time, I considered the fact that Java runs on over 2 billion devices mainly a marketing trick. However, if you think about it, this is one of the major advantages of Java.
I was recently in a discussion about which mobile device or PDA would make it. Will mobile phones evolve in the direction of PDA's, or is it the other way round? Very difficult to predict (at least for me). The thing is, I don't have to worry. They both run Java. The same language I use for enterprise software development is used on mobile devices. Of course, the external API's that are used are not always the same. But the Java syntax, mainly the java.lang package and the way of programming are the same. As Java developers, we don't have to worry about the outcome of the battles between the mobile phone companies.

Using the same programming language on high-end backend servers and resource constrained mobile devices is not trivial. Being first class in both domains, is far from trivial. But the Java language is doing a great job in both areas.
One of the major characteristics of the current GlassFish v3 software is that it starts up quickly. After less than a second on a laptop, you don't have all the functionality that you typically expect from enterprise servers. But in many cases, you don't need all this functionality. You just want the same principles to apply whether you are working on an enterprise project or on a mobile project. And that is where GlassFish v3 is heading to. The core is the same for mobile and enterprise, the programming methodology is the same. GlassFish is moving from the Enterprise to mobile (without ignoring the enterprise). OSGi , on the other hand, has been moving from mobile to the Enterprise. It is not a coincidence that GlassFish and OSGi have met each other.