Enterprise grade Java.
You'll read about Conferences, Java User Groups, Java, Integration, Reactive, Microservices and other technologies.

Friday, December 24, 2010

Season's Greetings and Happy Holidays

09:40 Friday, December 24, 2010 Posted by Unknown No comments:
,
It's nearly done. 2010 is almost over and we finally reached Christmas. Time for eCards, postcards and greetings. I've seen many good ones this year and it's hard to come up with a picture, that visualizes all the good wishes and hopes I have for the many readers out there. Thanks for reading and contributing to my blog this year! Thanks for listening to my thoughts!

Now it's time to wish you and your family all the best this holiday season. Have some silent times for Christmas and between the years. And last but not least a great start into 2011!

Wednesday, December 15, 2010

One thing you did not know about Java EE class loading in GlassFish 2.x

11:10 Wednesday, December 15, 2010 Posted by Unknown No comments:
, ,
As you might have read, I am working on a couple of WebLogic to GlassFish migration projects occasionally. Most of them are WLS 10.0 to GlassFish 2.1.1 and therefore stick to the Java EE 5 specification without removing or adding anything. A couple of projects failed to pass the regression tests on GlassFish because of a class loading issue I was not aware of. So, if you are not willing to make the same mistake, read on ...

Class Loader Hierarchy: What I knew.
Class loaders in the Enterprise Server runtime follow a delegation hierarchy. Note that the class loader hierarchy is not a Java inheritance hierarchy, but a delegation hierarchy. In the delegation design, a class loader delegates classloading to its parent before attempting to load a class itself. A class loader parent can be either the System class loader or another custom class loader. If the parent class loader cannot load a class, the class loader attempts to load the class itself. In effect, a class loader is responsible for loading only the classes not available to the parent. This is true for most application servers out there. Transfered into practical experiences this should tell you, that you have a great example if you look at two web application archives packaged in an ear. Non of the two should have access to the classes loaded by the other class loader. This is, what I believed to be the single truth out there. And the image to the right (taken from Sun GlassFish Enterprise Server v2.1.1 Developer's Guide) seems to support this. You can also compare a little bit smaller documentation without the image in the latest Oracle GlassFish Server 3.0.1 Application Development Guide. On the first read, both seem to tell me the same.... I have a strong class loader hierarchy and one war can not access the classes of the other.

The test case
Ok. Here we go. Build a simple maven project. Two wars in one ear.
[INFO] [dependency:tree {execution: default-cli}]
[INFO] net.eisele:ear:ear:1.0-SNAPSHOT
[INFO] +- net.eisele:web1:war:1.0-SNAPSHOT:compile
[INFO] +- net.eisele:web2:war:1.0-SNAPSHOT:compile
[INFO] +- javaee:javaee-api:jar:5:provided
Put a simple Servlet into war1 and a simple bean with a simple getName() which returns a String into War2. Now access the bean from your Servlet (you need to trick around a bit to get this to work. If anything else fails, put the bean into War1 also and remove it from the war afterwards). Now deploy it to GlassFish 2.x and start being amazed. It works. Even if it should not according to the documented class loading mechanisms.
If you switch over to GlassFish 3.x you get the expected behavior. The class loading from here on is save and you have separate class loaders (Archive class loader) for every module in your application and the test case fails :) Thank god!

The Spec
Now you are wondering, what the specification tells you about this. Look at the latest javaee_platform-6_0-fr-spec.pdf and read:
Components in the web container may have access to the following classes and resources. [...]
The classes and resources accessible to any other web modules included in the same ear file, as described above.

Bottom line
Wow. That was unexpected. In fact, I did expect something else. Now we all are a bit wiser. Be careful migrating apps from one app server to the other. And don't expect to have a strong hierarchical class loader in place. That is especially true for GF 2.x class loading.

Friday, December 10, 2010

Who is afraid of Java EE 6? Get rid of your fears!

13:24 Friday, December 10, 2010 Posted by Unknown 1 comment:
,
Believe it or not. From time to time I get the chance to make a proposal for a technology stack to use. And it happened recently, that I did this. And after following my post about choosing the right Java EE version I dediced to make a proposel for using Java EE 6 with GlassFish 3.0.1. And this proposal finally raised my awareness about possible risks, people could remark being confronted with such a decision. Here is how you could address them. And please note, that this is only one possible way that is drawn with a strong technology background skipping all the "maybes" and "technical details". If you have to argue for it, it's most likely, that you will see business decisions driving this more often.

Nothing changed (basicaly)
If you look at Java EE 6 from a technology point of view, you have a couple of single specifications contained in an umbrella. We are talking about roughly 35 technologies. Let's split them apart to see, what's important. Compared to the plain numbers, the heart of Java EE 6 is still Java EE 5. 52% of the specifications did not even get an update. They simply stay unchanged. We have 23% regular updates, 14% major updates (reworks) and only 11% of the stack is completely new. So nobody has to fear, that already taken investments in Java EE 5 skills or infrastructure will be wasted. It's more like a concrete evolution of what we have with Java EE 6. If you stay at 5 these days, you'll be betting on 4-year old technology and increasing your Technical Debt.

Advantages and opportunities of the new ones
Let's look at how the 11% new stuff could influence our development and which opportunities are in there. First two are Contexts and Dependency Injection (JSR 299) und DI for Java (JSR 330). Both promise to make mature dependency injection capabilities know from frameworks like Spring and Guice available within the industry standard.
Next in line is the new Bean Validation (JSR 303) framework. It's presence allows for standardized and annotation based validation within your applications. And finally there are the RESTful Web Services (JSR 311). They allow a lightweight approach to connecting clients and servers. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it.

Significantly less workarounds and overhead
As one primary goals of Java EE 6 was to optimize the webstack and because of this it is primarily JSF 2.0 (JSR 314) which holds the biggest opportunities. Beside the fact, that you now can use facelets without having to deal with it as a library, you have many other advantages available. Think about scopes, resource handling, system events and native AJAX integration, to name but a few. All this is directly followed by Java Persistence 2.0 (JSR 317). It's the first usable JPA standard out there. You no longer have to use other persistence frameworks to get a working application. Sticking to the standard is now possible without workarounds or additional effort. The topping are the Enterprise Java Beans 3.1 (JSR 318). Forget about ejb.jar files and containers. Deploy everything in a single war. Use the new no interface beans, the singleton support and benefit from the new annotation driven timerbeans. To make it short. The reworked specifications consequently addresses issues from the field. Compared to Java EE 5 you now have significantly less workarounds and overhead in terms of third party libraries to handle.

How to manage the new kids
But there is still the risk, that the new kids on the block will fail and the concepts are not usable in a productive environment. How to address this? The first step is to have it on the list somewhere. Don't tell anybody, you are going to base everything exclusively on them. For a real life project it's best to find a strategy for staggered and suitable use of the new features. In fact, you could think about the right time to introduce the new features. Having a mature Java EE 5 stack at hand it's probably best to start with whatever you have. Straight away and think about the need to introduce any of the new specifications following these simple rules: 1) One at a time. 2) And always have a fall back strategy. The little graphic shows a possible scenario for this. Start with what you know best and introduce what you could handle. JSF 2.0 is a good starting point in general.

GlassFish is dead!
If you are done with discussing Java EE 6 and its advantages in general, you have the next point to talk about. The application server to use. To make it short: You only have exactly one choice at the moment. And this is something that could scare people to death. Be careful talking about it. But it's true, so you have to commit this somewhere during the discussion. The worst argument I heard lately was that someone read, that "GlassFish is dead". Wow. Awesome. Thanks manager magazines around the world. If this is not the message, you are willing to spread: This is how it arrives at your readers. Even if Oracle has it's own way of driving Java and even if they are not Sun and even if there are many things happening in the community at the moment. GlassFish is anything but dead! It's freaking alive and rocking. 24 million downloads since 2005. The reference implementation for both Java EE 5 (JSR 244) and Java EE 6 (JSR 316). The choice for many big accounts like Peugeot, Verizon, Xerox, Telefonica, T-Mobile and many others. And it's there since 11/2008. A stable version is available since 12/10/2009. So it's happy first birthday for Java EE 6 and GlassFish 3 today. But to be honest, the first tests started two years ago. And if you look at the release plan on the right you can see, that the commercial 3.0.1p1 fixed additional 7 bugs compared with the 3.0.1 released 6/18/10. That's a sign, isn't it? A good one!

Why everything has to be this hard
I know. The honest way would be to simply share the personal excitement: "Java EE 6 with GlassFish 3 is freaking hot and we need all those fancy new specifications.". But the truth is, that your daily jobs are there because of people asking you questions about risks and taking them into account. And there are still some scenarios, where I honestly don't want to use Java EE 6. But it's also true, that beside all political considerations there is nothing to worry about using it. If you are not working for one of those customers or shops requiring you to use blue or other colored commercial application servers, you are free to give it a shot. And it is worth it. Beside the technical advances it will save you real money.

Tuesday, December 7, 2010

Seven ways to get things started. Java EE Startup Classes with GlassFish and WebLogic

09:04 Tuesday, December 7, 2010 Posted by Unknown 9 comments:
, ,
This is a blog about a topic that I realy don't like. But it comes across my ways over and over again and it's no doubt that you need it from time to time. Enough reasons for me to collect some information about it and publish it for your reference. I am talking about Startup-/Shutdown classes with Java EE applications or servers.

What are those and why?
Most Java EE applications require you to invoke some functionality at the server startup or application deployment time. For example, you may want to preload some data or invoke some business logic or invoke some logic at server shutdown to gracefully disconnect from a service or release some resources. The right place to do most of the stuff is a so called startup- and/or shutdown class. If you look into the most recent Java EE 6 specification you only find one application construct, the @Startup annotation to do the job. But you have a couple of other options. Here you are:

EJB 3.1 @Startup
The introduction of singletons also provides a convenient way for EJB applications to receive callbacks during application initialization or shutdown. By default, the container decides when to instantiate the singleton instance. However, you can force the container to instantiate the singleton instance during application initialization by using the @Startup annotation. This allows the bean to define a @PostConstruct method that is guaranteed to be called at startup time. In addition, any @PreDestroy method for a singleton is guaranteed to be called when the application is shutting down, regardless of whether the singleton was instantiated using lazy instantiation or eager instantiation. In lazy instantiation, the singleton isn't instantiated until it's method's are first needed. In eager instantiation, the singleton is instantiated at startup time whether or not it gets used.

@Singleton
@Startup
public class StartupBean {

@PostConstruct
private void startup() { ... }

@PreDestroy
private void shutdown() { ... }
...
}

If you are in a clustered environment this probably will not work for you out of the box. This only works within a single VM. You will have your StartupBean called on every server instance starting up or shutting down. If you have special cluster requirements (e.g. only initialize once for the complete cluster) you have to think about synchronizing your StartupBeans by using a database. Usable on any EJB 3.1 compliant container and highly portable. This even should work with the lightweight Java EE 6 Webprofile.

Startup Servlet
The old fashioned way. You can do whatever logic is needed within your startup servlet. This is a simple servlet in general which gets a >load-on-startup< parameter in your web.xml or the @WebServlet(name="startup", loadOnStartup="2") annotation.
This servlet has a load-at-startup priority of 2, meaning any servlet with a load priority lower than 2 will be loaded before this one, and those greater than 2 after.
If you have an init() method which is called by the servlet container to indicate to a servlet that the servlet is being placed into service and a destroy() method which is called by the servlet container to indicate to a servlet that the servlet is being taken out of service.

public class StartupServlet extends javax.servlet.http.HttpServlet {

public void init(ServletConfig config) throws ServletException {
....
}

public void destroy() {
....
}
}


There are a couple of disadvantages to this approach. First of all, this obviously only works with web applications. And second, there is nothing that prevents the servlet from being called a couple of times. To ensure this, you probably would have the need to implement the singleton pattern. Biggest plus here is, you can port it to any Java application server you like.

ServletContextListener
A better way to implement an application startup class is by using the servlet context listener. It listens to application startup and shutdown events by implementing the methods contextInitialized() and contextDestroyed(). You can configure the listener in your web.xml (<listener-class>) or even use the @WebServletContextListener annotation.

public class StartupListener implements javax.servlet.ServletContextListener {
....
public void contextInitialized(ServletContextEvent sce) {
....
}

public void contextDestroyed(ServletContextEvent sce) {
....
}
}

Drawback again; there is one context per "web application" per Java Virtual Machine. So you would have to handle cluster problems yourself. But positive about this is, that you don't have to care about anybody calling it externally, like this could happen with startup servlets. But it's portable and can be used on any Java EE server.

Resource Adapter to Perform as a Startup Class
Another way would be to implement a resource adapter with a minimal resource adapter class that implements javax.resource.ResourceAdapter, which defines a start() and stop() method. When the resource adapter is deployed, the start() method is invoked. When it is undeployed, the stop() method is called.

public class StartupRA implements ResourceAdapter
{
public void start( BootstrapContext bsCtx ) {
...
}
public void stop() {
...
}
// Because of the definition of the ResourceAdapter interface,
// you must also define the endpointActivation(), Deactivation() and getXAResource() methods.
...
}

You can use this approach if you have the Java EE full profile at hand. This is a very mature way of initializing your application in general. Nevertheless you have to add an Resource Adapter to your project and you have to package and deploy it. Compared with the other approaches this is additional complexity. But it will work for any of the containers available providing an RA implementation.

Using JMX notification objects with WebLogic Server
JMX provides two ways to monitor MBeans: MBeans can emit notifications when specific events occur (such as a change in an attribute value), or a special type of MBean called a monitor MBean can poll another MBean and periodically emit notifications to describe an attribute value. You create Java classes called listeners that listen for these notifications and respond appropriately. To receive a notification when a server starts or stops, register a listener with each server's ServerLifeCycleRuntimeMBean in the Domain Runtime MBean Server and configure an AttributeChangeNotificationFilter. Find a detailed description in the Oracle WebLogic Server documentation Listening for Notifications from WebLogic Server MBeans: Main Steps.

Biggest drawback here is the complexity. You have to handle the many notifications and filter them according to your needs. I still do not feel JMX is the easiest API to work with. At the end of the day, this will still be no portable solution. You have to use the WLS specific ObjectNames (e.g. DomainRuntimeServiceMBean).

WebLogic Startup- and Shutdown classes
Prior to release 10.x of WLS, you could have used application-scoped startup and shutdown classes. Application lifecycle listener events provide handles on which developers can control behavior during deployment, undeployment, and redeployment. You create a listener by extending the abstract class weblogic.application.ApplicationLifecycleListener. The container then searches for your listener.

public class MyListener extends ApplicationLifecycleListener {
public void preStart(ApplicationLifecycleEvent evt) {
...
}

public void postStart(ApplicationLifecycleEvent evt) {
...
}

public void preStop(ApplicationLifecycleEvent evt) {
...
}

public void postStop(ApplicationLifecycleEvent evt) {

}
...
}

If you are not willing to use any WebLogic Server-specific interfaces, you can also declared it in the weblogic-application.xml deployment descriptor.

<listener>
<listener-class>MyListener</listener-class>
</listener>

This is a very easy way of implementing startup- and shutdown functionality. Too sad, that it is deprecated and should not be used anymore. And it's not portable and and and ... forget about it :)

GlassFish Server Life Cycle Events
A similar construct is available within GlassFish. The so called Server Life Cycle Events. A lifecycle module (implementing LifecycleListener) listens for and performs its tasks in response to events. Upon start up, before initializing its subsystems application server posts lifcycle modules the INIT_EVENT. This is followed by server posting the STARTUP_EVENT to the lifecycle modules upon which server starts loading and initializaing the applications. Once this phase is completed, the READY_EVENT is posted to the lifecycle modules. When the server is shutdown, server posts the SHUTDOWN_EVENT to the lifecycle modules and then shuts down the applications and subsystems. Once this phase is completed the TERMINATION_EVENT is posted.
You only have to implement the com.sun.appserv.server.LifecycleListener to get this going. It has one method handleEvent(LifecycleEvent event) which gets notified.

public class StartupListener implements LifecycleListener {

public void handleEvent(LifecycleEvent event) throws ServerLifecycleException {
...
if (LifecycleEvent.INIT_EVENT == event.getEventType()) {
...
return;
}

if (LifecycleEvent.STARTUP_EVENT == event.getEventType()) {
...
return;
}

if (LifecycleEvent.SHUTDOWN_EVENT == event.getEventType()) {
...
return;
}

if (LifecycleEvent.TERMINATION_EVENT == event.getEventType()) {
...
return;
}
}
}

After you have implemented it, you can put the jar to the domain/lib directory and add the needed configuration to the domain.xml.

<application name="StartupTest" object-type="user">
<property name="isLifecycle" value="true" />
<property name="class-name" value="net.eisele.StartupListener" />
</application>

This could also be done via the admin console or the asadmin command.
Things to keep in mind are that the configured properties for a lifecycle module are passed as properties after the INIT_EVENT. The JNDI naming context is not available before the STARTUP_EVENT. If a lifecycle module requires the naming context, it can get this after the STARTUP_EVENT, READY_EVENT, or SHUTDOWN_EVENT.

In general it's the same as with the WebLogic startup mechanisms. They are not portable and you should consider using them only in very special cases.

Bottom Line
Now you know about seven ways to get things started. Only four of them are portable and also usable with other Java EE servers. You should try to stick to the first four presented. But there could be reasons for using server depended ways of initializing. If you have the need for threads in general you are almost save starting them the proprietary way, as this is most likely the only way that is supported. Or you have a (customer) blueprint to stick to. Or you need guarantees for your startup classes, that could not be meet by the standardized ways (e.g. classloading, order) ... At the end of the day, it's up to you to make the right decision. Or ask your favorite architect about it :)
If I have missed an approach .. let me know, happy to read your comments!

Thursday, December 2, 2010

NetBeans in large teams. Rollout and preconfiguration.

08:21 Thursday, December 2, 2010 Posted by Unknown No comments:
, ,
I have spend a couple of hours with Java EE 6 since December 2009 and now it finally seems as if the time is right for doing the first real Java EE 6 project. Beeing an Eclipse advocate for years now, Java EE 6 and the IDE support made me think about NetBeans (again). I guess, I used the 3.x in the past and was happy but switched to Eclipse because of the fast growing infrastructure and the number of available plugins. Being in need of Java EE 6 support everything changed. The first bits are out for Eclipse, but I need the full stack. And there is probably no better place to look at, than NetBeans. Here we go. This are the findings from our first steps for using NetBeans in a larger development team. Thanks to Wolfgang for figuring out all this, and thanks to the NetBeans Team (Jesse, Antonin, Petr) for listening to our questions!

Why you should care!
Having a small team at hand this is nothing but a big deal. You talk about the prerequisits and everybody installs the stack. If you are trying to run a midsize or even large development team, you are in need of a defined, structured and preconfigured development environment. There are many reasons for this. First is the time. You don't want:
- everybody to spend a day or two on installing, reading and configuring his IDE.
- different versions around (IDE itself, plugins, server, java)
- different templates, code check configurations or settings around.
And you probably want to be able to scale the team to your needs. One important part of this is a simple and easy development environment and project setup.

Which parts?
In the past, I used to have some archives around with preconfigured Eclipse bundles. They contain different plugins and configurations. One of them was chosen for a new project. If someone came on board, I gave her/him the archive and told her/him to unzip it somewhere. Next was to checkout the project. This is the simple setting. Depending on the projects size, I also decide to rollout the "one" right version of the JDK, Appserver and build tools. For me the optimal set for bigger teams should be:
- IDE itself (with appropriate plugins for your Java EE stack)
- Code Templates
- Quality Checker configuration
- JDK
- Appserver and it's domain
- Build Tool

How to do this with NetBeans?
Have you ever tried to move a NetBeans installation around or rename the folder? Not a big deal, isn't it. But what happens, if you archive it and put it onto another maschine? You probably will experience, that some configurations are broken and you end up with a freshly installed NetBeans or even an error message telling you, that the configured jdkhome is invalid.
You need to take a look at a couple of places to get this right. As always, there are some solutions to this problem and they are OS dependend. I am asuming, that you are using a Windows maschine as dev envorinment.
The best place to start is a clean NetBeans install. You should prepare yourself a bit, to make this easier later on. Create a local project folder somewhere and map a drive letter to it. On windows you can use SUBST [drive1: [drive2:]path] for that. This is only one approach. You could also use whatever folder you like and provide a wrapper.bat where you set all the folders as variables for NetBeans (find some hints about it in the PortableWorkingEnvironmentFaq). I personally like the single mapped drive a bit more.
Next is to download and install the Java SE Development Kit, that you are planning to use. Don't try to install it to the logical drive, this will fail (Don't know, if it's a bug .. trying to figure it out). You will have to install it to the real folder behind the drive. Now start installing your freshly downloaded NetBeans to this logical drive. During the installation process, you should select the appropriate JDK install. Don't care about the "wrong" drive letter for now. Once finished, go and open your X:\ folder and create a new one. Name it whatever you like. It should contain the future default user settings. I'll call it "nbsettings" from now on. Caution: It must NOT reside inside your NetBeans installation folder! Now open the etc\netbeans.conf in your favorite editor and change the netbeans_default_userdir to "../../nbsettings". Next is to change the netbeans_jdkhome to a relative path: "../../jdk1.6.0_22". Now, open a cmd-line and start bin/netbeans.exe.
You should now have a setup like this:
Java Home               = X:\jdk1.6.0_22\jre
  System Locale; Encoding = de_DE (nb); Cp1252
  Current Directory       = X:\NetBeans7.0Beta\bin
  User Directory          = X:\nbsettings
  Installation            = X:\NetBeans7.0Beta\nb
Whatever configuration you are working on now should only make changes to your newly created user directory.

What else?
If you have the basic setup up and running, you can now go, archive the complete logical folder, add a setDrive.bat file containing the subst command and adding some env variables and give everything to your developers. Assuming, that they all run the IDE from a logical drive x:\ you are done. For convenience you should think about adding an up-to-date application server (glassfish or weblogic, of course ;)) and you could even think about pushing out the SQE-Quality Plugin. I recommend, that you place every single needed bit (including Maven and Ant in versions your project will be using) to your IDE template. Another point are the Java Templates. I highly recommend, that you configure them to your projects needs and include them in your bundle. And don't forget to insert subversion keywords.

Summary
I like NetBeans a lot. It is fast, has a rich feature-set and everything you need to get started with Java EE 6 is included. Even if the lates 7.0 is still beta I am really looking forward using it. I especially like the maven, hudson and server integration. This looks very smooth from a developers point of view. Compared with Eclipse the missing plugin infrastructure could be an issue. But who cares, if everything you really need is already bundled with the IDE? One other point, I like is the size. My latest helios packages have an average of 550MB and 11,0k files. The NetBeans 7.0 beta comes with 370MB and 4,5k files. That's a big plus if you are zipping everything together ....

Friday, November 26, 2010

Thoughts on Java's pace - will kairons decide about the future?

08:32 Friday, November 26, 2010 Posted by Unknown No comments:
,
Kevin asks in his recent Java.net poll what do you think about the current pace of Java 7 / Java 8 development? It's not finished today and only 163 votes were given, but I'll try to explain what I think about the past, pace and what should happen in the future.

the past - of Java
Java came on the scene in 1996. It was all very exciting, very energizing. And Sun kept shipping releases on a fairly regular basis for quite a while. 1.1 came out in 1997. 1.2 in 1998, 1.3 in 2000. 1.4 shipped in 2002. 5.0 shipped in 2004 and the last feature release shipped by Sun was Java 6 in 2006.

the pace and time - in general
It is an age-old experience that we do certain things because they have to be done at specific times. Initially unwritten laws, which determined what to do and when to leave is. These laws were mostly derived from the necessities of nature or the culture. This experience of time is called "Kairos" by the ancient Greeks. Everyone knows you can be as important to the proper choice of the moment: when we mow the meadow or to invest in new project and other examples. Today we can and must increasingly decide when and what to do and when not. But beside "Kairos" we also depend on "Chronos", the time we can actually measure and that may be appropriate or not. While chronos is quantitative, kairos has a qualitative nature. Everything depends on your own speed. Or the speed of the organizations you are working. Whenever you are going on even slightly higher speeds than your personal adjustmens to Kairos and Chronos recommend, you will experience the consequences. You have to spend more power than would have been good. Doing this for quite some time even could make you sick.

But wait ... how does this map to java releases?
I know, this sounds very metaphysical and you expected to hear about development stuff. Let's look at how the pace of Java happend to be in the past. It seems as if it followed some kind of a pattern. The odd numbered ones tend to be evolutionary with very few new stuff, but mostly clean-ups and stabilization. The even numbered ones tended to have revolutionary, big things in them. Even if Mark said in his general technical session at J1, that it was not intended to have this kind of pattern in the releases, it was there. An indication of "Kairos" working? I don't know. And please, don't follow that I am heavily involved into any kind of metaphysical stuff in general :) But what I do like to point out is, that I strongly believe that there is a right pace for everything. I am not talking about the right time to do things, but about the speed and release cycles over time. And I believe, that we all have seen this in the past. Start two completely equal projects at the same time with the same setting and force one to be quicker at about 10% of the other. You will most likely see it failing while the other one was ready in time. I am shure, you can find other and better examples.

but we have had long four years silence now - not enough?
Java stood still for years now. More or less exactly four. The double of what "Kairos" had done until 6.0. This should have been a sufficient timeframe for everybody working towards the 6.0 and leaving everything behind. But if you look into the field, you can find lots of 1.4 and 1.5 Versions around. What happened? Was 1.6 too unsexy? Wow .. no ... it was! Were people and companies happy with what they had with 1.4/1.5? I guess not! But it seems as if the missing successor gave them the time to readjust to their own pace and to catch up with the powers lost on the way. Even before the first rumors about possible timelines of Java 7 and 8 came up, the first projects started to move again. It was simply time to do the right thing again.

was time lost?
Comming back to Kevin's poll, the majority of voters think, that a lot of time was lost, but that we're back on track now, having the new JSRs in place and a timeline for Java 7 and 8. But was this realy lost time? There are two sides to this. From the metaphysical points I gave you above: not a single minute. But from a technology point of view I agree with the majority. Some of the most needed advancements have been delayed and Java itself has to catch up with a lot of progress done by other programming languages.

how will Kairos influence Java's future?
What happened with Sun was special. A product without a long-term plan is something I personaly could not imagine to see with Oracle. So they are probably taking out Kairos from the equation. But I still think, that they could learn from what happend in the past. The sucessfull release plan from the past allows for some recommendations to a bright future. They are very personal and I would love to discuss them with anybody out there, so please comment and discuss:
  • New Releases every two (!) years
  • Follow the even/odd system
  • Do continous security updates (monthly or on ASAP)
  • Invest in migration (help people getting to newer versions faster and easier)
  • Decouple parts and allow version mixes (don't force people to learn all the new stuff at once)

Thursday, November 25, 2010

DOAG 2010 - It's a wrap ... in pictures ...

07:18 Thursday, November 25, 2010 Posted by Unknown No comments:
,
A week after, the images arrived. And I found some time to do the postprocessing. This is what came out after walking around with the 7D of Bjoern and the speedlight and lenses from Bernd. A big "Thank you guys!" for letting me use your equipment! It's a pleasure to have great tools at hand :) Maybe .. sometimes I get my own stuff ...
Get the details at flickr/myfear.

Sunday, November 21, 2010

Review "Oracle JRockit - The Definitive Guide"

21:09 Sunday, November 21, 2010 Posted by Unknown 4 comments:
, , ,
This one was on my list of things to buy for quite some time. The only reason for this is simple: Oracle JRockit is one of the industry’s highest performing Java Virtual Machines and I loved it's JIT everything approach since the beginning. I did not manage to do this, since it was published. But a few days ago, the digital edition arrived on my iPad and I finally found the time to read it. Sit back and relax. This is my personal view about the most stunning Java related book of 2010!

Book: Oracle JRockit - The Definitive Guide
Language : English
Paperback : 588 pages [ 235mm x 191mm ]
Release Date : June 2010
ISBN : 1847198066
ISBN 13 : 978-1-847198-06-8
Author(s) : Marcus Hirt (Blog, Twitter, Website), Marcus Lagergren (Twitter)

The Authors
As usual, I start with a short introduction of the authors. In this special case, I feel this is very important to understand the book. Both started out with Appeal Virtual Machines where they were founders. This was the company, which initially developed JRockit. Marcus Lagergren holds a M.Sc. in computer science from the Royal Institute of Technology in Stockholm, Sweden. He has a background in computer security but has worked with runtimes since 1999. Marcus has been team lead and architect for the JRockit code generators and has been involved in pretty much every other aspect of the JRockit JVM internals. Since 2007 Marcus works for Oracle on fast Virtualization technology.

Marcus Hirt is currently working for Oracle as Team Lead, Engineering Manager and Architect for the JRockit Mission Control team. Marcus has been an appreciated speaker on Oracle Open World, eWorld, BEAWorld, EclipseCon, Nordev and Expert Zone Developer Summit, and has contributed JRockit related articles and webinars to the JRockit community. Marcus Hirt got his M.Sc. education in computer science from the Royal Institute of Technology in Stockholm.

Both have a very stunning vita and I am really sad, that I still did not manage to meet them. Something I'll definitely try to catch up with in 2011.

The Content
Java developers are always on the lookout for better ways to analyze application behavior and gain performance. As we all know, this is not as easy as it looks. If you are trying to understand more about all this you need to know far more than simple Java. The big things in terms of performance happen elsewhere: In the JVM. If you are looking for the best Server JVM out there, you'll come across JRockit. And this book is there to reveal it's secrets. This book helps you gain in-depth knowledge of Java from the JVM’s point of view. It explains how to write code that works well with the JVM to gain performance and scalability.

The first chapter get's you started. You learn about the real basics. Cmd-line options and JRockit versioning. The real content starts with chapter 2. It brings you down to the inner workings of the JVM and the adaptive code generation ürinciples. If you are not used to assembly code examples, you will learn it. Examples are explained with bytecode and assemly code. If necessary instruction by instruction. Further on, code generation strategies, JIT compiling and runtime optimizations are explained as concepts with additional JRockit details. Chapter 3 takes you over to adaptive memory management. Here you will learn about the basics of heap management and garbage collection algorithms. Also scaling and performance are touched here. You get a glimpse at pitfalls and things, that will not work. Chapter 4 follows with everything about threads and synchronization and topics that are hard to debug and difficult to optimize. You get a more detailed look at special JRockit flags which help optimizing the topic. Chapter 5 gives your everything about benchmarking and tuning. You get basic hints about what to think about while creating a benchmark and about which measures to take. It also contains a brief overview about industry-standard benchmarks. After that you get to know about common bottlenecks and how to avoid them. Chapter 6 presents an overview about the JRockit Mission Control. Followed by chapter 7 which dives into the management console, touching MBeans, the runtime and further topics. The runtime analyzer is detailed in chapter 8. Learn about the recordings and how to analyze them in terms of memory, code, threads/locks and latency findings. As expected the flight recorder follows in chapter 9. Another JRockit tool, the memory leak detector is the major player in chapter 10. Chapter 11 dives into the JRCMD cmd-line utility and shows how it can be used for listing and sending diagnostic cmds to one or more locally running instance of the JVM. It's an alphabetical reference guide to the JRCMD commands. Chapter 12 contains everything you need to know about using the JRockit management APIs by showcasing examples. The last chapter 13 summarizes the basics about the JRockit Virtual Edition and gives some basics about the challenges by virtualizing Java. If needed you can dive deeper with the bibliography or even look through the glossary or index. 477 pages of content without the preface and the appendix is a big hit for your weekend. You better have some very silent times to follow this stuff!

Writing and style
As you might have guessed already: I am impressed by the book. Being used to read complex and detailed stuff which takes time, I really flew through this book. You get used to the direct and technical style very easy and it's still personal enough to be interesting so you keep on reading page after page. Even non native speakers should be able to follow, if they know the technical terms. I needed to lookup some very uncommon and hardware near things but this did not disturb the overall reading experience.
This was my fist eBook as PDF from Packt Publishing and I am not sure, if I am still willing to have the printed version, too. The many assembly and other code examples always makes you want to scroll back. If you are using a book you just need your thumb to solve this problem :) But I still like the digital reading experience in general.

My expectations
The structure is a bit different from the one I expected. The tooling around JRockit is covered a lot; something I wasn't expecting. But this is the only part, that did not fulfill my expectations. Especially because even those parts are excellent.
I expected to read some very technical content. But it was far more than that. It goes down to the metal and handles and registers and the JVM internals. If you thought, you know anything about the inner workings of a JVM ... here is what really happens. Don't ask what you can do for your JVM; ask, what your JVM can do for you :)

Conclusion and recommendation
Buy one! No .. better two! The digital edition and of course the paperback. It's worth it. If you have both, you can always carry the digital edition around and recall the basics and optimizations to yourself every time you think about writing optimized code for the JVM. Make shure, you have a silent place to read this one. And you should get a recent JRockit R28 to play around with. I wrote articles about it and I have seen it in the wild since some time. I thought I know a bit. Now, I know even more!
If you are a beginner, you probably need some more basics before reading this one.

Friday, November 19, 2010

DOAG 2010 - Day 3 - My second talk, tired people and the trip back

06:56 Friday, November 19, 2010 Posted by Unknown No comments:
My last conference day started not too early. Ed and me had an eigth o'clock breakfast appointment and we drove to the ccn afterwards. So we managed to see the first sessions starting at nine. I was not feeling like taking pictures that day. I simply carried my bag around and tried to focus. Which was not too easy. Anybody was looking tired and asking around how long the evening was for them you get surprising answers. Some hardly did get any sleep. A big surprise to even see them again in the early morning looking reasonably awake. My first stop was at Ed's keynote. He was brilliant on stage and I love listening to him.
After that I meet up with Christian Kirsch and Alexander Neumann. Both from heise.de. We talked about different projects to come and evaluated some oportunities for future work together. If you did not know by now: I like the way heise publishing is doing their job. Very professional and supportive editors give you a great time as an author. This happened around lunch time. My second talk was all about migration. At 14:00 I was answering the question how to migrate J2EE to the new Java EE specifications. What to keep in mind; which version or appserver to choose and which pitfalls to avoid. The talk was not that packed as the one yesterday. Maybe it was because Steven Feuerstein gave his keynote in parallel. What a pity for me.
I left the conference right after the talk. Beeing tired and wiped out it was time for me to take the ride back. Two hours by car to get to munich is not the best time you can do for this distance but it's ok. At the end I was happy to have my girls back and finaly have some time to spend with them in the late afternoon.

To make it short: I always enjoy the Doag conference. There are many reasons for that. First I like to see the people enjoying the program we created for them. Especially this year it was very hard to get that many good speakers and talks for the Java stream as both Devoxx and WJAX happened at the same time. I spoke to some of the speakers and some even made at last two conferences this week. If I could make a wish, I would love to see all three happening on different dates. Devoxx is something I like to attend, too next year.
The second reason is, that I like the location. The CCN is perfect for the size. All in one location on different levels. You start knowing about the rooms the second day and the tracks try to use the same rooms over and over again. That is easily navigable.
Third reason this year are the many high quality foreign speaker we had. So many ACE's, Oracle's and other guests have been on the program that it was nearly a three day English speaking conference for me. I enjoyed having OTN there. Todd did an awesome job and I would like to thank the OTN team for making this possible and for following our invitation!
In general it is easy to say, that the Oracle support was gorgeous. Oracle itself does not sponsor the conference with anything but speakers and their booth in general (which is a very important part for an independent German Oracle Users Group). But they were listening. Not only during the Q&A session but also in between. The feedback they received from their users is valuable and it's a pleasure to see them noticing this and taking care.

I would like to close with some very famous words from a well know Austrian-Amerikan: DOAG, "I'll be back!" next year! Looking forward to it!

Thursday, November 18, 2010

DOAG 2010 - Day 2 - My Talk, People and Party

10:42 Thursday, November 18, 2010 Posted by Unknown No comments:
The second day at the 2010 DOAG conference started more or less in time. After a longer evening it needs some discipline to get up early to be at a 10:00 talk. I arrived timely and had some time to get a last minute glimpse at my slides and even check network connectivity and other details.
The talk itself was awesome. About 30 people listening to my very slideful ( :-( ) introduction to the umbrella JSR 316 (Java EE 6). Even if I tried my best it's simply not possible to introduce a complete set of roughly 30 specifications in 30 minutes. I guess I did a not too bad job. I totally missed pointing the attendees to all the other detailed sessions about single specifications around. I'll promise I'll do better next time. Thanks for all that were listening. I guess I lost nobody and even used NetBeans M7 to demonstrate a simple Servlet calling an EJB. Not the world, but best I could do in this short time. After that I walked around and took some pictures. I hope to get them during the day. They are still on the card with Björns cam. As usual I am trying hard to publish as many impressions I took during the next days.
The afternoon was dedicated to the Q&A preparation with German Oracle management. It always takes some time to get this right and working. Me being one among others who prepared parts of the topics and questions I had to sit in the first row. Always in reach of the microphone to jump in helping the moderator if needed. I was not needed. Thanks for that. The SIG Java lead Andreas did a great job. Also did the moderator of the session which started at 17:00.
After that it was time to relax and get ready for the community evening. Ed Burns arrived in between and I was happy to finally meet him again after JavaOne. I did not know he speaks German very well. He promised to be there at 19:00 for the party. And he showed up in time. We did a quick walk through. Listened to some Jazz and meet some people out there. The food was awesome and there was plenty to drink out there. Beside him some other fellow guys joined us from time to time. Here are some impressions:

Some people in the pictures: Tom Kyte, Steven Feuerstein, Ed Burns, Simon Haslam, Todd Trichler .... it was an awesome evening.
Today is my last day at the conference. I am giving my last talk at 14:00. If you make it, I would be glad.

Wednesday, November 17, 2010

DOAG 2010 - Day 1 - People, Sightseeing, Java SE 7 and 8

08:58 Wednesday, November 17, 2010 Posted by Unknown No comments:
,
It started yesterday. The DOAG 2010, the German Oracle Usergoup Conference. After a very quick ride by car (it is held in Nuremberg which really close to Munich) I did my check-in things and tried to make me comfortable with everything which is going on. I again had the luck to walk around with Björns cam. A big Thank you for this! Will process the images afterwards and post them to my flickr account. The first day way packed with personal meetings. Catching up with people, you haven't seen for some time is great. A special thanks to Dalibor Topic (blog) who was giving a nice overview about the things to come with JDK 7.
As you already know, there are a couple of aces with the DOAG conference this year, too. I meet Daniel, Stanley and many more German aces around.

For some of our international guests there was a sightseeing tour later on. DOAG was so kind inviting me to join and this is how it look like, if a couple of Oracle related guys walk through Nuremberg during evening times freezing their hands off at rainy 7°C. (Thanks to Ronald Bradford for this awesome picture!)
After a nice dinner and some drinks it finally was time to go to bed. A quick twitter and email check revealed a surprise. Around midnight Oracle filled four new JSRs. Java SE 7 and Java SE 8 among them. Reading this, it was totally clear to me, why Dalibor was smiling at me a few hours ago, when I asked him about the time frame for the JSR submission ;)


Today is my first talk at 10:00 (room: Riga). I am giving a brief overview about the Java EE 6 specification and try to present some Samples with NetBeans. If you are there, I would be happy to meet you in person.

Monday, November 15, 2010

DOAG Conference 2010 - last minute information and hints

07:24 Monday, November 15, 2010 Posted by Unknown No comments:
,
One day to go. The 2010 DOAG (German Oracle Users Group) Conference starts tomorrow in the CCN CongressCenter Nuremberg East. There are a couple of ACEs and ACED out there.
Additionally you can find a couple of well know Oracle people attending and giving sessions. Here are a couple of last minute information and links.

Location
The CCN is a nice location and part of the Nuremberg traid fair. You can find a floor plan (PDF) for the conference on the DOAG webpages.The conference is open daily from 8 to 18, on 18. November 2010 from 8 to 17.You can find tracel directions on the ccn website.

The program
You can find a complete program online on the DOAG website. This year you can also use the mobile edition which is accessible from http://iconfguide.doag.org.If you like, you can also download a digital edition (PDF) from the daily conference news. The first issue contains an overview of the complete program.

Twitter
The DOAG also started using twitter this year. They basically use two accounts. @DOAGeV and @doagkonferenz. Not a big surprise, that both are German speaking. If this is an option for you, you get updates on session changes, unconference topics, highlights of the day, some more background about the conference and possibly some interesting retweets from members and attendants. They missed giving out an official twitter hastag but I can imagine most people will tag with #doag2010 or #doagkonferenz.If you are following my own @myfear twitter account, you can get some more English speaking information. At last, I'll try to stick to English :)

What else
I am looking forward to this years DOAG conference. Even if I am very very unhappy about the timing. There are two other conferences (Devoxx and WJAX) going on just the same timeframe and I would loved to have visited all three. It will be hard catching up with all the news from the other two online. I hope, that the hosts mange to serialize this a little more in the future. This would be my advice :) And as always, if I am not giving a session you can probably finde me walking around with a cam. I try to post pictures on my flickr.com/myfear account frequently.
Looking forward meeting you there! Save travels!

Friday, November 12, 2010

Arquillian - Test in the Container with GlassFish 3.1-b04 Embedded

07:41 Friday, November 12, 2010 Posted by Unknown 1 comment:
, ,
I am playing around with JBoss Arquillian these days. Arquillian provides a easy mechanism to test your application code inside a remote or embedded container or by interacting as a client of the container. Having all those integration testing issues since years really makes me wanting all those stuff. And this week there was time to get my hands on that.

Download and first information
It's simple. Grep your copy of the Arquillian Examples from Github and start using it. You can either download or even checkout the repository. It's also a very good idea to make yourself familiar with the reference guide.
The examples are based on the latest Arquillian 1.0.0.Alpha4 and this probably is the first hint for what to expect. It's an alpha. Even if the reference guide gives very helpfull information there is still a lack of public solutions to many things you come across. So you are up to the help of the guys who created it. Thank god, they are available and very responsive. (Thanks to @aslakknutsen and @mojavelinux for the latest help and ideas!) If you are having problems, the first place to look is the user forum. It's there since September and already contains 127 threads to look for solutions.

Getting Started
Extract the arquillian-arquillian-examples-XXXXX.zip archive to a suitable location. All you need is a recent JDK (1.6.0_21) and Maven (3.0). The best place to start is the ejb31-gfembedded example. In most cases this will not work out of the box. I had  to adjust a couple of things to get this running.

1) Repositories
You need access to some JBoss maven repositories in order to build your example. Add the JBoss public repository as a repository and additional as pluginRepository in your projects pom.xml.
2) Offline/Proxy issues with GF
If you are working behind a corporate proxy, you need to add a build section with the maven-surefire-plugin to your pom.xml. Add both systemProperties relevant: http.proxyHost and http.proxyPort. Offline testing is not possible at the moment. Because Arquillian only runs with GF 3.1-b04 which has an issue trying to download schema ressources from sun.com.
3) Arquillian configuration files
If you are not adding an arquillian.xml to your project you will get into trouble with temp gf folders. It's best to exactly configure where you have your instance_root. This is done via the arquillian.xml file. Add a src\test\resources folder and put it in there. Configure the instanceRoot to be at src/test/glassfish and create the folder. Next is to add a testResource pointing to src\test\resources in your pom.xml

Executing your tests
Done. Now you are set. Get a cmd line and enter mvn test -Pglassfish-embedded-3. You see a couple of log messages streamed to your console. The most important one:


INFO: GlassFish3.1-b04 (java_re-private) startup time : Embedded(406ms) startup services(312ms) tota
l(718ms)

followed by

INFO: Portable JNDI names for EJB HelloEJB : [java:global/test/HelloEJB, java:global/test/HelloEJB!o
rg.jboss.arquillian.examples.gfembedded.HelloEJB]

which both tells you, that the embedded server started and your HelloEJB was bound to the JNDI tree. And finally you have the test-results.

-------------------------------------------------------------------------------
Test set: org.jboss.arquillian.examples.gfembedded.HelloEJBTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.563 sec

You can find an output per testcase in the target/surefire-reports folder. This also contains an XML with all the testsuite properties used and the testcase itself.

Some more hints
It took quite some time to get this up and running. There are some examples in the initial distribution also (arquillian-1.0.0.Alpha4\examples\junit) but I was not able to get them to work. Still not giving up, but it's hard because missing qualified error output. You only get logfiles and they collect errors no matter from where they are. If you are looking for the actuall deployment that Arquillian tries to deploy, you can add an engine entry to your arquillian.xml

<engine>
<deploymentExportPath>target/temp</deploymentExportPath>
</engine>

This puts the generated jar to the target directory. Helpfull, if you are tracking down things in the server.
Also don't try to use a later GlassFish build than b04. This leads to a couple of problems and exceptions, that needed to be tracked down further. Seems as if some older TLDScanner things came up again.

Where next
This was a very short howto about running a simple example with Arquillian. Now you have a working environment to make yourself compfortable with this awesome tool and you should actually start looking at the executed testcase and try to write some yourself. I have never ever seen a tool before which could run my integration tests with that ease. I am really looking forward to the next versions and I still hope, that the guys at JBoss start having a more frequent look at
a) their examples and
b) the integration with the Java EE 6 Reference Implementation.

Tuesday, November 9, 2010

Mobile Apps - Native? Flash? HTML 5? - a decision helper.

07:39 Tuesday, November 9, 2010 Posted by Unknown 6 comments:
, ,
Playing around with mobile app development recently one question comes up over and over again: Should I write a native app, rely on the browser capabilities or even take the flash/air approach? As you might have guessed, this is not an easy answer. But there are things, you could keep in mind and make your own decision.

What's out there?
To understand the problem behind this, we do need to have a look at the industry and standards out there.
According to different sources (Gartner, et all) there are roughly 270 million smartphone devices and 19 million tablet computers in the hands of users at the moment. With tablets being the fastest growing cosumer electronic category of all times. Especially the iPad became the most quickly adopted electronic device ever. According to different sources, the number of mobile devices shipped every year will grow at rates close to 20 percent. There are roughly six different vendors with offerings for smartphones or tablet devices which both count as mobiles in my definition. The most prominent ones are of course Apple, RIM and Nokia.


Why should I care?
Mobile computing is a trend in the enterprise. Forrester predicts, that 2/3 of the employees will require mobility support until 2012. For IDC it is clear that more than 35 percent of the workforce will be done using mobile technologies in 2013. All this are enormous numbers that do point into one direction. Mobile computing will hit your desk or even development environment sometimes in the near future. You better should be prepared for that.

Which technologies are there?
Six major vendors are a valid size in the industry. But if we look at the used technologies you quickly notice, that they are all cooking their own soup. Android and BlackBerry rely on Java (Eclipse) with additional device APIs. iOS has it's own Objective-C based programming and tooling environment. Windows Phone 7 relays on  .NET and C#, Symbian uses Qt and C++. All (except one) OS are equipped with a modern browser based on an HTML 5 capable rendering engine. Windows Phone 7 however will probably still contain an older version of Microsoft's Internet Explorer and therefore will not be able to take advantage from the next generation web standard. All but one OS actually can or will be able to run Flash / AIR applications.



HTML 5 and Flash/AIR are the solution?
If you are looking at the table above and are searching for a "write once, run everywhere solution", you probably are looking for an HTML 5 or Flash/AIR app. BUT, both have their limitations. Using one of them does not give you access to the device specific APIs. So you will not be able to access contacts, phone, camera and many many more of the device specific features. If you need them and you need to support all the major OS in the mobile space, you probably end up writing different applications for different devices. If you are comfortable with the feature set you get from HTML 5 and Flash/AIR you probably have found your programming language of choice.

Native apps are the solution?
You are going to develop native applications if you are trying to be most efficient in terms of resource usage. This is true for battery, RAM and CPU. If you are trying to get the best out of your resources there is no other way than writing native apps. I already mentioned the integration with built in device features. If you are willing to write an email, contacts or whatever integration there is no other way than to provide a native app making use of all the device/OS specific features.

What else?
But to be honest, this are not the only decisions you have to make. There are many more things to look after if your are evaluating your approach to mobile development. Everything starts with technology but you also have to look at the distribution (e.g. Do you really want your app in iTunes?) at the development skills in your company, at the needed resources (Do all developers really need a mac ?) ....

As always, there is no single answer to this simple question. But I still hope, the little basics give a brief idea about where to look to make your decision.

Wednesday, October 27, 2010

Bleeding edge - First steps with OpenJDK 7 Build b115

08:10 Wednesday, October 27, 2010 Posted by Unknown 6 comments:
,
Here it is. The guide, to making your first steps into the next version of Java we all are waiting for. Let all the others talk about politics. We are going to test drive what's there today. Prepare for some exciting times.

Preface
This is not a true beginners topic. I'll guide you through installing the binary builds and give some very brief hints at building your own OpenJDK7 version first. After that, we are going to take a look at some of the new features which are already working. But there are a couple of things, you should be aware of:
1) We are working with a development build. Expect this to be anything but mature, production ready or even stable. If you go on reading, you agree on being a geek willing to work with bleeding edge stuff. There is no other help from now on than yourself. Don't bother anyone of the OpenJDK developers with beginners questions. They are hard at work providing the complete set.
2) You should know how to write and compile Java classes without any IDE support. Non of the Eclipse or NetBeans versions were too happy about having a JDK 7 on board and they know nothing about it today. So you need to get yourself an editor and a cmd-line.

Download and install
If you are not willing to build everything yourself, you also could download a binary snapshot release. It's far easier to install this one. The list offers files for different platforms - please be sure to select the proper file(s) for your platform. Carefully review the files listed there to select the ones you want, then click the link(s) to download. The DEBUG builds have not been run through ANY quality procedures, and are only provided as a potential way to track down a bug in the more official product bits. There is no guarantee that the debug builds even will work. For a Windows Offline Installation, Multi-language JDK installation, you need the 86.22 MB jdk-7-ea-bin-b115-windows-i586-21_oct_2010.exe. It's installation is exactly what you know from previous versions. You have a couple of wizard screens. Follow them and you are done. It's better not to install the Public JRE! You are not willing to have OpenJDK7 in your browsers as the default JRE at the moment.


Download and build
If you are willing to build the OpenJDK 7 yourself. There are a couple of things you need:
- The source downloads for the OpenJDK Project. You could also grep the sources from the repositories.
- Some binary plugins. Also available from the source downloads page.
- Things listed at Minimum Build Environments
- GNU make
There is a very complete OpenJDK Build README out there, where to find more detailed explanations of what to do. If you are unhappy with it or you don't understand something. Don't try it. There are binary builds available.

First steps
Check, if your installation is valid. Switch to your %JDK7%\bin folder and type java -version.
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b115)
Java HotSpot(TM) Client VM (build 20.0-b02, mixed mode, sharing)
If you are willing to give it a try, you should put the %JDK7%\bin folder to your path variable.
Seems as if you are set. Next is to fire up some first tests. Make yourself familiar with the new features and give them a try. A good place to start is to look at Arul's post Rest of Project Coin explored, advantage Java 7. I tried the Strings in switch feature. I have waited for this too long :) Taken from Joe Darcy's Project Coin JavaOne presentation and adapted from Arul's blog. It takes a month name and a year as input and returns the days of the month in that year. Take your favorite editor and put it in (Classname and Package, as you like it).
int days = monthNameToDays("February", 2008);

public int monthNameToDays(String s, int year) {
   GregorianCalendar c = new GregorianCalendar();
    switch (s) {
        case "April":
        case "June":
        case "September":
        case "November":
            return 30;
        case "January":
        case "March":
        case "May":
        case "July":
        case "August":
        case "December":
            return 31;
        case "February":
            int days = 28;
            days += c.isLeapYear(year) ? 1 : 0;
            return days;
        default:
            return -1;
    }
}

And, as usual, compile the class and run it. For February, 2008 it returns 29 days. As expected. Great stuff! If you are looking for more advanced examples, you have to dig deeper. The new I/O API is probably a great place to look at. There is a quite old article (2008) about the new features on java.net.
Very short background: What used to be a java.io.File will now become a java.nio.file.Path. This is a more accurate name, since there was never any guarantee that a File object mapped to a real file. Also, paths can refer to both files and directories. The Path class is abstract and has no constructors. Instead, you'll ask a FileSystem object to create a path for you. This way, it can create a path that's specific to the type of file system.
import java.nio.file.*;

public class NioTest {
  public static void main(String... args) {
    FileSystem local = FileSystems.getDefault();
    Path p  =  local.getPath("bar.txt");
    String url = p.toAbsolutePath().toUri().toString();
    System.out.println("Path: " + p.toString());   
    System.out.println("Url: " + url);
    }
}

If I run it on my system I get what I expected:
E:\OpenJDK7Tests\src>java NioTest
Path: bar.txt
Url: file:///E:/OpenJDK7Tests/src/bar.txt

Further readings
This really was not everything waiting for you. You should make yourself familiar with all the new things to come. To be honest, it's not too easy to keep up with what's becoming Java SE 7 at the moment. As you might have heard, there are a couple of political things around which lead to many not technical search results, if you are googling for JDK7. The best place to start looking for further information is the openjdk.org homepage. If you are looking for a blog to subscribe to, look at the openJDK News blog or follow @OpenJDK on twitter. Next place to look are the mailing lists. Sad to say, that every project has it's own. If you are looking for some more advanced stuff, you can also have a look at Arul Dhesiaseelan's blog. He is looking into what's coming up for Java SE 8 (Lambdas, Rest of Coin ...). The offical Java Tutorials also start pushing content for JDK7 out. The Concurrency lesson now includes a chapter about the new Fork/Join framework. Also the NIO 2.0 parts are already featured. A short overview about the SDP (Sockets Direct Protocol) is also available. But be aware, that parts are still moving around. We are all waiting for the Java SE 7 JSR's to be filed and we will see the Expert Group (EG) moving around things, too. So, for the last time a friendly reminder not to take anything too serious at the very moment.
If I could make a Christmas wish, I would love to see some more Java SE 7/OpenJDK7 content coming up. @Java told me, that Santa heard my wish :) Let's look forward!

Wednesday, October 20, 2010

18 and more clicks to the future. Java EE 6 with IBM's WAS 8.0

11:18 Wednesday, October 20, 2010 Posted by Unknown No comments:
, ,
Its out. Finally. The first beta version of IBM's WebSphere Application Server has arrived. The beta offers an initial glimpse into the future of IBM's flagship.
As of now, it isn't touting complete and total Java EE 6 support for the beta product. As they carefully state with the feature list which tells us about "support for portions of key Java Enterprise Edition 6.0 specifications." Those key portions include:
  • Enterprise JavaBeans 3.1
  • Java Persistence API (JPA) 2.0
  • JavaServer Faces (JSF) 2.0
  • JavaServer Pages (JSP) 2.2
  • Servlet 3.0
  • Java EE Connector Architecture 1.6
  • Contexts and Dependency Injection for Java (CDI)

Monday, October 18, 2010

NetBeans 7.0 Milestone 2 features WebLogic Server Support

15:35 Monday, October 18, 2010 Posted by Unknown 2 comments:
,
The NetBeans folks have been busy working on their next release: Milestone 2 of NetBeans 7 is now available and it has a lot to offer:
- Java EE 6 enhancements,
- support for GlassFish 3.1 and
- Oracle WebLogic Server
For a complete list of new features, you should check out the new and noteworthy page. This post is about all the new WebLogic Server features available.

The past
NetBeans always has been the development tool for GlassFish and Tomcat. With Oracle taking over control and committing their support, it was obvious, that WLS will follow. This happened early with NetBeans IDE 6.10 Milestone 1. As of todays M2 the support grew significantly.
If you are willing to try it out, get started today. Grep your copy of NetBeans and install it to your favorite location. Start with a new Webproject and select "Add" next to the serverruntimes shownn (GlassFish, of course). Next is to browse for your WLS install. Remember not only to point it to the %HOME% but directly to the server folder (e.g: D:\Oracle\wls11gR1P2\wlserver_10.3). Click next and choose a domain and enter admin user and pwd. A final click on "finish" will close the wizard and lets you go on with the webproject creation.

Thursday, October 14, 2010

Software Quality on JSF Mojarra 2.0.3-SNAPSHOT

13:58 Thursday, October 14, 2010 Posted by Unknown No comments:
,
Seeing all those political stuff on my blog lately I personaly need a break. And what is best? Get your hands dirty :) And this is what I did. I downloaded the latest mojarra-2.0.3-FCS-source.zip (12/10/10), build it and did a brief setup of my favorite software quality checker with both the API and the RI.
And back to the initial topic, here are the dirty findings :).

Preface
I did this without knowing that much about the project. I am not a committer or in any other way related with the Mojarra Team. Therefore, my findings may leak a bit of interpretation. I also missed to discuss the findings with the team before publishing. First of all, they are not critical (everything works and runs literally in a thousands of places) and second they are not about security or anything else compromising. A quick "Thank you!" to Jochen, who helped me with the msg.Java measuring station. I am open to questions and would love to hand the complete report to the team (@Edburns, you know, how to reach me :)).

msg.Java measuring station
The JMP is described in more detail in a previous post (dec last year). Up to now only the tool versions changed. We are running at the moment:
[echo]  ==         Ncss 32.53
[echo]  ==   Checkstyle 5.0
[echo]  ==     FindBugs 1.3.9
[echo]  ==       Simian 2.2.24
[echo]  == Dependometer 1.18

Tuesday, October 12, 2010

Java SE 7 - new features in detail

04:40 Tuesday, October 12, 2010 Posted by Unknown 1 comment:
,
A lot has been talked about the planned roadmap. And up to now it seems as if it is still not sure, that we will have a new Java SE 7 as planned (Mid 2011), but I thought it may be time to take a deeper look at what's in it and give you a collection of further readings on the separate topics. Following the post by Mark Reinhold from yesterday, where he states details about plan-b this is a more detailled collection with aggregated links and further readings.
The umbrella JSR for Java SE 7 should be submittet during the next weeks. Mark points out, that there might be changes to the list:
These lists should be considered neither exhaustive nor final—they are merely the starting points at which the Expert Groups for the Umbrella JSRs will begin their deliberations.
(M. Reinhold)

Thursday, October 7, 2010

Review "Java EE 6 with GlassFish 3 Application Server" by David Heffelfinger (PACKT Publishing)

09:16 Thursday, October 7, 2010 Posted by Unknown No comments:
, ,
Packt Publishing was so kind, sending me their latest Java EE 6 with GlassFish 3 book for a detailed review.After a couple of weeks delay (work, J1 and more) I finally completed my review and here are the results from the German jury ;)

Book : Java EE 6 with GlassFish 3 Application Server
Language : English
Paperback : 488 pages [ 235mm x 191mm ]
Release Date : July 2010
ISBN : 1849510369
ISBN 13 : 978-1-849510-36-3
Author : David Heffelfinger Twitter | Website | Blog

Monday, October 4, 2010

Free Java? jcp.next? Here are the options!

09:06 Monday, October 4, 2010 Posted by Unknown 4 comments:
, , ,
A lot has been written on this topic over the last few weeks. And it was one of those things that depressed me during JavaONE. Nobody spend an offical word on all those rumors, lawsuits and a possible jcp.next. But the voices calling for a change in the treatment of Java hasn't become silent.
Seems as if it is time to step back and order the thoughts. That is what I was trying to do this weekend. And here is a brief analysis about the "publicly known" facts and the options for the future in my eyes. Why? I guess, Eduardo was right with his response on my tweeted fears. He said:
my point: easy to say free it when not owned nor paid for; change places & well see
(Source: twitter)

Thursday, September 30, 2010

Visual Impressions from JavaONE, Oracle Open World and Develop 2010

10:20 Thursday, September 30, 2010 Posted by Unknown No comments:
, , ,
As you might have guessed, I am into photography. At last a bit. I love taking pictures because of many reasons. One of them is the ability to focus. If you look through your lens you tend to see only parts of the whole and you are able to work out details that nobody else would have seen looking at the same scene. To make it short. I am not going to write a introduction about photography here. This is about sharing my visual impressions from the recent San Francisco trip. If you are willing to use one of them for your own blog posts or anything else, please ask! I am holding the copyright but am willing to share if you tell me a bit more about your plans in advance :) More impressions also via flickr.com/myfear

rush hour

Java SE 7, 8, 9 - The Road Ahead

06:57 Thursday, September 30, 2010 Posted by Unknown 5 comments:
, ,
Another JavaONE followup. After I blogged about what's going to happen with Java EE, it is time to recall what was said by Chief Architect, Java Platform Group, Mark Reinhold on the same general technical session on September 18.
After having the Java SE 6 release shipped in 2006 there had been several plans for Java SE 7. The last plan Sun was in charge of was to ship in 2010. This was before the Sun down. It’s been clear for some time that the most recent JDK 7 development schedule is unrealistic. The schedule was created over nine months ago, prior to the acquisition of Sun by Oracle. The post-acquisition integration process took longer than expected.

Wednesday, September 29, 2010

Java EE.next - the cloud? Exalogic? Some thoughts. And fears.

08:18 Wednesday, September 29, 2010 Posted by Unknown No comments:
,
The JavaONE announcements about upcoming Java EE versions were anything but exciting. Nothing too concrete and nothing comparable to a road map or plan like Mark Reinold's presented for Java SE. But Roberto Chinnici still did some slides about Java EE.next during the JavaONE general technical session on September 18.

The Future as proposed
Everything about the next Java EE version will be cloud support. To enable highly managed environments with scalability and elasticity and to make easy upgrades and easy patching possible. As he said, "Java EE actually has a lot to offer". A container model, exposed application services, injection and consumption of services for clients and it's already scalable up to very large clusters of instances and on top of this a comprehensive security model. This is a quite fair basis for the cloud enables Java EE.next. Java EE, however, was not designed to be operated in highly dynamic environments. Clouds tend to be elastic, and most of the current computing centers are not. But as Adam Bien stated before, "there is some work to be done with respect to dynamic discovery, self-healing, and dynamic load balancing." (Adam Bien, July 2009, tech article) And this is where the requirements for the next Java EE version will arise from:
- Tighter requirements for resource and state management
- Better isolation between applications
- Potential standard APIs for NRDBMS, caching, other
- Common management and monitoring interfaces
- Evolution, not revolution of the programming model
Beside this, there will be a couple of packaging improvements which were presented as "Better Packaging for the Cloud":
- Apps are versioned
- Multiple versions can coexist
- Must deal with data versioning, upgrades, etc.
- Need ability to specify Quality of Service properties
- Apps both expose and connect to services
A visualization of the direction in terms of architecture Java EE.next is going could look like this. The basis is a virtualization layer. Followed by state management for scalability and a number of services on top. What is called a "Java service" in the stack should be the equivalent to the existing containers. That's what runs your Java code. But there will be more services that will be formalized to provide a comprehensive platform.
The application itself will contain a number of code modules, which could be a rough equivalent to what there is today with WAR-, EAR- and JAR-files. To fulfill the requirements, the application also needs a definition of the data it uses with plans to migrate the data to be able to do upgrades. It needs security information. The application will actually grow to include more than the currently present code modules. One application would be sitting alongside other applications from an organization. And there is a need for a very strong isolation between the applications.And finally, the whole environment needs to be managed. So, there will certainly be some added features about management interfaces on both the application level, so you can manage your application and its data, but also, at the lower levels, so that platform providers can manage the infrastructure, and get it to scale accordingly.
Beside this high level stuff, Roberto also pointed out some more detailed plans:
- Modularity build on Java SE work
- explicit dependencies
- explicit versioning
- classloaders straightened out
- Web socket support
- standard JSON API
- HTML5 support
- NIO.2-based web container
- JPA Language support for properties
- JPA generated identity
- all triggered by the @Entity annotation
- Enhancements to the Criteria API, simpler queries

Who needs this? What does the community leaders think?
Seeing all this, makes me wonder, who really needs this cloud stuff. And I remembered a series, Arun Gupta did on his blog. In the Java EE 6 Feedback from Community series you can learn about how Java EE 6 is currently being used in production, development and deployment environments used within the community, and even feature requests for Java EE 7. I quote the answer to the last question from each participant:

Java EE 6 brought simplicity in complex enterprise applications, and made a significant move towards web-based projects. Indeed, the Java EE 6 specification is rather focused on the Web. While there are many usecases and real-world scenarios that have the Web as the most important client, I think there should be more attention for other clients, i.e. PDA, mobile phone, TV, JavaCard. Easy integration capabilities between those low-resource devices and high-end backend system will drive the adoption of Java EE.

From another point of view, more integration with the environment would be useful. For example, in a number of cases I would like to execute a specific EJB-call once CPU load is below 50%, or once disk usage is too high. I understand this is rather difficult to standardize in a non-platform dependent way.
(Johan Vos, QA#4: Java EE 6)

What I really miss in Java EE 6 is something similar to Spring Web Flow or Seam Page Flow. I hope that in Java EE 7 a new specification will come and standardize flow management (for JSF, of course, but something more general letting you manage different sorts of flows).

Batch processing is also something missing. Spring Batch is very good and defines well known principals such as jobs, steps and so one. With EJB 3.1 there is a new Timer Service (inspired from cron and as rich as Quartz). It's time to get a Batch processing specification that can be easily scheduled.

Security is also a difficult point. JAAS is too low level. Even if there are some improvements in the Servlet 3.0 API, there is still room to tight the platform together in terms of security.

Packaging could also be changed in Java EE 7. We talk a lot about OSGi these days. As a developer I found it too difficult, I would like the EE 7 platform to simplify the creation of bundles (OSGi or something different but compatible). I’m also hoping that Java SE 7 will become more modular. Modularity in Java SE 7 + OSGi packaging in EE 7 would be a great combination.

And I remember talking to Adam Bien about it, JMS hasn't changed for more than a decade, it should benefit from the novelties of the platform and get simpler.

In a word, I would like Java EE 7 to get richer (more specs), simpler (less code to write) and more integrated (security is one example).
(Antonio Goncalves, QA#3: Java EE 6)

I think the specifications are more or less feature complete. Of course I can think of a lot of improvements and I believe it's important to stay up to date and integrate new approaches.

If you look at JSF and the RI for example, I am still missing a lot of more complex components. I always find myself implementing one or two own in my projects. If you work for more restrictive enterprises, you are not always able to use the component suite of choice. If possible I still prefer to work with either RichFaces or PrimeFaces. Further on the cooperation between JSR 299 and JSR 330 should be clearer in general. The interaction between all JSRs should be taken to a next level. Clear but abstract guidelines
have to be specified, who is working with whom and how. If you look at the @ManagedBean annotation for example, you have three different ways of defining beans that are managed (JSR-314, JSR-316, JSR-299). That's not exactly what I would call intuitive ;)

Generally I would love to see the Managed Beans specification becoming the heart of enterprise java. Containers should belong to the past. Services should be available to POJOs and injected (and of course started) as needed. This could speed up the whole environment a lot and frees developers from having to implement interfaces. But the most important improvements would be administrative. Java EE 7 should put those pruning ideas forward and realy try to drop some old stuff. And finally it is time to
solve all those never-ending licensing discussions about the TCKs!
(myself, QA#2: Java EE 6)

Further simplification and unification of the APIs would be great. The synergies of JSF 2, EJB and CDI could be a lot more leveraged. A more natural use of java.util.concurrent in Java EE would be also interesting (e.g. injection of Executors). For all of my cases @Asynchronous worked perfectly, but Executors seem somehow to fascinate developers :-)

JPA 2.0 could be also extended with some useful features like support of resource injection (EntityManager is the most important) into JPA-entities. Its a controversial topic - but really important for projects. Also better support for stateful environments would be nice.

I would also expect a standardized JAX-RS client. Something like jersey, but with javax.ws.rs. prefix :-)

I’m really surprised, that actually no-one really complains over the really old JMS programming model (1997). This spec could be drastically simplified. A plain injection of a simplified queue or topic would be sufficient for > 80% of all cases.
(Adam Bien, QA#1: Java EE 6)

Sorry for the complete quotes (also to Arun, who did a great job doing this interviews, btw: why did you stop with it? Keep up!) but I found myself wondering, that we did not find the word "cloud" or managed services a single time. The problems the community leads are seeing, are of course more technical and detailed, than anything presented by Roberto. But the basic indication is that they don't necessarily have anything to do with running Java EE in the cloud. And yes, you can argue, that the overall platform architecture should not be driven by fine-grained technical requirements but by a long term direction. Right. You are right, but:

The fears
Or let's call them: my fears ;) are that we were witnesses of the first steps for the overall platform strategy drifting into a direction that is more product and vendor centric than aimed towards an open and multi vendor approach. Have you seen the probably biggest announcement at this years Open World? Oracle Exalogic? Also make sure, you read the first analysis of fellow ACE Director Simon. It basically is a highly optimized runtime environment for Oracle Fusion Middleware and the product itself was expected to be there way before we heard the announcement. Beside all this technical improvements it has a "Exalogic Elastic Cloud Software" layer in it's architecture. (Also see this post from last week.)
This is where you have to work hardest to establish what's under the covers. The "elastic cloud" software moniker is being used for a host of optimisations Oracle are building into WebLogic Server, JRockit (and presumably Hotspot), JRVE and the Oracle's optimized Linux kernel (unbreakable linux), JDBC and OVM.
Looking at the presented ideas for Java EE.next and the Exalogic I get a strange feeling. This does fit too well to be an "accident" at all. But I leave this up to your thoughts and I would be happy to hear about your fears.

To finish with more positiv thoughts. The Java EE 6 Panel "What do we do now?" gave a more detailed look and discussion about the future of Java EE than Roberto did on a high level in his keynote.