April 22nd, 2013
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
September 20th, 2009
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:
- 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.
- 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.
- 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.
- 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.
August 20th, 2009
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!
January 9th, 2009
I have read so many blog posts recently that bash the singleton pattern, and from many many great programmers, that I am forced to believe that this is the new in thing! I mean those guys are great, and I look to them for inspiration! Here is one by Steve Yegge.
But, it seems, I am not going to be able to bash Singleton just yet. I read all of those patterns with an open mind, to see if there was something better out there. Instead, what I have found is that all the specific examples of what they are bashing (for example, the PrintSpooler!) are exactly the cases where in our code, we never use Singleton in the first place.
We use Singletons exclusively to cache reference data and properties that are loaded at application start up time. Those objects don’t change (except perhaps if system administrator uses the edit reference data functionality).
So, we use Singleton pattern, I still like it, and I agree with all the people who say not to overuse it.
January 2nd, 2009
We have been using JBoss since JBoss 3.0 and have been key proponents of this product to the US Government as part of various projects. However, the JBoss 5.0, which has been touted as a complete rewrite, has been a complete failure from our perspective. The general release was on December 5, but despite repeated attempts, we have not been able to get a stable version out. As we dig deeper and deeper into the issues, we find that some of the compatibility issues have simple been “postponed”. It definitely feels like the JBoss team had a strict deadline that they wanted to meet even if some of the issues would not get solved. That kind of defeats the purpose of doing a full release.
Perhaps all this malaise that I am feeling is misplaced and will be replaced once a “real” release of JBoss happens, perhaps that will be JBoss5.0.2. But for now, I cannot advise anyone who is thinking of upgrading to giving it a real try.
So, in a nutshell: if you are running JBoss4x, this is not the time to move to JBoss5.0.0GA, wait a little while.
Let me also list a couple of concrete items:
- Configuration XML files (ejb-jar, web.xml, etc) have a DTD reference on top. That causes a problem, as the JBoss5.0.0GA has a bug that causes that DTD reference to be treated as a local file reference.
- The documentation is very scarce. For example, consider the supposedly “complete” copy of JBoss5.0 documentation available here: http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Installation_And_Getting_Started_Guide/5/html_single/index.html. It makes no mention of what “vfs” is, though that acronym is used dozens of times. I would play a positive role and tell everyone what it is, but I dont know what it is.
- When looking through the logs, this exception appears: java.lang.NoClassDefFoundError: org/jboss/remoting/InvokerCallbackHandler. When searching through the lib folder, I do see this class in jboss-remoting.jar file, but in that jar file, it has the package: org.jboss.remoting.callback (not org.jboss.remoting).
- Perhaps a significant part of the challenge is that as of January 2nd, 2009, google searches on all of these errors return almost no records. I am sure the situation would change in a few days/few weeks time as more workarounds are found.