deepthoughts.orsomethinglikethat

I'm not against acronyms, but recently I stumbled upon the Java Community Process (JCP) Wikipedia article, while looking up what exactly JSR (Java Specification Request) stands for. The JCP article lists all (or at least some - I don't know) of the JSRs that exist; including their number and technology...

RTSJ, JMX, JAXP, JDO, JCA, EJB, CLDC, JAXB, JSIP, CDC, MIDP, JMI, NIO, JSTL, JSP, JDBC, JNLP, JDM, JAXR, JDOM, WSDL4J, WMA, JSF, MMAPI, SLP, SDP, JCR, SATSA, SIP, JTWI, NIO2, JBI, JAX-WS, XQJ, SDO, JDM, MTA, IMS, JTA

Oh oh... looks like I forgot one... JBS

This is in response to Michael Urban's posting, "And The Fastest Growing Web Framework Is..." (which is also kind of a commentary/response to a Rick Hightower blog posting) which awards the honors to JSF based on job posting trends from February 3, 2005 to June 27, 2007.

I won't argue that the job trends chart clearly shows that JSF has had a significant number more job postings for the last two and a half years. You might argue the means the data was gathered but that's already been done extensively in the article's comments.

I will offer an alternative (I'll admit a bit ridiculous) interpretation that states the reason there are so many more JSF job postings is because JSF is the least productive web framework listed; requiring more developers to complete a project. I know it's another poor conclusion drawn from the chart, but I would venture to say that the average JSF project's development team is larger than other development teams using the other listed web frameworks.

Now that's a long title, but still not long enough. It doesn't mention the "java.lang.OutOfMemoryError: PermGen space" errors that led to the use of BEA's JRockit as the JVM of choice for our application server.

After reading several resources (#1, #2, #3) we'd determined the cause of our PermGen Problems:

• Continuous integration was causing frequent "Hot" deployment to our application server (Tomcat 5.5 then JBoss 4.0.4 - Same problem on both). We're crediting the JVM's garbage collecting for not correctly unloading the "old"/previously deployed classes, thus causing the PermGen to run out of space.

• Using Cruise Control running on Jetty, every time the build ran, we'd get a PermGen OutOfMemoryError during JUnit test target execution. We're crediting JUnit for this problem due to the massive class creation/loading that it uses to provide it's much appreciated "clean" environment with every test.

We temporarily solved the problem by not deploying "Hot"; automatically restarting the server instead. The JUnit test problem was temporarily solved by increasing the Jetty server's max PermGen size using the -XX:MaxPermSize=128m JVM arg. Neither of these solutions are great. The most commonly suggested real solution to these problems is to switch to BEA's JRockit JVM - I guess it doesn't have a Permanent Generation memory space so it's impossible to get PermGen memory errors.

Our next step... Running JBoss on BEA's JRockit JVM as a Window's service using JavaService... This didn't work. Why? I have no idea. After a lot of searching for JavaService and JRockit recipes and only finding unanswered questions to a common problem, "...the service will install correctly, but it won't start..." (orsomethinglikethat), I gave Java Service Wrapper a try. I initially preferred JavaService for it's simplicity and small learning curve for the impatient, but Java Service Wrapper works (even with JRockit) and isn't too complicated after a little reading.

To summarize my ramblings to this point: If you're having PermGen memory problems, then BEA's JRockit JVM may be your answer - just don't try to use it in combination with JavaService. Use Java Service Wrapper instead. Here's how to configure Java Service Wrapper to run JBoss on JRockit Read more »

While Java 5 is no longer considered "new," I would guess that many of the features introduced with the version are still "new" or underutilized by most developers. In this entry we'll take a look at the "new" Enum. So what is so great about the new Enum? For starters, it's an object... well kinda... it's a Java object; inconsistent semi-OO quirks and all.

An Enum instance is technically an instanceof java.lang.Object, but when creating a new Enum you don't declare a new class, you use the enum keyword. I hear the (non-existent) reader asking, "that's pretty basic stuff... what's the big deal?" The big deal is that unlike traditional uses of an Enum as a grouping of constant values, the Java 5 Enum is a grouping of constant instances that have properties and behavior. Every instance is statically defined at design time, but that doesn't prevent it from providing behavior to interact with other dynamic objects at runtime.

Let's have a look at an example:

• MenuItem.java - Our Java 5 Enum defining values; CHEESEBURGER, FRIES, DRINK, & DOUBLE_CHEESE_MEAL.
• MenuItemTest.java - JUnit test case for our enum.

Every MenuItem instance has two properties and one behavior-defining method; private String displayName, private Double price, and public Double calculateSalePrice( Double salesTaxRate ) (respectively).

We'll focus on the DOUBLE_CHEESE_MEAL instance... you'll note that it's declaration provides it's own overridden implementation of getPrice() that doesn't just return a constant property value, but instead returns a calculated value based on the price of it's contents (a "Double McCheesy Meal Deal" - two "McCheesy" cheeseburgers, one "McFrench Frie", and one "McSoft Drink"). You'll want to note that the calculateSalePrice(...) method makes use of getPrice() so the DOUBLE_CHEESE_MEAL instance will calculate it's sale price against it's own calculated price.

To finish this longer than necessary post to explain a little with a lot, I'll add that any Java 5 Enum instance that provides it's own methods (ie DOUBLE_CHEESE_MEAL), is compiled like a standard inner class. For example, MenuItem.java compiles to MenuItem.class and MenuItem$1.class. If there were more than one declared MenuItem with it's own overrides, then MenuItem$2.class would exist after compilation.

The sample code and eclipse project can be downloaded in it's entirety here.

This is a quick entry about how to "inject" a Java 5 enum using the Spring Framework. This may not be a common problem, or even considered an obstacle for the average Spring user. I wouldn't consider myself an average Spring user as my involvement with Spring is limited to a small domain of the product I work on. Either way, I thought it would be nice to share my solution with others...

The main players in this example are:

• Status.java - The Java 5 Enum with two enumerations: ACTIVE and PENDING
• AccountServiceImpl.java - The "service" class to have it's defaultStatus property value injected via dependency injection.
• applicationContext.xml - The Spring Framework configuration file.

Until I can find a good way to embed code/xml in WordPress, the code will only be viewable via the links provided.

You'll notice in the applicationContext.xml that the Status enum has been configured twice. Once as it's own bean, Status.ACTIVE, and the other as an anonymous "inner bean" of the accountService bean's defaultStatus property value. In either case you'll notice that each bean definition declares the attribute, factory-method="valueOf". This declaration tells the Spring Framework to use the static factory method, valueOf on the Enum class. We'll also declare a constructor-arg value with the name of the enum, either ACTIVE or PENDING. In short, the enum will be constructed using the Status.valueOf( "ACTIVE" ), or Status.valueOf( "PENDING" ).

The sample code and eclipse project can be downloaded in it's entirety here. This project requires Spring Framework 1.2.8 and Commons - Logging.  Oh... and of course, JUnit.