Adam Bien

Are Naming Conventions For JUnit 4+ Still Needed?

admin — Thu, 19 Nov 2009 09:00:00 +0100

JUnit 3 used naming conventions for the identification of test methods. JUnit 4 uses annotations for that purpose, so that the prefix "test" is actually superfluous. It is not only superfluous, but also redundant.

Instead writing something like:

@Test
public void testAverageTotalStartedThreadCount() {}

you could just skip the prefix "test" and go with the annotation only:

@Test
public void averageTotalStartedThreadCount() {}

The "test" prefixes are still generated by Eclipse and NetBeans, so if you don't like the superfluous naming, you will have to remove it manually. The "test" prefix in the test-class name, however, is still useful. It makes the search for test classes more easy.

Upcoming (2009-2010) Java EE 5/6 Workshops and Events - Some Free

admin — Tue, 17 Nov 2009 09:41:39 +0100

A workshop about "Pragmatic Enterprise Architectures" in Munich - there are already enough registrations - it will take place. I plan to explain how to create pragmatic, but maintainable architectures - of course with real world examples.
January 2010 at the OOP conference - a talk about cloud computing and a Java EE 6 "Rethinking Best Practices" tutorial / workshop.
I will give a talk at Java User Group Hamburg - probably about Java EE 6 stuff. Preliminary date: 02.02.2010
Februaray 2010, ejugdays 2010 - Spring vs. EJB "talk" with Juergen Hoeller, Pragmatic Java EE Architectures workshop and a session about "Xtreme Lightweight EJB" :-).
March 2010, at Scanconf.se in Gothenborg a session about Java EE 6

...and the Adoption Of EJB 3 / Java EE is:

admin — Mon, 16 Nov 2009 09:00:00 +0100

far better than expected. The landscape:

Java EE 5 is already supported by 14 (all major) application servers.
Java EE 6 is already supported by Glassfish 3 and partially by JBoss 6.0 and Geronimo.

The adoption is harder to estimate - but it seems like Java EE 5 (6 is too early) and EJB 3 are gaining momentum. The w-jax conference is over - it was interesting to observe some indicators:

The first time ever there was an EJB 3 / Java EE 6 day. More important: it was very well attended.
Our EJB 3 / Java EE 6 table during the ballroom night (a kind of openspace) was (over)crowded. We already thought about occupying the JRuby table near us :-). All attendees had already EJB 3 experience. The participants introduced interesting projects from the biometric area, over health care system, to route planing and automation. This really surprised me.
Several projects are going to migrate their existing EJB 2 infrastructure to EJB 3. I had two conversations about migration from Spring to EJB 3. The reasons, however, were strategic and not technology driven.
Speakers signalized their interests as well. We had a really nice hall conversations about the EJB 3 programming model and its lightweight nature. I didn't expected it either. Even a Tomcat committer is starting to investigate EJB 3 :-).
My interactive hacking session (60 minutes - with Java EE 6) was attended by ~ 200 people in a room with 180 capacity :-). Btw. the average deployment time took <10ms (Glassfishv3b70 and NetBeans 6.8beta). This caused some interesting discussions afterwards.
At the very last day - I gave a workshop with the title "Java EE Patterns - Rethinking Best Practices" with 55 attendees (a new record). The majority of the attendees had already EJB 3 / Java EE 5 experience. I got really good questions about modularization, transactions, caching and performance during the day. My general observation is: developers, who already used EJB 3, really like it.

See also my tweets. The w-jax conference this year was very well attended (subjectively: more than last year). The conference was well organized with excellent food and location (Westin Grand Hotel in Munich...).

I also recognize growing interests in EJB 3 / Java EE topics in this blog. EJB 3 / Java EE 6 topics are very popular.

Best Of October - JSF Without EJB = Bloat (17k), JSF 2 with NB 6.8 (10k), NB Features (7k)

admin — Sat, 14 Nov 2009 14:09:31 +0100

(JSF + JPA) - EJB = Bloat (17436 views)
JSF 2 + JPA 2 + EJB 3.1 Scaffolding With Netbeans 6.8 in 3 Steps - And The Code Is Even Usable (10118 views)
NetBeans 6.8 m2 - Some Cool + Lightweight Java EE 6 Stuff (6972 views)

and: 376645 direct requests (best result ever), 83803 RSS (best result ever) reads and 21756 atom reads (best result ever)

Daily Avg. Visitors 7236 (September 7068) best result ever

Total Visitors 224329 (September 212058) best result ever

Total Hits: 775886 (September 789488)

Java EE 6 Kills The WAR-Bloat - The KiloByte Deployment

admin — Fri, 13 Nov 2009 08:00:00 +0100

The beauty of Java EE is the lack of libraries and JARs which have to be deployed with your project. Everything you needs resides already on the server. This makes your WARs / EJB-JARS / EARs extremely lean. They only consists of your compiled classes - the actual business logic. There is no need to deploy anything, because the frameworks (JPA implementation, EJB container, JSF implementation, REST implementation, JMS / JDBC-drivers) are already installed on the server. The last time I pushed some examples to: http://kenai.com/projects/javaee-patterns/. The size of the deployment units were:

BeanLocatorTest.war - 16 kB
FireAndForget.war - 8 kB
DAOPattern.war - 29kB
ResourceBinder.war - 8kB

Java EE 6 deployments gets even leaner, than Java EE 5 because REST implementation, Bean Validation, DI extensions (JSR-299, JSR-330) etc. are already part of the spec.

Small deployment units makes the deployment cycle really fast. With Glassfish v3 and incremental deployment of a EJB, Interceptor, JPA-Entity, JSF backing bean takes in general < 10 ms. The full deployment takes at most few seconds.

It seems like some developers are concerned about the size of the server. I prefer small deployments and actually don't care very much about the size of the server. Although Java EE 5/6 servers became surprisingly small. The EJB container in the newest Glassfish v3b71 build is still < 1 MB.

Small deployment units are good for short deployment times - furthermore you don't have to deploy the same stuff over and over again in your WARs.