Web 3.5 Arrival or Swing Apps Rocks With Java 6 Update 10 - an 3D, Flickr, WebStart App

The Synergy Between Operations And Development, Or Why Glassfish Takes Off

It seems like the software development process is driven by developers :-). Fast booting, text-based configuration, IDE-integration and hot deployment - or better no deployment are key to developer acceptance in appserver market. Small footprint and modularization can be derived from the previous requirements. Nonetheless, the development phase ends with the delivery of your software to your customer - and so operations. Often developers choose "lightweight" application servers for development - and deployed to application servers maintained by the operations. The problem is: although with Java EE 5 there are no more problems with porting an application from one server to another, but the servers can still behave different. So there is always some fraction here.

The operators prefer application servers with good monitoring capabilities, easy visual administration (or easy console administration - it really depends on the company) - but just don't care about boot times, hot deployment etc. Glassfish is the first, server I know, that tries to satisfy developers as well as operations. And it is opensource on top... It is small enough to use it for your day to day job, and it can scale to an enterprise system. Furthermore - Glassfish comes with excellent monitoring capabilities, nice visual console - even the documentation is directly accessible from the admin console ...as PDF. This is what administrators like - but it is still possible to configure Glassfish using XML and command line interface.

By scaling, I do not only mean "throughput", but deploying EJB 3, WebBeans (Seam), JCA, JMS connectors etc. if needed as well. Also the acronyms sounds scary, it is really easy to access e.g. an SAP system via JCA (or JRA), or communicate with a mainframe via JMS. Btw. even really simple applications are easier to build with EJB 3, than without.

So, "Tomcat Today, Glassfish Tomorrow - or I would rather say: Glassfish v2 Today, Glassfish v3 Tomorrow :-)".  And...even Rod Johnson likes Glassfish :-).

OSGI Was Supported By Sun Long Before J2EE...

It's actually funny, or tragic. Sun started in August 1999, the Java Embedded Server 1.0 product (JES) for residential gateways.
In May, 2000 JES 2.0 software became even OSGi compliant. I gave some workshops in 2001 / 2003 timeline, but actually no one was really interested in OSGI at the time.
Why Sun is just not waiting for about 10 years, until they announce their products? :-) The same (tragic) story, like with JavaBlend and JINI... Sometimes it is interesting to delve into the history of Java.

EJB 3 (@Session) For Absolute Beginners - 3 Minutes Bootstrap, 5 Steps

Requirements:

1. Installled JDK 1.5 (better 1.6) 
2. An IDE of your choice e.g. vi, emacs, netbeans 6.1 (SE or EE), Eclipse Genymede (SE or EE)
   
3. @Stateless, @Local Annotations in classpath
   
4. An Java EE 5 capable application server of your choice. It will work with Glassfish v1+ (better v2), JBoss 4.2+, WLS 10+ and probably Geronimo (not tried yed)
   

What is to do:

1. In the IDE you will have to point to a JAR containing the two annotations. If you have the Reference Implementation installed (Glassfish), put just: glassfish\lib\javaee.jar to the classpath. IDEs with built in EE support have already everything you need. However for the very first time I would prefer to develop "from scratch" an EJB.
   
2. Create an interface with a method (without a method is a little bit odd :-)):
   import javax.ejb.Remote;
   
   @Remote
   public interface HelloWorld {
       public void sayHello();
   }
3. Create a class which implements this interface. You will be forced by a good IDE (probly not by vi or emacs) to implement this interface:
   import javax.ejb.Stateless;
   
   @Stateless
   public class HelloWorldBean implements HelloWorld {
      
        public void sayHello() {
           System.out.println("Hello!");
       }
   }
4. Compile everything and JAR the output (in Netbeans just "build", in Eclipse "Export -> JAR")
5. Copy the JAR into the autodeploy folder of WLS 10 (bea10\user_projects\domains\YOUR_DOMAIN\autodeploy), or glassfish\domains\domain1\autodeploy in the case of Glassfish v2, or jboss-4.2.2.GA\server\default\deploy in case of JBoss
6. Inspect the log files, you are done :-)
   

What you have gained:

1. It's threadsafe (in multicore environments as well) 
2. Remoting: you can access the interface remotely
3. It's transactional - transactions are started for you
4. It's pooled - you can control the concurrency and prevent "denial of service" attacks.
5. It's monitored: and EJB have to be visible through JMX. Application servers provide additional monitoring services as well.
6. Dependency Injection just works - you can inject persistence, other beans, legacy pojos (I will cover this in some upcomings posts)
7. It's portalble and so vendor-neutral. Deployment to different application servers just works
8. There is NO XML.
9. Its easily accessible (via DI), from Restful services, JSF, Servlets etc.
   
10. Clustering and security are beneficial as well - but not the main reason to use EJBs
    

You Don't Need To Think About Transactions If:

1. Your application has no persistence and do not interact with transactional resources like messaging, legacy interfaces etc.
2. The application is used only by one user in sequential way in a single thread.
   
3. It only reads the data and no one writes or if it only writes the data, and no one reads :-).
   
4. The access to persistent storage, backend resources is performed in one (business) method.
   
5. You don't need the "Unit Of Work" abstraction. So it is no problem if the application dies between method invocations and the data is partly processed.
6. It's ok, if other applications, users etc. see the unfinished (uncommitted) activities in their applications.

You know such an application? :-). I hear from time time statements like: "This is just a report - so I don't need transactions - I'm only reading the data". In this particular case you would access the database without a defined transaction and especially isolation - so you will basically see a snapshot of the database (especially uncommitted changes).

Even if you totally ignore the transactions - you will still get the "Green Bar" in most cases. This is probably the reason, why transactions are often in fact ignored ...until the production :-).

Is EJB 3 The Solution For The "Multicore Crisis"? (@Stateless and @Stateful)

During yesterday's excellent talk of Heinz Kabutz at Jazoon, it turned out, that even the += operator isn't atomic and can cause problems in  parallel, multicore, multiprocessor platforms. It doesn't have to be super-parallel - just current commodity hardware can already cause the problems - and you have to synchronized your code (without synchronized :-)).

Nevertheless, because EJB (1.0, 1.1, 2.0, 2.1, 3.0 and probably 3.1) are always executed in a dedicated thread - they appear as single threaded for the developer. For every thread (=user request, transaction) a new EJB instance is created (or reused from pool) - there is actually no shared state, except you access singletons, files etc. - which is not allowed. Actually the spec even prohibits the usage of the synchronization primitives and threading functionality inside EJBs.

Furthermore the programming model is rather procedural (or if you will "service oriented") - so in the @Stateless Session Beans the methods process some input data and give it back to the caller. Even the @Stateful Session Beans do not brake the rule - the container still prohibits concurrent access to the @Stateful instance. Because a @Stateful Session Bean can be only executed in a single thread - you do not have (you shouldn't!) care about the threading either.

The best of all: if you acess the JPA-persistence - the container synchronizes the data for you. Every transaction receives a copy of the JPA-entity (it is often implemented in this way), so nothing bad can happen even in this case.

I'm not sure whether there are actually some corner cases - where EJB programming model breaks in multicore environment (except you are violating the spec). Every EJB-instance can be only executed in a single thread. And every thread is (hopefully) executed in a single core. So if you keep the transactions short, and do not "hack" the EJBs accessing static variables or singletons - you are on the bright side :-).

Embedding Glassfish V3 in Unit Test - Two Jars, Three Lines Of Code And Five Seconds Start With Deployment

There is already a great blog entry about using Glassfish v3 in embedded mode (I "reused" some ideaas and even code from the post - this is how web works :-)). It explains the whole process, to install, build and test Glassfish v3 using maven 2. However I just liked to do it without maven - and as easy as possible. To start glassfish you only need two jar:

• gf-embedded-api-1.0-alpha-4.jar
• web-all-10.0-build-20080430.jar

Having them in the classpath, you can start glassfish v3 just from your code - in process:

  GlassFish glassfish = new GlassFish(port);
It is not only possible to start glassfish in embedded code, it is even possible to deploy applications on the fly. The following code does exactly that:

ScatteredWar war = new ScatteredWar(NAME, new File("src/main/resources"), new File("src/main/resources/WEB-INF/web.xml"),   Collections.singleton(new File("build/classes").toURI().toURL()));
glassfish.deploy(war);

...and the full test code:

import org.glassfish.embed.GlassFish;
import org.glassfish.embed.ScatteredWar;
//and other obvious imports

public class HelloServletTest{
   
private final String NAME = "AppTest";
public static int port = 9999;

private GlassFish glassFish;

    @Before
    public void bootGlassfish() throws Exception{
        this.glassFish = newGlassFish(port);
        assertNotNull(this.glassFish);
    }
    @Test
    public void testServlet() throws Exception {
        URL url = new URL("http://localhost:" + port + "/" + NAME + "/HelloServlet");
        BufferedReader br = new BufferedReader(
                new InputStreamReader(
                url.openConnection().getInputStream()));
        assertEquals("Hallo from servlet", br.readLine());
    }

    private GlassFish newGlassFish(int port) throws Exception {
        GlassFish glassfish = new GlassFish(port);
        ScatteredWar war = new ScatteredWar(NAME,
                new File("src/main/resources"),
                new File("src/main/resources/WEB-INF/web.xml"),
                Collections.singleton(new File("build/classes").toURI().toURL()));
        glassfish.deploy(war);
        System.out.println("Ready ...");
        return glassfish;
    }
   
    @After
    public void shutdown(){
           this.glassFish.stop();
    }

The unit test is only a sample, in general I woul start glassfish in the static @BeforeClass method - for one test it is good enough.
Glassfish v3 is not production ready yet - but it becomes more and more interesting for development. Cannot wait for embeddable EJB 3 containers :-).

I checked in the whole project (with servlet, glassfish jars and the unit test) into the p4j5. The project name is: EmbeddedGlassfishWeb. The remaining question is: from where I have this two jars - the answer is simple: from the maven repository :-).

So, and I'm going to present this stuff now  - I'm at Jazoon :-).

To JSF Or Not To JSF ...This Is The Question - or Why vi is Not Enough

1. Java Server Faces 1.2 are already shipped with every Java EE 5 server - so before you are choosing a more esotheric framework, you should at least evaluate JSF.
   
2. JSF are component based - the development model is event-driven and similar to Swing
1. A backend object (backing bean) receives the events (just a method)
   
2. Bi-directional, declarative Data Binding can be used to synchronize the view-components with the backing bean
3. The backing bean runs on the server - it can access e.g. the EJB 3.0 per Reference. "Fat Client" programming model is possible :-). This is a huge advantage. No value objects, client objects etc. are required.
   
4. Model View Presenter / Model View Controller patterns are easy to implement. The presenters / controllers can be even shared with Swing apps (in theory - in practice the views are too different).
   
3. Convenient data conversion for the common types (e.g. from String to int) already happens behind the scenes.
4. Validation support is already built in.
5. Navigation / Page Flow are provided and standardized.
   
6. Visual tool support for JSF is outstanding. Most of the tools are free e.g. Netbeans 6.1, Oracle JDeveloper, Eclipse with Plugins (e.g. Visual Page Designer in WTP 2.0). Some tools (e.g. Netbeans) provide visual support for page flows.
   
7. There are already many JSF component providers - many have AJAX support, and are opensource.
   

JSF programming with good tool support can be very productive (in my opinion - unbeatable). So it is absolutely possible to build from scratch a CRUD app in three minutes (with nice table - sorting included) - without hacking. In case a given JSF provider fully covers your customer's requirements - it's the best choice. Some extensions like Shale or Tiles, help you better structuring your application / page flow. However I would only use them if necessary (every jar increases the complexity...- and makes the deployment harder).

Nevertheless JSF 1.2 has also a "dark side":

1. The amount of XML-configuration is considerable (therefore tools are absolutely needed - vi, even emacs are not enough :-))
2. Building custom components requires some deeper knowledge - it is not so simple, as it could be.
3. Every request is a POST request - you will need some workarounds for bookmarking etc.
4. For more sophisticated applications - you will need to understand the "6 phases" - this can take a day of experimentation to fully understand it.
5. You will still need JavaScript / AJAX expertise, regardless how good your framework is.
6. Customizing the look and feel of the visual components, can be time-consuming. Go with the default if possible.
7. The whole component tree is cached on the server in memory - you should plan some performance tests to verify the requirements. In general the performance is o.k.
   

How Fast Is The Build And Deployment Of about 660 JPA Entities And 50 Session Beans On Glassfish v2 And Netbeans 6.1?

I'm often asked about the deployment performance of Glassfish v2 in Real World. If you have just few EJB 3 and JPA-Entities the whole build and deployment takes only few (1-3 ) seconds. In Real World you will have rarely only few components to deploy, so I just measured the performance in the one of my current projects. The initial (standard Netbeans) ant build and deployment of JSF application with 660 JPA Entities and about 80 EJB 3 in an EAR, with creation of  tables etc. takes:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 2 minutes 32 seconds)

Subsequent redeployments are much faster - and takes about:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 41 seconds)

 In both cases the full cycle (clean, build deploy and undeploy) ot the whole EAR was tested. It seems like preparing the named queries and deploying the JPA entities consumes most of the time.

The first deployment in incremental / or activated directory deployment (goto -> services -> Glassfish -> options in Netbeans 6.1). Is very slow:

Enable of application in all targets  completed successfully
All operations completed successfully
post-run-deploy:
run-deploy:
BUILD SUCCESSFUL (total time: 7 minutes 6 seconds)

But subsequent deployment become really fast. I changed some JSFs and EJBs and it took:

Browsing: http://localhost:8080/myapp/
run-display-browser:
run-ac:
run:
BUILD SUCCESSFUL (total time: 6 seconds)

opening the browser included :-).

If you like to use the incremental deployment, use the "Run" option in Netbeans, instead of  "Undeploy and Deploy".

It was tested on Glassfish v2 (developer profile) on Java 6 update 10, Oracle XE, Netbeans 6.1 ...and Windows Vista 32 bit (without activated virus scanner :-)) on a IBM notebook. However from time to time it seems like Windows locks the files - so I have to restart Glassfish then. It seems to be a Windows problem - it occurs only in the "directory deployment" mode.

See you at Jazoon'08 :-)!.

Would Someone Consider To Use SWT (or another native widget library) Again These Days For Portable Platforms / Applications?

Everything started with AWT in JDK 1.0. It came with JDK 1.0, and it used (actually uses - is still there) native widgets for rendering. I still remember the excitement, as it was introduced around 1998 (with JDK 1.2). Everyone was excited, although even the JTextFields weren't rendered correctly. Swing took the opposite approach - it rendered the components itself - so it was somehow OS independent. Only about three years later Eclipse was introduced with the SWT. It took similar approach to AWT - because of responsiveness problems of Swing and the native look and feel. At the time it was a viable solution for a given problem (although e.g. the performance of other Swing apps was really good). These days the responsiveness of Swing is just phenomenal (just ask IntelliJ / Netbeans users about it :-)), and Eclipse (forms) looks very different to the native Windows applications (Outlook, Office, OneNote etc.). The new platforms like Flex, Silverlight, even Java FX do not even try to achieve a perfect, native, look and feel - many nice demos just look totally different (which can be a good thing).

A native UI toolkit is harder too maintain for different platforms, because you have to test different operating systems (32 and 64 bits), and emulate some widgets, since they are not available for every given platform. So there is more effort to achieve the same goal (a decent toolkit). Furthermore SWT can only wrap existing native widgets, so the usable API is somehow limited. It's not always fun to work with it. Just ask a developer (after a beer) with SWT / JFace experience, whether he reall enjoyed it. You will get interesting answers :-).

Regarding the maintanenance overhead and portabilities issues - it remains really interesting question. Would e.g. Eclipse start with SWT again - or provide a lightweight approach?