Tag Archives: java

Application Servers Gone By: Do you remember JRun?

For the oldies like myself who remember JRun 🙂
JRun has a good history. Developed by Live Software, then bought by Allaire, which was bought by Macromedia, which was bought by Adobe, I wondered many times about JRun core employees (if there were any) who probably sat on the same desks for years even though their name badges changed logos. A classic case of abandonware.

Anyhow, you may wonder this sudden nostalgia. Since it was discontinued in 2006, I didn’t think that anyone would be using it now, however, while navigating the Washington Gas page (washgas.com), I came across this error message which might explain. I always thought that giving away your application server can open you to a security vulnerability, but maybe that’s just me. (Or perhaps I have just given a sales lead to IBM/Oracle?)

WashGasUsesAdobeJRun

In case you thought English didn’t matter since you are only a Java developer..

Just in case you thought English didn’t matter for you, because you are only a Java developer, think again..

// These two Java comments mean entirely different things:

// First determines whether this enrollment application is valid or not.
// First determine whether this enrollment application is valid or not

YAGSC (Yet Another Grails Struts Comparison)

I have recently been inundated by emails about Grails (mostly good, some neutral, some outright complaints), even though my email inbox isn’t much different from a certified black-hole. The great divide seems to be part philosophical and part technical. There are already quite a few technical comparisons of Grails vs. Java/Struts out there, such as: CompleteOpenSource, Nabble and StackOverflow, not to mention the big comparison over at JavaOne, but some of the philosophical issues seem harder to tackle:

  1. Unsubstantiated Claim #1: Hesitation to move to Grails is really an unwillingness to learn anything new on part of Java developers.
    Really? This is a subjective claim, and I am sure it is going to be neither true nor false. But my personal experience on this issue suggests that Java developers do not want to learn Grails simply because they want to focus on solving new problems, not focus on solving new problems in a new way! It is the “new problem” that is of interest to them, not the “new way”. One could argue that “new way” can make things much faster for them, but the Java developers frequently argue back that business (and not technical) problems are the ones where they are spending the time, so the “new way” isn’t likely to change much in that case. This represents an implicit high level of maturity in Java/Struts based enterprise systems.
  2. Claim #2: Grails is easier for development.
    Java, since its day one, has been known to be harder for development than say VB. Still, that has not stopped Java from progressing and reach dizzying heights. So, what does that teach us?The language/framework needs to be easy to develop, and scalable/efficient to execute/deploy. Which of these two attributes is more important – that is an inane question. Can you turn one knob up and the other knob down, and come out better? I don’t know.With Java/Struts, apparently, the difficulty in development was not a show stopper. If Grails promises to ease development, but is even an epsilon less scalable, that already makes it a partially ordered set. In fancy terms: Grails, in that case, is not a Pareto optimization over Java. In layperson’s terms: win some, lose some.
  3. Claim #3: Grails doesn’t have the same security of compile time checks.
    The bad news is that for a production system, this isn’t so good. The good news is that by integrating unit tests, the impact of this problem can be minimized.
  4. True, but pointless Claim #4: Convention over Configurability.
    This one is surprising. Grails lovers claim CoC to be a big plus. Java developers don’t see why this should be a reason for celebration at all. Configuring a project takes very little time these days, and if you do that, and retain the choice of configurability, then should you be interested in something that takes 10 less minutes to setup, but is not as configurable?

Obviously enough, jury, is still out on this one.

Awesome Layout – ParagraphLayout

Java/Swing documentation and user guides talk a lot about how layouts should be used, but the fact is that Java Swing default layouts are not really that helpful in following those guidelines. To create simple UIs, I often need to create at least a few layouts, using usually a mixture of SpringLayout, BorderLayout and FlowLayout.

Luckily I just came across ParagraphLayout from JHLabs. In general, great article – good stuff guys!