Thursday, March 31, 2011

Why NetBeans isn't an Enterprise Solution - for me.

We are all looking forward to the new NetBeans 7.0 release which should come out in a few weeks. And the more excitement grows the more people start asking questions about if it's suitable for enterprise development or not.
According to the Java EE Productivity Report (2011) NetBeans has an overall usage that is about 12%. By far the most users (65%) rely on Eclipse. But why is this so? NetBeans is fancy as hell and even in my personal past I was a happy NetBeans user for a long time. In this post I try to summarize my own experiences and feelings about using NetBeans heavily. Please note, that this is not an objective comparison. I am happy to read about your thoughts!

Enterprise Requirements
Development of enterprise class software has some special needs. They all arise from the fact that we are mostly talking about bigger development projects with a whole team of developers which have to complete their job within a more or less short time frame. This leads to a couple of things a truly enterprise IDE can assist you.

Rollout into large teams
First requirement category is derived from the needs to rollout the IDE to a larger team quickly. This includes the initial installation and configuration and a following distribution to the team. The individual member should not feel the need for anything else than to unzip the project distribution to a suitable location and start coding. This is very easily achieved with Eclipse. You simply download and unzip the recent build and configure the needed plugins before zipping everything up again and distribute it to your team. There are even some very decent central packaging and distribution solutions available which make it very easy to standardize on enterprise level (compare Yoxos from Innopract). If you are more interested in any pre-packaged solutions you could even thing about using MyEclipse or comparable offerings.
NetBeans doesn't have this kind of valuable ecosystem. The most complete way of installing NetBeans is offered by the OS dependent installers. The OS-independent set is feature limited (but only 23MB smaller than the installer for windows). I don't know about any management solutions comparable to Yoxos or even other bundles. So you simply have to take what is offered in terms of technology packages.
In addition it's most important to have a separation of configuration. You need to be able to differentiate IDE and project specific settings. The "workspace" approach used by Eclipse is a very convenient way for that. You simply have to put the complete workspace under version control and every developer has a consistent development environment to start over with.
Project and IDE settings with NetBeans are very distributed between the project and the installation folder. If you are willing to keep a consistent project setting for a whole team you are probably forced to send updates around via email.
Don't get me wrong. You can actually rollout NetBeans to larger teams. But if you try to do this with a complete environment (Server, Build-Tools, etc) you quickly run into trouble if anybody is not using the same installation folder or want's to change some locations afterwards. This is not necessarily a problem with NetBeans itself but possibly a trade off in favor of the tight integration with the supported servers and build-tools.

Fast development
Beside this, key to every IDE is it's ability to let developers code fast. There are a couple of places you experience this. The most obvious ones are the available templates and shortcuts. Both IDEs are strong here. You could even partly configure the NetBeans shortcuts to work like Eclipse shortcuts. But what's very different is the code completion. You don't realize this if your are only doing small examples. If you ever tried to use NetBeans with a large and probably not too well designed project with too big classes and many files you quickly find yourself having to pause up to 2 sec. after typing a single character. Code-completion is slow. Another issue I have with NetBeans are the project scans happening. They take too long and appear too often. The larger your projects grow, the more problems they make.
Next big point is the server integration. That is nicely done with NetBeans. Especially the GlassFish and Tomcat integration. Smoothly. And hot-deployment works .... as long as you stick to the generated ANT scripts. Switch over to maven and your out. Same is true for Eclipse for sure. But then non of the IDEs really makes a difference here. But there are solutions upcoming. The Oracle Enterprise Pack for Eclipse already can take full advantage of the Fast Swap feature for WebLogic deployments. I bet, this is going to swap over to GlassFish soon.
Let's look at the maven integration. It's natively build into NetBeans. And it simply executes maven on behalf of the IDE. You have a nice repository view and some ways to create and modify mavenized projects. You can add dependencies and have a couple of ways to run the goals with the profiles you need. What about a simple and helpful editor for pom.xml files? what about visualizing dependency hierarchies? There are a couple of other things that m2eclipse does far better for me personally than the NetBeans integration.

Quality insurance
One of the most important things in enterprise projects are the available tools for quality checks and insurance. FindBugs, Checkstyle, you name them. For any of the tools you can find an .... Eclipse plugin :). Some have NetBeans support but most not done by the tool developers itself but by third parties. This leads to outdated integrations or force you to use complete packages (like PMD) even if you only need parts out of it. Subjective it feels like the PMD integration with NetBeans is many times slower than any of the Eclipse plugins I know.
If you look at Code-Coverage: A cobertura plugin was available in prior NetBeans versions. It does not seem to be there with 7.0. The only way to have any information about code-coverage is to use the cobertura plugin. What about Emma? Nothing. And there are some more examples. TestNG integration for example. Because of tight integration of JUnit testing framework in NetBeans most IDE-wide tests related actions do not work for TestNG tests. Even if there is a plugin you can install manually (don't expect this to be an official plugin).

Let's look at team collaboration solutions. Codebeamer? Rational Team Concert? Any other commercial solution? NetBeans supports Bugzilla and JIRA. You probably will find Eclipse integrations. In general the plugin experience with NetBeans simply is worse. If you use the pre-configured three Update-Centers you get a total of 30 Plugin proposals. If you look at the plugin central you can find additional 600. Many of them seem to be outdated (e.g. JAD integration). The presentation is worse. Hardly any documentation. Some broken links. No images. A website I am not willing to use. In general NetBeans only has 1/3 of the number of Plugins which are available for Eclipse via the Eclipse Marketplace (which has 1,064 "solutions").

This is quite a bit unfair because this mostly relates to latest NB 7.0 Betas and RC. But I have the subjective feeling, that NetBeans is unstable. I've had lot's of exceptions and unresponsivenesses during development that I was not able to track down. If you take a Java EE 6 development project you quickly start over NetBeans a couple of times during the day because of that.

Bottom line
Thanks NetBeans. It was a great time playing with you. And I guess, we could get used to each other again for doing teaching, showcases, wizard driven developments. But if I have to do an enterprise level project with many developers and a tight timeline I will chose Eclipse.
What are your experiences? And please don't talk about your experiences with your 20 classes projects.

Wednesday, March 16, 2011

New article for latest JAXmag "Java EE 6" about Arquillian

Just a short notice. You can find a new article of mine in the latest JAXmag issue. This issue of JAXmag is dedicated to the latest industry standard for enterprise Java computing: Java EE 6.
This issue of JAXmag introduce the readers to the various technologies that comprise Java EE 6, with the 'Java EE 6 Overview' article by Caucho Technology engineer Reza Rahman. We'll examine some of the technologies that occupy the Java EE 6 space, with articles on JBoss' Arquillian integration testing tool, and the Siwpas application server, and look ahead to the relationship between enterprise Java and the cloud in Ales Justin's 'Java EE inside GAE' article.
Get it: It's for free!

Aiming to Make Testing Easier
Integration Tests with Arquillian
Since the early days of Java Enterprise Edition, testing of container components and their interaction has been a pain-point. Their cooperation with other services has been traditionally difficult to simulate. With the increasing functionality of the container (dependency injection, etc.) cross-links and dependencies have also grown. A fully automated integration test suite previously consisted of many JUnit tests. Now, Arquillian aims to make this task easier by offering the first complete and integrated test suite for integration testing.

UPDATE (19.05.2011):
The article is now available in an online version (HTML).

Tuesday, March 8, 2011

Both Weblogic and Glassfish are strategic products for Oracle

VP Development Anil Gaur and Product Manager Adam Leftik explain Oracle's strategy for creating increasing integration between GlassFish Server and Oracle WebLogic Server with an overview of new features and functionality for developers in GlassFish. The 21:23 minutes Techcast moderated by Justin Kestelyn is good as always and I found the time to transcribe some quotes from it (sorry for any mistakes I did...). It's interesting to see, how both products coexist and grow together over time. The first 10 minutes are worth watching if you are interested in interoperability. After that you get a brief intro about the new and exciting GlassFish Server 3.1 release.

Watch the complete TechCast replay on Oracle Media Network. I would love to have embedded it here, but it's still a Flash player and I'm not going to embed this kind of video playing stuff here.
Anil Gaur and Adam Leftik
"Both Weblogic and Glassfish are strategic products for Oracle"
(Anil Gaur)

"GlassFish it's industry leading Open Source Application Server"
(Anil Gaur)

"We are using GlassFish server as a means for providing innovation and the ability to get features out into the broader Java EE developer community quickly.
As well as also bringing technology and innovations back into WebLogic Server vault."
(Adam Leftik)

"The customers today they can start with GlassFish, when their enterprise need grow, they will need a more comprehensive solution and WebLogic Server will fit in right there."
(Anil Gaur)

"We are gona be use more shared components from GlassFish, so a couple of examples there: We are taking the latest version of JSF in addition to that CDI, we gonna share a common CDI implementation as well.
EclipseLink will sort of move into the TopLink grid features that are part of the EclipseLink vault [...] providing a common reverse proxy plugin."
(Adam Leftik)

"And we are learning from WebLogic in terms of like the Coherence integration, how we can pull in that functionality and integrate with GlassFish."
(Anil Gaur)

Friday, March 4, 2011

High Performance JPA with GlassFish and Coherence - Part 3

In this third part of my four part series I'll explain strategy number two of using Coherence with EclipseLink and GlassFish. This is all about using Coherence as Second Level Cache (L2) with EclipseLink.

General approach
This approach applies Coherence data grid to JPA applications that rely on database hosted data that cannot be entirely pre-loaded into a Coherence cache. Some reasons why it might not be able to pre-loaded include extremely complex queries that exceed the feature set of Coherence Filters, third party database updates that create stale caches, reliance on native SQL queries, stored procedures or triggers, and so on. This is not only an option for local L2 Caches but with additional configured Coherence instances on different nodes, you also get a cluster-wide JPA L2 Cache.

As with many Caches, this is a read-mostly optimization. Primary key queries attempt to get entities first from Coherence and, if unsuccessful, will query the database, updating Coherence with query results. Non-primary key queries are executed against the database and the results checked against Coherence to avoid object construction costs for cached entities. Newly queried entities are put into Coherence. Write operations update the database and, if successfully committed, updated entities are put into Coherence. This approach is called "Grid Cache" in the Coherence documentation.

Move it into practice
Start with the previous blog-post and prepare your environment, if you have not already done so. There is a single thing, you need to change. Go back to GlassFish 3.0.1 / EclipseLink 2.0.1 for this scenario as there is a problem with the CacheKey.getKey() method. The 2.0.1 returns a Vector, the 2.2.0 simply returns an Object. Seeing the new Oracle GlassFish Server 3.1 having support for ActiveCache, I expect this to be fixed with the 3.7 Coherence release. But until than, you have to stick to the old GF or EclipseLink.
Anyway, lets create a new web project with your favorite IDE (e.g. GridCacheExample). Add the required libraries (coherence.jar, toplink-grid.jar and the eclipselink.jar). Now let's create our entity class and add the extra @CacheInterceptor annotation to it:

import oracle.eclipselink.coherence.integrated.cache.CoherenceInterceptor;
import org.eclipse.persistence.annotations.CacheInterceptor;

@CacheInterceptor(value = CoherenceInterceptor.class)
public class Employee implements Serializable {

Don't forget to add the @GeneratedValue(strategy= GenerationType.SEQUENCE) as this is needed in opposite to the last example. After this is done, you have to add the coherence configuration to your WEB-INF/classes folder. You can start from the tutorial (Example 2). (be careful, there is a typo in it ... a dublicate </backing-map-scheme> tag). Configure your persistence.xml as you would do with a normal JPA based application.

<persistence-unit name="GridCacheExamplePU" transaction-type="JTA">
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.logging.level" value="FINE" />

That's it basically. Now you can test your new L2 cache. A simple servlet should do the trick:

public class InsertServletPart3 extends HttpServlet {
@PersistenceUnit(unitName = "GridCacheExamplePU")
EntityManagerFactory emf;
UserTransaction tx;

EntityManager em = emf.createEntityManager();
// some loop magic
Employee employee = new Employee();
// some loop magic end

If you watch the log, you can see something like this:
 bind => [Eisele, Markus]
FEIN: Coherence(Employee)::Put: 1 value: net.eisele.coherence.entities.Employee[ id=1 ]
Which basically tells you, that the actual database insert is carried out by EclipseLink as you are used to. After that, you can see, that the Employee object is put to the Coherence Cache named Employee with the PK as it's key.
If you now issue a query against the database

em.createQuery("select e from Employee e where e.lastName = :lastName").setParameter("lastName", "Eisele").getResultList();

you see the following:
 bind => [Eisele]
FEIN: Coherence(Employee)::Get: 1 result: net.eisele.coherence.entities.Employee[ id=1 ]
FEIN: Coherence(Employee)::Put: 1 value: net.eisele.coherence.entities.Employee[ id=1 ]
Which tells you, that the query itself is issued against the database but the results checked against Coherence to avoid object construction already for cached entities. Newly queried entities are put into Coherence. If you issue a simple PK query:

em.find(Employee.class, 1);

the output changes to:
FEIN: Coherence(Employee)::Get: 1 result: net.eisele.coherence.entities.Employee[ id=1 ]
and you don't see any db query at all. That's it :) Your cache works! Thanks for reading. Stay tuned for the next part!

Further Reading
OTN How-To: Using Coherence as a Shared L2 Cache
Integration Guide for Oracle TopLink with Coherence Gird 11g Release 1 (11.1.1)

Tuesday, March 1, 2011

Time to take the red pill.

It was nice. Being a part of the Center of Competence IT-Architecture at the msg.Applied Technology Research for nearly eight years has brought me where I am. It was a pleasure to help customers, projects and coworkers with their daily problems around Java EE and my favorite application servers. But things need progress and there is no progress without change. So it was time to decide weather to take the blue pill - end the thoughts, and wake up in my bed and believe whatever I want to believe. Or to take the red pill - staying in Wonderland and looking how deep the rabbit-hole goes. (see: Matrix quotes)

This is what I did. I took the red pill and so the new year will bring some changes for me. I will be leaving the position I am in. Moving on to another division within the msg systems ag, called Insurance Business Consulting. I will be part of the IT-Strategy and Architecture department and as such working with our customers on their visions and needs. As expected, I have to change my working habits a bit. In the past I was frequently helping a lot of projects during the year (~40/year makes roughly 300 projects in the past years ;) ). From now on, I will work on fewer but probably bigger projects and have the opportunity to structure and design a lot more and do less firefighting.
All this will hopefully not influence my involvement with the Java EE / GlassFish / Oracle community out there. I'll try to get posts out as usual. Even if it looks like, I can not avoid to spend one or two words on insurance related topics in the future :)  So, thanks again for listening and reading. Moving on with an exciting 2011!