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

Java FX - Shapes, Binding, Animation Screencast By Josh Marinacci

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.

Netbeans 6.1 Editor - One Of My Favorite Shortcuts / "Hidden" Functionalities

Netbeans 6.1 is able to automatically assign a return value and create a variable for you. This is really convenient. To try it out do the following:

1. Type e.g. new java.util.Date();  (or new Date() with strg+space -> it will import it for you), or invoke an arbitrary method with a return value (e.g toString()).
2. Then go with the cursor to Date()  (or the method).
3. You should see a yellow bulb on the left. Either click on the bulb, or click alt+enter.
4. Netbeans should suggest you: "Assign Return Value To New Variable" just press Enter.
5. Netbeans will create a variable, derive the name and the type. The end result is:  Date date = new Date();

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
    

GlassFish & MySQL Unlimited - I Miss One Feature

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 :-).

A Beautiful Java Book - Something For Your Lunch Break

I missed somehow this book. It is my first IT-book (almost) without technical content. Instead of learning new stuff, I just enjoyed it and remembered the old JDK 1.0 days. It is a "special edition" book for the Ten Year Celebration Of Java: Hello World(s)!: From Code to Culture, a Ten Year Celebration of Java Technology. It comes with lot of pictures and arts - but almost no text. So it is perfect for a lunch break - you can fully read it :-).

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 :-).