JEE complexity, documentation, pruning - some analyses and thoughts

J2EE applications can be rapidly deployed and easily enhanced as the enterprise responds to competitive pressures.
(Source: Sun Microsystems Inc.: J2EE Specification)

I am working with JEE6 these days. Try to design some new tech-workshops, sessions and lessons to bring others up to speed with this. During my research I cam across an old slide which talks about total complexity (in number of specification pages). Up to today it only covered J2EE 1.0 until J2EE1.4. But I needed to know more about the actual specifications JEE5 and JEE6. Ok. It was time to browser the jcp website and look out for the details.
The result was unexpected. After having seen so many people complaining about the complexity/size of the J2EE if was finally heard by the Specification Leads and the JEE5 was launched with a slightly different goal than the J2EE specifications before:

The focus of Java EE 5 is ease of development. To simplify the development process for programmers just starting with Java EE, or developing small to medium applications, we’ve made extensive use of Java language annotations that were introduced by J2SE 5.0.
(Source: Sun Microsystems Inc.: JEE5 Specification)

But as you can see, compared to the other versions it is the most complex one regarding to the total number of specification pages. Seems as if the fundamental work for simplyfing the platform itself comes to fruition with JEE6 finally.



The graph itself is reduced to the core and well known APIs. This is a little more than half of the complete platform documentation for JEE6. The complete documentation consists of about 6300 pages (some release notes are not considered with this number).

What else is to mention:
- You see the JSF specification comming in with JEE5. About 450 pages of specification, that were added. Slightly reduced to 400 with JEE6.
- The size of the umbrella specifications was reduced. JEE5 (JSR-244) has about 80 pages of specification more than JEE6 (JSR-316).
- Both JSP versions does not include the Expression Language parts. This would add another 122 pages of specification. JSTL (272 pages) is also not part of this number.

One of the major goals of industry standards is the backward compability. This could be seen in the chart, too. As more and more specifications come in, the old ones still are not beeing dropped even if they are considered as not beeing state of the art anymore. A good examples of this is CMP. Removing the dead parts of APIs, outdated features and not well supported parts is something that will have more attention in the future. The JEE6 already introduced a concept for getting rid of this ballast, called prunning. Based on the community votings, some APIs will disappear from JEE7.

The Java EE Container Redeploy & Restart Report – measuring Turnaround Time

The Java EE Container Redeploy & Restart Report comes from a survey with over 1100 Java EE developer respondents. It analyzes time spent on the Redeploy and Restart process, and compares the following containers:

• GlassFish
• Jetty
• Tomcat
• WebSphere
• WebLogic

Among other results, this report shows that Java EE developers are spending three to seven work weeks a year on redeploys and restarts, depending on their container of choice.

Which Container is used most often?

Organized By Container, How Much Time is Spent Redeploying?

There are few surprises here. Jetty is leading the pack with only 5.8 minutes per hour spent redeploying and IBM WebSphere is trailing with more than twice more — 13.8 minutes per hour. One thing to note is that although Jetty startup is undoubtedly faster than IBM WebSphere it is likely that most of the difference is due to the size of the applications deployed and the technologies used in them.

Book review: Real World Java EE Patterns - Rethinking Best Practices by Adam Bien

I got the chance to look at the digital edition of Adams newest book. All "Bien works" promise real world knowledge and code you need to develop lean and maintainable Java EE 5 / 6 applications. Therefore I was quite excited to see his new book.

Real World Java EE Patterns - Rethinking Best Practices guides you to efficient code and best practices in a structured way, with real world examples.

The first two chapter sum up, what you should already know. Basic JEE principles (EJB, JPA, JMS, JCA, JTA, Dependency Injection, Convention Over Configuration, Interceptors, REST), Transactions, Isolation Levels, Core J2EE patterns. In short, this is more like a "history of the internet section".

Chapters three to five realy deal with patterns. Starting with business layer patterns for domain driven and service oriented architectures, over to patterns for integration of asynchronous, legacy, or incompatible resources and finaly infrastructural patterns for eager-starting of services, thread tracking and more.

Chapter six finaly is about pragmatic Java EE Architectures. With a discussion of superfluous patterns and outdated best practices. Things like DAOs, Business Delegates, Data Transfer Objects extensive layering, indirections and more. Beside this, the introduces lean and pragmatic service and domain driven architectures, based on the discussed patterns.

As a conclusion: A good book to start over again with patterns in JEE6. If you skip the first two parts and focus on the "pattern" itself, it can be a very usefull ressource for you. As always, Adam's books are fun to read and easy to understand even for non native speakers :)

The online PDF version is available from Lulu.com.
(If you use the the promo code: "README" you will save 10% off)

Have a look at http://press.adam-bien.com/, too.

Using JavaMail with Weblogic Server

WebLogic Server includes the JavaMail API version 1.3. Using the JavaMail API, you can add email capabilities to your enterprise java applications. It provides access to Internet Message Access Protocol (IMAP)- and Simple Mail Transfer Protocol (SMTP).

JavaMail depends on configuration files that define the mail transport capabilities of the system. The weblogic.jar file contains the standard configuration files from Sun, which enable IMAP and SMTP mail servers for JavaMail and define the default message types JavaMail can process. If you do want to extend JavaMail, download JavaMail from Sun and follow Sun’s instructions for adding your extensions. Then add your extended JavaMail package in the WebLogic Server classpath in front of weblogic.jar.

First thing to do is to configure a JavaMail Session in WebLogic Server. This allows server-side modules and applications to access JavaMail services with JNDI, using Session properties you preconfigure for them (e.g. mail hosts, transport and store protocols, and the default mail user). Applications that are heavy email users benefit because the mail session creates a single javax.mail.Session object and makes it available via JNDI to any module that needs it.

You can override any properties set in the mail session in your code by creating a java.util.Properties object containing the properties you want to override. Then, after you look up the mail session object in JNDI, call the Session.getInstance() method with your Properties object to get a customized Session.

To create a mail session in weblogic admin console:

1. In the Administration Console, expand Services and select Mail Sessions.


2. Click the New button.


3. Enter a name for your mail session and click OK.


4. On the Mail Sessions page, click the new mail session name.


5. On the Mail Sessions: Configuration page, in JNDI Name, enter a unique JNDI name.


6. In Properties, specify information for connecting to an existing mail server.


7. save your changes

A simple example of sending a message with java mail:

// Look up the mail session
InitialContext ic = new InitialContext();
Session session = (Session)
ic.lookup("sampleMailSession");

// Construct a MimeMessage.

String to = "some@adress.net";
String subject = "some example subject";
String messageTxt =
"Some example message body text";

Message msg = new MimeMessage(session);
msg.setFrom();
msg.setRecipients(
Message.RecipientType.TO,
InternetAddress.parse(to, false));
msg.setSubject(subject);
msg.setSentDate(new Date());
// Content is stored in a MIME
// multi-part message
// with one body part
MimeBodyPart mbp = new MimeBodyPart();
mbp.setText(messageTxt);

Multipart mp = new MimeMultipart();
mp.addBodyPart(mbp);
msg.setContent(mp);

//Send the message
Transport.send(msg);



Enterprise Java - a firmer grasp of the fundamentals

This blog is about Enterprise Java. The word "Enterprise" mainly refers to the fact, that it need some more that just plain
Java to run applications that fulfill enterprise requirements. Beside the fact, that most of them were tried to be adressed
by the Java standard with a nearly equal name (JSR 316) there is still lot to learn about this topic beside the basics.
Here are some hints and best practices for beginners wanting to gain a firmer grasp of the fundamentals.
These tips assume, that you already knwo about OOP and Java in general.

1) Read, read, read, read and understand
The Enterprise Java Specification is incredibly thorough and has truly helpful comments following each included standard.
Before asking questions or trying to figure out an issue on your own, save some time and just head straight to the
documentation. Another good place to look for answers and get a deeper understanding about the collaboration of the
standards is the Duke's Bank Sample application. Also known as the JEE Tutorial. Besid this, it is always a good idea
to have a look at the documentation of the application server of your choice.

- JSR 313 Documentation
- Duke's Bank Tutoral
- Certified Java Application Servers

2) Get used to exceptions and learn to read them
You’ll find bugs in your code that you might not have spotted earlier, as not all bugs keep the application from working.
There are different levels of strictness in the reporting that you can use. Depending on the framework, application server
or JDK you are using, you have to configure error reporting the right way.

- JDK Logging
- Commons Logging
- Log4j

3) Use an enterprise IDE
IDE’s (Integrated Development Environments) are helpful tools for any developer.
While they’re not for everyone, an IDE definitely has its place. IDE’s provide tools like

* syntax highlighting
* code completion
* error and deprocation warnings
* refactoring (reworking)
* appserver integration.

And many other features. There are plenty of great IDEs out there that support Enterprise Java. Have a look and take
your choice:

- Eclipse IDE
- Netbeans
- IntelliJ
- OEPE

4) Try some frameworks
Starting with JEE 5 the specification got much easier to use. Anyway, there are still some concepts that feel to
overengineered. Some frameworks try to fight this and reach the goal of providing enterprise grade applications on
a different track. Beeing a skilled developer, you should have seen some of them. Take your time and experiment with them.

- Springframework
- JBoss Seam

5) Try different O/R Mappers
JEE 5 introduced the Java persistence API (JPA). Beside the reference implementation, that ships with the specification
there are plenty other, very good and stable O/R mappers available out there. Most of them have a moving history and
come with advantages or disadvantages depending on your needs. To use the right O/R mapper, it is worth seeing some.

- Hibernate
- EclipseLink
- OpenJPA

6) Don’t Repeat Yourself (DRY)
DRY stands for Don’t Repeat Yourself, and it’s a valuable programming concept, no matter what the language.
DRY programming, as the name implies, is ensuring that you don’t write redundant code.

7) Think about readable code
If you don’t use indentations and white space in your code, the result looks may look like a painting.
Ensure that your code is readable and easy to search because you’ll most definitely be making changes in the future.
IDEs and advanced text editors can add indentation automatically. Take your time to adjust the default settings to
meet your needs. Have a look at available code-templates and best practices out in the web or other projects.

8) Think in tiers
Maintenability is one of the trickiest parts in JEE development. There are plenty of options for architecting your
software. The first paradigma is about tiers. Separete the client from the logic and the database access. spend some
time reading about tiers and how to decouple them.

9) Be aware of dependencies
Even if your follow tip 7, you still have to think about dependencies. You can have a couple of dependencies not only
inside your code and tiers but also with your libraries and infrastructure components. Make shure, you are using the
right and only the needed dependendencies wherever they may appear. Handle them on different levels (Architecture,
Development, Build and Depolyment)

10) Stick to naming conventions
Naming this isn’t just for your own good. There’s nothing worse than trying to find your way through some other
programmer’s nonsensical naming conventions. Help yourself and others by using names that make sense for your
classes, variables and declarations. It's worth taking a look at the basic Sun naming conventions. There are plenty
of different project or customer sets out there, too. Respect them and don't think of them as unneeded. One aspect
of JEE programming is about teams. Most likely you will not be the only one working on a project. Sticking to naming
conventions makes live much easier for all involved team members.

11) Comment your code
Aside from plain formatting, you’ll also want to use inline comments and JavaDoc to
annotate your code. You’ll thank yourself later when you’re needing to go back and find something in the code,
or if you just can’t remember what a certain function did. It’s also useful for anyone else who needs to look
over your code. Remember, that your most likely will not be the only one writing code in an enterprise grade project.

12) Decide on the right plattform to start learning with
There are some application servers out there for free. Well known are Sun's Glassfish, Apache's Geronimo or even Redhat's
JBoss. Beside this, you could always decide to start over with a free for development edition of one of the major commercial
vendors, like Oracle's Weblogic, IBM's Websphere or SAP's AS Java. No matter, which version you start over.
This will always be your home to come back to. Therefore it could be
worth thinking about your future needs. What plattform is your company using? Which area of interest drives my developments?

13) Never, Ever Trust Users
If your application has places for user input, you should always assume that they’re going to try to input naughty code.
I am not implying that users are bad people. It’s just a good mindset. A great way to keep your application
hacker-free is to always initialize your variables and validate input on any way to safeguard your site from attacks
(e.g. XSS, SQL Injection).


14) Ask for Help
It’s only human nature to want to hide the fact that we don’t know much about a certain topic.
Nobody likes being a rooky! But how are we going to learn without asking? Feel free to use forums, StackOverflow or
event the vendors support base to ask more seasoned JEE developers questions.


Have any ideas and tips of your own? I’m sure you do! Comments welcome!

JPA: Optimistic locking and concurrency

The JPA provides a relatively easy way to persist objects, however, there are certain cases that often require a deeper understanding of the consequences that can take place. In two recent posts, Carol McDonald and Felipe Gaucho walk you through two such cases. Carol McDonald first discusses concurrency and locking in the context of the new JPA 2.0 version, while in a second post Felipe Gaucho talks about optimistic locking in the current JPA release and what's in store on this same topic for JPA 2.0


About Carol McDonald
As a Java Technology Evangelist at Sun Microsystems, Carol McDonald has spoken at various conferences including JavaOne, Java University, Sun Tech Days, Sun Network, Sun Code Camps, JDJEdge, and JUGs including Machester, Boston, Maine, Cologne, FAA, Richmond, Memphis, D.C...

About Felipe Gaucho
Felipe Gaucho works as senior software engineer at Netcetera AG in Switzerland. He is a well known Brazilian JUG leader and open-source evangelist.

Using Maven Dependency Projects

Maven is number one in managing dependencies. This could get even simpler, if you use plugins for your favourite ide (e.g. m2eclipse).
Anyway, dependency management is the most challinging part in maven projects. If you have a growing project, you should sit back and think about the project structure and the needed dependencies a bit.
Best practice building jee applications for me is to use so called "dependency projects". If you have your web project you simply add another project called web-deps of type pom and link a dependency to it from your web project. Now you have a single place, where you can manage all your dependencies for your web project.



There are several advantages of this approach:
* One central place to manage all dependencies of your web/ejb projects. You can have some web-tools projects that depend on the deps. This helps preventing circles.
* Assign one responsible person in your project managing the deps.
* Easier change container dependencies. By only adding new deps projects and not breaking the actuall build. This gives you the option to have one deps project per container for example (e.g. web-deps-wls, web-deps-was).



Follow the other parts of this series:

• Adding additional Source Folders to Maven Project


• Generating Static WAR Content Archive with Maven


• Quickstart Maven JEE5 Project

Download the complete Quickstart Maven JEE5 Project.

Adding additional Source Folders to Maven Project

Most projects today have at least one part, that is generated in anyway. This is not too easy to integrate with maven. Mostly the generator's build relys on ant. Therefore it's always a discussion, where to place the build and how to trigger it. The most easiest way is to have a separate java eclipse project that builds with ant and copying the generated ressources to a /gen/ folder within your maven project. Beside the disadvantage, that you have a possible stale version of the generated sources checked in with your repository there are also some advantages, too.
Even if the majority of your team memvers do not have the generator project setup, they can still develop. Beside this, you skip the mostly tricky part of shipping a bunch of additional eclipse plugins to the rest of the team and you can keep the model itself under control of a selected group of persons. Anyway, if you have such a setup, it is no good idea to copy the generated sources to your /main/java folder. It should be obvious to the developers, that there are generated sources in the project. A practical workaround for this is to have different java src folders in your projects. This could be a /main/gen folder for example. In order to tell maven about it, you need to add additional resources to your projects pom-file.
Resource folder are ment for resources and not for java files. Therefore this is quite a bit like a workaround. But it works :)
The following snippet assumes three src folders in your project.

<resources>
<resource>
<directory>src/main/java</directory>
<includes>
<include> **/*.java </include>
<include> **/*.properties </include>
<include> **/*.xml </include>
</includes>
</resource>
<resource>
<directory>src/main/gen</directory>
<includes>
<include> **/*.java </include>
<include> **/*.properties </include>
<include> **/*.xml </include>
</includes>
</resource>
<resource>
<directory>src/main/test</directory>
<includes>
<include> **/*.java </include>
<include> **/*.properties </include>
<include> **/*.xml </include>
</includes>
</resource>
</resources>

Generating Static WAR Content Archive with Maven

You may have seen my simple JEE5 maven project setup already. I am trying to add more and more features during the next few weeks that satisfy the needs of enterprise software development.

First add-on is the possibility to have a separate static-web.zip generated, which contains all relevant content, that should be deployed to a separate webserver.

All you have to do is to add the following to your war/pom.xml

<plugin>
<!-- assamble static content -->
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>src/main/assembly/static.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>

Next step is to add a new folder in the web project (src\main\assembly) and create the needed assembly file (static.xml)

<assembly>
<id>static</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>src/main/webapp</directory>
<includes>
<include>**/*.html</include>
<include>**/*.htm</include>
<include>**/*.jpg</include>
<include>**/*.gif</include>
<include>**/*.css</include>
<include>**/*.js</include>
</includes>
<excludes>
<exclude>WEB-INF/*</exclude>
</excludes>
<outputDirectory>/static</outputDirectory>
</fileSet>
</fileSets>
</assembly>


If you now run maven clean install than you get a new static-web.zip file generated, which contains all the defined files and folders.

Quickstart Maven JEE5 Project

I had to start several JEE5 projects recently and always needed to setup a new maven project structure over and over again. Therefore I decided to build a basic maven project setup for a default JEE5 application containing:
- one EAR project
- one EJB project
- one WAR project

You can download the project setup and give it a try. All projects have the base setup from the JEE5 facets of the related maven plugins. Therefore: Don't expect any magic behind this. The only intention of this was to have a quickstart and don't waste any time on creating the same four poms and folder structures over and over again.

Have a look at the general project structure:

IBM hashing out WebSphere plans

Paul Krill from Infoworld interviewed Savio Rodrigues, IBM product manager for WebSphere Application Server at the SD West 2009 conference in Santa Clara, Calif. about the future directions the WebSphere Application Server will go.

IBM plans more componentizing of its WebSphere Java application server as well as additional dynamic language support. This will continue with extensions to the existing version 7 of WebSphere or with other upgrades.

In future versions, we're going to extend our work with OSGi to further componentize the app server so that finer-grain components are started up

Support for dynamic languages helps with developing situational applications that need to be completed in days, said Rodrigues. "[For] that type of application, something like PHP or Groovy is much better for [that]," he said.

Well, I think that over the last 10 years with Java technology, we've really taken Java to the core of server-side applications. Application servers now appear not only as the foundation for end-user custom applications, but also are the foundation for a whole series of other programming models," such as enterprise service buses

JCP Approves the Java EE 6 Public Review (JSR-316)

The Executive Committee for EE/SE has approved the Public Review for JSR 316, the Java EE 6 Specification.

The vote was 12 YES, 1 NO, 1 ABSTAIN, and 2 NO-VOTED; see Ballot Results. You can download the PRD draft, and, as always, your feedback to the Executive Committee and to the JSR316 Expert Group are very welcome.

Most interesting comments from the ballot results are the comments from SAP and Springsource.

SAP AG voted Yes with the following comment:
SAP votes YES but would like to content that more work is required for the integration of JSR 299 into the platform to be useful and successful. We also would like the Spec Lead to consider putting more emphasis on architectural rigor regarding a single consolidated and extensible component model to be used across the platform - right now there are three (EJB, JSF and JSR 299).

SAP also has different component models in place already. And none of them is truely widespread in the java corner of SAP at the moment. If you want to get more information on this, look the "getting started with application development" guide on the SAP community network.
I am a big fan of SAP's JavaAS >=7. But I am not shure, if JEE is all about one common component model. Even if we have three ore more in place. The only thing that should be forced is the seamless interaction between them.

SpringSource voted Abstain with the following comment:
The introduction of profiles is a step in the right direction. However, we are disappointed not to see a minimal web profile, especially as this has become the choice of most enterprise Java users.

As with previous releases, the inclusion of unproven technology is a risk, especially in JSR 299 and EJB concurrency annotations. The number of substantial changes late in the process also gives us concern about the maturity of the result--especially, the impact of the scope creep of JSR 299 on other specifications.

Experience has shown that tying dependency injection features to a server environment does not match user requirements, as injection is common to all application types. We would have preferred to see a dependency injection model for SE, as we proposed in 2007.

Finally, we are not convinced that the end result matches the goals of Java EE 6 as defined in the original specification request, which we strongly supported.

Ok. This is a more serious comment. I am worried about the missing profiles, too. As I have seen the "Webprofile" for the first time I was wondering about what someone could call "web" :-) The requested "minimal webprofile" could be something similar to the JEE5 Webcontainer. Anyway: It is missing and I do expect that we get in bigger trouble with this doing our first projects on JEE6. Beside that I would love to see some more specialized profiles (e.g. portal, sip, etc).

Not beeing a member of the EG, I am not shure about the "inclusion of unproven technology" and the "number of substantial changes late in the process". But I am shure that both can result in problems. Looking at the different EG members with all their different interests it's like a miracle to me, seeing a new consolidated version of the JEE Spec "nearly" in time ;) What seems to be clear is, that if the inventors of Spring (aka the non JEE component guys :-)) have reservations on the impact of the JSR-299 it's worth looking at.

Weblogic Server - quick(er) development roundtrips - fast-swap

This is something that could eat up time in any bigger project. If you make changes to your working application and you need to track down bugs, it's inevitable to redeploy your application on any change. What is done in seconds, if you
a) know the WLS administration and/or
b) your application is quite lean

If you have a fullblown JEE application with all the magic inside, it's no problem to wait for a successful redeployment for minutes.
In practice there are some ways to get rid of this overhead very quickly.

1) Weblogic's ChangeAwareClassLoader (WLS <=10.x)
Java classloaders do not have any standard mechanism to undeploy or unload a set of classes, nor can they load new versions of classes. In order to make updates to classes in a running virtual machine, the classloader that loaded the changed classes must be replaced with a new classloader. When a classloader is replaced, all classes that were loaded from that classloader (or any classloaders that are offspring of that classloader) must be reloaded. Any instances of these classes must be re-instantiated. If you deploy an exploded application and run the WLS in development mode, you can take advantage from the ChangeAwareClassloader. If you make changes to a single class, the WLS simply replaces the whole classloader and starts over with your newly created class. This was one of the first approaches to quicker development roundtrips. Anyway it is still not the solution for bigger applications.

2) Weblogic Fast-Swap (WLS >=10.x)
Java EE 5 introduces the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing instances. This allows containers to reload altered classes without disturbing running applications, vastly speeding up iterative development cycles and improving the overall development and testing experiences. The usefulness of the Java EE dynamic class redefinition is severely curtailed, however, by the restriction that the shape of the class – its declared fields and methods – cannot change. The purpose of FastSwap is to remove this restriction in WLS, allowing the dynamic redefinition of classes with new shapes to facilitate iterative development.

With FastSwap, Java classes are redefined in-place without reloading the ClassLoader, thereby having the decided advantage of fast turnaround times. This means that you do not have to wait for an application to redeploy and then navigate back to wherever you were in the Web page flow. Instead, you can make your changes, auto compile, and then see the effects immediately.

• FastSwap is only supported when WLS is running in development mode. It is automatically disabled in production mode.


• Only changes to class files in exploded directories are supported. Modifications to class files in archived applications, as well as archived JAR files appearing in the application’s classpath are not supported.

To enable FastSwap in your application, add <fast-swap>true</fast-swap> to the weblogic-application.xml file.

FastSwap can also be enabled for a standalone web-application by adding the <fast-swap> element to the weblogic.xml file.

Once FastSwap is enabled at the descriptor level, an appropriate ClassLoader is instantiated when the application is deployed to WLS. It is recommended that you have your IDE setting set to "compile-on-save" so that java files are compiled on saving. The FastSwap agent tries to find all classes that have been modified since the last iteration by looking at all directories in the classpath.

FastSwap is supported with POJOs (JARs), Web applications (WARs) and enterprise applications (EARs) deployed in an exploded format. FastSwap is not supported with resource adapters (RARs).

Supported changes:



• Addition and Removal of static methods


• Addition and Removal of instance methods


• Changes to static and instance method bodies


• Addition and Removal of static fields


• Addition and Removal of instance fields

limitations:



• Java Reflection results do not include newly added fields and methods and include removed fields and methods. As a result, use of the reflection API on the modified classes can result in undesired behavior.


• Changing the hierarchy of an already existing class is not supported by FastSwap.
  For example, either a) changing the list of implemented interfaces of a class; or b) changing the superclass of a class, is not supported.


• Addition or removal of Java annotations is not supported by FastSwap, since this is tied to the reflection changes mentioned above.


• Addition or removal of methods on EJB Interfaces is not supported by FastSwap since an EJB Compilation step is required to reflect the changes at runtime.


• Addition or removal of constants from Enums is not supported.


• Addition or removal of the finalize method is not supported.

When FastSwap is enabled, after you recompile a class, FastSwap attempts to redefine classes in existing classloaders. If redefinition fails because your changes fall outside the scope of supported FastSwap changes, the JVM throws an UnsupportedOperationException in the WLS window and in the server log file. Your application will not reflect the changes, but will continue to run.

Essential Java resources in 2009

A comprehensive listing of must-have books, sites, blogs, events, and more was compiled by Ted Neward. He is a consultant with ThoughtWorks, a worldwide consultancy, and the principal of Neward & Associates, where he consults, mentors, teaches, and presents on the Java, .NET, XML Services, and other platforms.

I personaly like the section about "Future trends to watch".

• Dynamic languages


• Functional languages


• Closures in Java


• The DaVinci Machine


• User interface developments

As with anything "futures"-related, keep in mind that what's being discussed today may turn out to be a wrong direction, a flash-in-the-pan, a momentary distraction, an influence on the industry, or the Next Big Thing; keep an open mind and a healthy sense of skepticism in equal doses.

JEE6 - Public Review Draft

The public review period of the JEE6 specification (JSR-316) started on january 23. It will be open for comments up to the 23 of february.
Java EE 6 is the Enterprise Edition of version 6 of the Java platform, and thus will be built on Java SE 6.

The main focus of this new release will be to include existing JSRs and frameworks to the JEE landscape and to further continue in simplyfing the whole platform. The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, the JSR-316 introduces the concept of Java EE platform Profiles. The public review draft already contains the initial Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification.

At the moment the required components of the Web Profile are defined as follows:
The following technologies are required components of the Web Profile:

• Servlet 3.0


• JavaServer Pages (JSP) 2.2


• Expression Language (EL) 2.2


• Debugging Support for Other Languages (JSR-45) 1.0


• Standard Tag Library for JavaServer Pages (JSTL) 1.2


• JavaServer Faces (JSF) 2.0


• Common Annotations for Java Platform (JSR-250) 1.1


• Enterprise JavaBeans (EJB) 3.1 Lite


• Java Transaction API (JTA) 1.1


• Java Persistence API (JPA) 2.0

The specification team is looking for comments onto including Web Beans (JSR-299) into the profile or not. The profile definition itself is quite simple. Beside the Web Beans I am missing the possibility to deploy libraries to the container.

Let's see, what other Profiles will be available with the final version and what happens to the application server out there. I personaly expect non of them to provide separate profiles. They all will deliver complete JEE6 functionality.
Changes will come to separate webcontainers, like tomcat.

Btw: did you wonder about (EJB) 3.1 Lite? I did!
Chapter 2.11 from the EJB 3.1 (JSR-318) Specification states:

The EJB API is comprised of a large feature set with support for implementing business logic in a wide variety of enterprise applications. However, the full range of API contracts is not always crucial for all runtime environments. In addition, the breadth of the full API can present challenges for developers just getting started with Enterprise JavaBeans technology.
For these reasons this specification defines a minimal subset of the EJB API known as EJB Lite. EJB Lite is a proper subset of the full EJB 3.1 API. It contains a small, powerful selection of EJB features suitable for writing portable transactional business logic. The vastly reduced size of the feature set makes it suitable for inclusion in a wider range of Enterprise Java products, many of which have much smaller installation and runtime footprints than a typical full Java EE implementation.
An EJB Lite application is merely an EJB application whose EJB API usage falls within the EJB Lite subset. There are no special APIs defined only for EJB Lite. Therefore, any EJB Lite application can be deployed on any Java EE product that implements Enterprise JavaBeans technology, whether that product
supports EJB Lite or the full EJB API.
The EJB Lite API is composed of the following subset of the EJB API :

• Stateless, Stateful, and Singleton Session Bean components


• Local and no-interface view only


• Synchronous method invocations only


• Container-managed transactions / Bean-managed transactions


• Declarative and programmatic Security


• Interceptors


• Deployment Descriptor support (ejb-jar.xml)

An EJB Lite implementation is also required to support Java Persistence 2.0.

There you are. It's a quite minimalistic approach. But after all it's nothing. No full blown EJB and no minimalistic POJOs. What do you think?

Perf4J: Performance Analysis for Enterprise Java

Perf4J was announced yesterday. It is a new open-source performance logging, monitoring and analysis library for enterprise Java applications. For developers who are familiar with common Java logging frameworks like log4j, the team likes to describe Perf4J with an analogy:

Perf4J is to System.currentTimeMillis() as log4J is to System.out.println()

Some highlights of Perf4J's functionality include:

• A simple stop watch mechanism for succinct timing statements.


• A command line tool for parsing log files that generates aggregated statistics and performance graphs.


• Easy integration with the most common logging frameworks and facades: log4j, java.util.logging, Apache Commons Logging and SLF4J.


• Custom log4j appenders to generate statistics and graphs in a running application.


• The ability to expose performance statistics as JMX attributes, and to send notifications when statistics exceed specified thresholds.


• A servlet for exposing performance graphs in a web application.


• A Profiled annotation and a set of custom aspects that allow unobstrusive timing statements when coupled with an AOP framework such as AspectJ or Spring AOP.

(Taken from the original theserverside.com announcement)

For more details have a look at the developer documentation.

You can integrate Perf4J with maven. It is available from the codehaus repository (http://repository.codehaus.org/org/perf4j/perf4j/).

<dependency>
<groupId>org.perf4j</groupId>
<artifactId>perf4j</artifactId>
<version>0.9.7</version>
</dependency>

This seems to be a good thing to start over a new article on :)

Connecting PHP and Java

Back in 2008 I wrote an article about connecting PHP and Java/JEE. This was published yesterday for free on the new heise channel "developer".
Go and read it. Unfortunatualy this was written in german.

In Detail I am talking about:

• PHP Java Extensions and the PHP-Servlet SAPI


• Java Scripting API (JSR 223)


• PHP/Java Bridge


• Quercus from Caucho


• NuSOAP


• Zend PHP/Java Integration

JSR 316 oder auch JEE6

Irgendwie ist es ein wenig an mir vorbei gegangen.
Am 17.07. wurde die Expert-Group für die neue JEE6 Spezifkation
zusammengestellt.

http://jcp.org/en/jsr/detail?id=316

Einige spannende Dinge tun sich da. Zu allererst bleibt die Einführung von "Profiles" zu bemerken. Ein recht kritischer Artikel von Douglas Dooley beschreibt recht gut, zu welchem ersten Eindruck man kommen mag.

Ebenfalls spannend sind die deferred Teile. Nicht mehr dabei:

• JSR-168 Portlet Specification


• JSR-170 Content Repository for Java technology API


• JSR-207 Process Definition for Java


• JSR-208 Java Business Integration (JBI)


• JSR-225 XQuery API for Java (XQJ)


• JSR-235 Service Data Objects


• JSR-286 Portlet Specification 2.0


• JSR-289 SIP Servlet v1.1


• JSR-301 Portlet Bridge Specification for JavaServer Faces

Als Trost bleibt: Vielleicht kommen die mit JEE7 und dem JSR-277 Java Module System wieder.

EJB is dying!

Dass nenne ich mal einen Start in das Wochenende. Nach einer etwas längeren Zeit der Dienstreisen hab ich heute meinen Informationsbedarf mal wieder gestillt. Und prompt bin ich über einen Artikel über eine Keynote auf der JAX2008 gestolpert.

Zum Thema The Future of Enterprise Java referierte Rod Johnson (SpringSource). Den zugehörigen JAXenter Artikel verfasste Sebastian Meyen in seinem unverwechselbaren Stil :)

Aufregung galt Rods Einstellung: „EJB is dying“! Denn damit hat er ausgesprochen, was vielen von uns im Hinterkopf herumschwirrt und sich dennoch keiner zu sagen traut.
Aber was genau wird die Zukunft bringen? OSGi? Spring? Oder gar die bisher noch recht theoretische Agententechnologie?
Neugierig bleiben ist die Devise :) Und über die Agententechnologie werde ich im laufenden Jahr sicherlich noch das ein oder andere schreiben. Hoffentlich auch bald mal etwas konkreter :)

Ein Interview mit Adam Bien

Bin heute zufällig drüber gestolpert.
http://java.sun.com/developer/technicalArticles
/Interviews/community/bien_qa.html

Adam wurde im Rahmen einer Interviewreihe über "Java Champions" von java.sun.com interviewt.

Die Hauptaussagen:

• "It's kind of funny that developers still explore new frameworks and hope for magic solutions -- and forget about core problems."


• "The best advice I know is 'Don't distribute.'"


• "Large-scale IT projects are inherently inefficient. It's a misconception to even talk about a large-scale project."

Viel Spass beim Lesen ;)