Five things I like most at NetBeans Platform 6.8

NetBeans 6.8 is there since December 2009. It did not look like a very important upgrade at first. At least not very important for Platform developers. But using the new version of platform, some things which may appear small at first, has been visibly improved. The most important improvements are listed here (according to my personal feelings). For a complete overview of changes in platform API you can take a look here.

Wrapped libraries
That was one of the major headaches source. Developing modules for NetBeans (as for other platforms) requires sometimes links to other libraries. Third-party libraries, other than the modules provided by the platform, needs to be linked and wrapped in your custom pluggins or platform-based applications.

Wrapping libraries was done in the past in two ways. By creating a module library wrapper plugin for every library which need to be imported. But when you have to link a bigger library, which have a lot of jars, that was a pain. Because a module library wrapper could be created only for one jar. You can end up with easy to have twenty-thirty libraries only to link to something like apache logging libraries or Seam or similar.


The second approach was to create a big jar with all jars from library. For this operation, NetBeans is helpfull, but you have other two problem to solve. First is that the new jar will have it's own manifest. That means that if there is information in manifest files of every jar, that information is lost or not complete. If that information is important, you have a nice problem to solve. The second is that you can loose control over which libraries you have, which versions. Become very difficult in time to maintain the upgrades.

Solution is the new wrapped libraries feature. Now each plugin module in NetBeans can have it's own dependencies on external libraries. For configuration, you have a new tab panel to add as much as needed libraries. The cool thing is that you can specify also the source code and javadocs for every wrapped jar. That was not possible in the old versions.

ActionListeners are everywhere

That could not look as important as it is. In the old versions you could use ActionListeners only for always enabled type of actions. Not you can use the same interface also for context aware and callback action types. That is really cool, even it does not sounds like that at first. A main aspect here is that it is used a "well known" interface.

The first consequence is that if you want to migrate a swing-based app on NetBeans platform, is easier because you just have to pipe your actions. The second consequence is that you don't have to use specific platform interfaces like cookies. I don't say that cookies were bad, but they are old and there is better and much usable alternative.



Declarative Asynchronous actions

That's small, but makes code cleaner and flexible. Also throws away the need to manage yourself the asynchronous behavior of your actions. Nice done.

Enhanced IO API


We already had colors and links. And it was very useful. But now is even more flexible.

You can color the output as you like because you can output with IOColorPrint.print. So you can made your output lines from peaces colored independently. You can also put more hypelinks on the same line. You can, again, add an importance marker, which improves readability on verbose outputs. Finally, you can specify the parent of an IOTab and set its icon and tooltip message. All of them are small things, but used together can be very helpful on creating really effective and friendly output for your application. I appreciate very much an application which let you know what is going on.

Annotations

That's not a specific point. There are some very useful annotations added. The point is, thought, not the specific annotations added. But the trend to use as much as possible annotations. I hope that this trend will continue. I already used @OptionsPanelController.SubRegistration and @ConvertAsJavaBean. But there are more, take a look.

Common misconceptions about EJB

Java Enterprise is often a topic for many programmers in the free world (non m$ like one, I suppose ..). I don't think it was always a first option. There were and still there are pros and cons discussions. Still, Java Enterprise is an available solution. Thought, with a lot of books and good articles around, I often hear simply "amazing" thoughts about Java Enterprise. What is worst is that many of these are believed by so called Java Enterprise developers.
A lot of people still have some misconceptions about Java Enterprise. How this could happen? Perhaps due to the degree of configuration complexity of the firsts variants of the standard. Maybe because of the rigidity of the Sun guys, who kept in iron hands the previous releases (previous than 3.0). Perhaps because in the past the standard was not under JCP. Maybe none of this. I really don't know. But I will present some thoughts that I heard, and give some opinions on that.
EJB is for web applications
Simply wrong. Java Enterprise has nothing to do with web applications. To be more exact, Java Enterprise has the same link to web applications, as it has with other type of client applications. EJB is about business, about business distributed components and about integration. The consumers of these components can be any type of application that understands JNDI and IIOP, nothing more. Even if we see around a lot of web frameworks that are well integrated with EJB, that does not mean EJB is only for web.
With JPA you don't have to work with databases
I always considered that a good programmer is a lazy person. But a lazy programmer is a programmer which chooses to work less but smart instead of easy but with repeated tasks. If you choose EJB with persistence, than you choose to work with an abstract layer, which models your business. You choose to separate these layers. That does not exclude to improve the performance of database. There are often situations when a proper index can solve a big bottleneck. Don't be extreme on that. Persistence layer let you concentrate more on your functionality, don't exclude tuning database process.
EJB applications are always lazy
That is not true. I agree that Java Enterprise comes with a penalty performance. There is a cost for the ease of design and for generality. My idea is that every design tries to solve some classes of problems in trade of others. The art in application design (if there is one) is to make a good trade on that. It’s like in chess. If you want a benefit you have to leave something. The choices are core of the process. If your choices are good, the penalties are not relevant for your business. Going back to EJB, the initial performance penalties are traded for other benefits. As a sample, putting in place a cluster or a cache is not an easy job in state-of-art systems, in EJB this task is very easy. By choosing what components to be cached, the caching levels, by choosing a proper clustering structure you can benefit a lot. A common thing that is missed is the usage of entity managers. A almost always saw that the entity managers used are the default ones provided by wizards. That’s a bad choice. You must reconsider every opportunity. There are a lot of services for EJB components which can be configured with ease, that's the point. Don't put on work the wizards and consider you work done. You work begun after the wizards. Remember well, the choices are very important, and EJB container makes that job very easy.
Use EJB everywhere, is the best
Nothing is the best for everything. EJB has its place in software fauna. But it’s not best for anything you can think of. Sometimes you must consider using light web frameworks, sometimes is better to use light web scripting languages with fast databases. I can give clear receipts. If I put my two cents in, the rigid thinking does not do you any favors.
EJB is only about components and services for these components
I don’t agree. It’s true that components and container services for these components worth a lot. But there is something more, which I consider at least as important as the previous. This valuable thing is integration with external systems. I lot of people forgot that. But one of the main goals of EJB is the integration of external systems. The integration potential is, sometimes, the main reason to choose EJB in place of others technologies. We can review the times when EJB was put on place. A lot of big software consumers had a lot of big systems provided by different software vendors. It is a usual. Every system produces a part of the big picture. A lot of effort and money and knowledge are buried in those systems. The next step is to obtain the big picture. You can’t rewrite everything from scratch. You have to integrate the existent system. You have to put all the pieces together. EJB is good at that. Did you hear about resource adapters? Did you saw a detailed sample of a CORBA component written in C working with EJB? I bet you don’t. Unfortunately I never saw books with covers well this topic. Three pages from five hundred are not enough, but that is the sad average. I am still waiting for a good book to cover this, to exploit this potential.

Concerned about JBoss Seam? Don't worry, it will be better

I am a big fun of Java EE. Don't ask me why, if it's not obvious I will explain in another post. Even of the fact that I like Java EE that much, that does not mean I consider it perfect. In fact is not perfect at all.
There is place for a lot of improvements, a lot of them are on the road to be included in the next versions of standards, others not yet. So, working with Java EE alone, sometimes could be a pain. That's why I put in place Seam Framework. Seam Framework is a perfect match for Java EE on server side. It gives you a lot of things which the standard has not. You have Seam components and Seam contexts, which is a big progress. I don't mention the whole features of Seam here, even those have a great weight. If you want to see details on that you can see on http://seamframework.org/. I worked with Seam on three medium/big applications and had a lot of reasons to be happy.
But in these days I had some black thoughts on that. I was wondering what will happen with Seam. You could honestly ask yourself why, if everything was so fine? Just because of WebBeans, the new standard. Here is the story.
O lot of good people of JBoss and Seam were working on the new proposals from JSR. They provided a lot of work and results for EJB3 and JPA. Now they are ready to publish the new JSR-299 Java Context and Dependency Injection ( aka. WebBeans ). That is a great JSR and I am waiting to work with. The WebBeans comes to provide a standard for the main lack of Java EE applications. The poor integration between EJB components and JSF components ( aka. managed beans ). That was the core job of Seam Framework. Now WebBeans put these two layers together, by allowing EJB components to act as JSF components. We will have more multiuser secured acces and transactions on the components beneath JSF, and that's really cool. In fact WebBeans have knowledge from Seam Framework, Struts Shale, Oracle ADF and Google Guice inside.
So what will happen with Seam in this context? The JBoss will renounce at Seam in favor of WebBeans? I was thinking on that until I read a very clear statement from JBoss. You can find it here. It explains how Seam Framework relates with WebBeans.
WebBeans implementation form JBoss will be the core on which Seam will be based. All the good things from Seam related to components and contexts will be based on that and that. Seam Framework continues, it will be alive. And most probably, it will give you in the future also, a lot of reasons to stay sticked your business and use EJB in a painless way.
The good thing here is that we could use WebBeans implementations from another providers together with Seam Framework, it's a standard, isn't it?
If you didn't give a try to Seam Framework, you should start to do it right now. EJB and Seam is a winner bet. Thanks to all guys who works on that.

Slow death by technical debt

Did you here the words "can't have time now, implement that quickly" or "we need a.s.a.p. that for a presentation"? If you did that, you should know that you are in the middle of the battle. Invisible bullets go near your ears and you and your team are living on the edge. That's not bad in itself, but can became as bad as can be soon, if you can't handle. I'll explain why.

When you have to implement something, either is a new feature or a solution for a bug, you face one common problem. You can take main scenario, fix what it should do and go further. That's called quick and dirt. That is because the code resulted from that is really dirt. The second and best approach is to face to problem for today and tomorrow. Think hard and implement the optimum solution, use a good design. As I said, there are times when quick and dirt saves you from something. Is like in management, the difference between important and urgent. The urgent sometimes is more useful than important. But this has a trade off.

Ward Cunningham invented a metaphor for that, which fits well in understanding the implications. This metaphor is called Technical Debt. Technical debt is similar to financial debt. When your business needs something urgent and you don't have enough money, you borrow some from the bank and do your job. After that you have to pay interests and principal to return the debt. Same in software, but here you deal with quality in place of money. Sometimes to get a good deal, to touch a milestone or to give something with few resources you can accept quick and dirty. After the deal is done you can decide if you live with that or you refactor it, using a good design this time.But you must have always in mind the working on poor code means paying more interests. And if you pay too more interests your deals could became a bad one. So, for your health, refactor as soon as possible. That is called paying the principal and eliminate the technical debt.

Quality in software means resources. You have to spent more resources to have better quality. As Martin Fowler said here, technical debts hurts performance. And the performance is almost unmeasurable in software. You have to manage a proper balance in your technical debts. If you hear the magical words which leads to quick and dirty, open your ears. If you don't hear soon about refactoring tasks, you should put your questions. If these things come again and again then you could go into a swamp with your projects. Everything begins with parts of code which is considered ugly and unmanageable. These become to stink. The project can go to the slowly path of death by technical debt suffocation.

How to handle technical debts?

There no standardized solutions. That's because is hard to measure and because managers like Excel too much. They like to see numbers, that give them the sensation of control. But numbers are not so bad. They really don't show the things how they are (don't let the managers know that!), but the process of getting these numbers enforce some processes which could help in handling technical debts.

A good individual exercise which I practice is using of IDE meta comments like TODO, FIXME or somebody else from the family. When I begun to implement something which is complex somehow I use TODO comments. I use them as bookmarks to remind me that I should complete something. These marks will be removed until I submit. So they exists only to remind to my poor memory that I did not finished the job. Before submit I check to see if everything is like I want by verifying and removing these comments.I call them Transient Technical Debts. Transient because these technical debts are not persisted into version control system.

A similar approach could be followed for the persistent technical debts or the normal technical debts. You can you a marker like FIXME. Maybe a FIXME and a date. Better is to have also a system for controlling them. A good approach is to put an effort in the next iteration of your software and eliminate them. So all the technical debts you accumulated on the current iteration will be paid in the next one. Just to keep things in control.

Another approach is to keep that ledger in the bug and task tracking management system. You can have some attributes on tasks and bugs which tells us if the job was done quick and dirty or not. If we have to spent more effort to put a good implementation in place of a poor one. A mixing solution is to have code comments linked to that kind of a system.

These kinds of ledgers are good because they can give you numbers also. It forces you to have a health quality of the software and keeps you manages happy. They have the input for nice charts and reasons for raise your salary. Anyway, keep your ears tuned and don't go int the technical debts swamp.

Java EE is just Java

I write Java EE applications for about some years. During those years I learn some things and give some cents to others. But most productive things which were happen were the discussions on that topic. When you talk with somebody on a subject where both have some knowledge, you find usually nice points of view. Also I noticed that in the same the same time, the same problems are bypassed.

A lot of discussions on this subject happens having in mind that Java Enterprise applications are applications made from distributed components. That's true. Java Enterprise applications some standard services provided by EJB and web container. That is also true. Java Enterprise are build only from EJB layers ( entity beans - now JPA, session beans, message beans, etc) and presentation layers. That is not true. There is something missing here. Java Enterprise applications are still Java applications. What is the meaning of this note? The fact that Java Enterprise applications are still Java applications is an aspect which is often forgotten or simply not took into consideration. When you build a Java Enterprise application you don't loose the possibility to do the same things as you would do in a normal Java application.

When you debug a Java Enterprise application, as a matter of fact you debug a Java application. The debugging feature is something which happen on the virtual machine and class loader level (more on that on a future article). You debug in the same way a Java EE application as you would do with a desktop application, even local or remote, even through shared memory or TCP port.

You can have static or singletons or factories as would you have with normal Java application. I remember a discussion on a forum when somebody put the following problem. Every client is represented by a stateful session bean. How you would implement a communication between those clients? A saw a lot of responses, more that 15 on that topic. All of them stating more or less that you cannot avoid to use persistence layer to store information to be used by different clients. Nobody thought at a simple solution. A singleton which would hold information send by every client and requested by others (was a IM problem). Don't say that the singleton is the best solution. I state only that developing Java EE solutions sometime makes you think that the only things that you can do are EJB components. That's not true. You can however do everything you want.

The only differences between a Java application and a Java Enterprise are:

• The Java Enterprise application is loaded and started by a special piece of code called container (EJB/web), the normal Java application does not need to be started by something else, could have it's own main entry point
• Java Enterprise applications are packaged in a specific way to achieve the third difference, while normal Java applications don't have this constraint
• Java Enterprise applications can use services provided by EJB and web container, while normal Java applications can't (only if you you an embedded environment)

An that's all. In every other aspect these applications are the same: Java applications.

Interface vs Annotations

When I think about OOP languages, my 2 cents goes into choosing a good contract between the components of your code. I never liked "smart" solutions which tries to steal a little time from here, a little from there and so on. Don't say that there are no good solutions of that type. When you accommodate a generic solution to a specific problem, you might be find that your code is much better. But, to be in that position, you have to have first the best design possible. That gives good solutions in every day practice. And a good OOP design implies healthy contracts between components.

Interfaces apart from classes can define a contract without implementation. Interfaces exists only as pure contracts. And interfaces are firm contracts. If a class implements an interface you can be sure that it will respond to you on the contract terms. Of course, nobody saves you from a bad implementation behind, we should live with that possibility.

Interfaces solves somehow the multiple inheritance problem. Can't agree on that

When we think a contract we have in mind classes which consume services stated by interface and other classes, behind interface, who provide the service. In this way interface acts as an indirection between two classes. You can change always the consumer or the provider of that service, things will go on. There was said that interfaces solves somehow the multiple inheritance problem. Can't agree on that. Interfaces does not provides behavior. The classes which implements multiple interfaces provides the behavior. Still, the implementation classes can't be considered as multiroot inherited. The main difference is that the class which implements multiple interfaces doesn't inherit behavior. And that is the main purpose of multiple inheritance.

Multiple inheritance is a bit clumsy and error prone

I always considered multiple inheritance as a bit clumsy and error prone. When a class inherits two behaviors we live on the edge. If the behaviors are small than there is a possibility to handle things in a logical way. If the behaviors are rich in features, that we are already doomed. That is the worst form of dependency. But even if we are in the best situation possible that an be on short term only. In time things can roll on in a bad way. Considering that the maintenance of the code is the biggest stage of a software component, there will be usually a lot of occasions or opportunities to "improve" and "enrich" the behavior of a component. If a class inherits multiple behavior, these kind of improvements is a curse.

Thanks to James Gosling and others that they don't allowed that in Java. But there are problems which still need to be solved.

Interfaces define how a component should look to be albe to be used by others

Interfaces can define the form of a class. That's why they are called interfaces, right? The interface defines how a component should look to be albe to be used by others. We can have marker interfaces or interfaces with content. Our clases can be less or more polluted by methods implemented from many interfaces. For that we allways have the addapter solution. When we have a class which needs to address many targets we always can split the class in many pieces. The main piece will retain the original goal of the class. The other classes will adapt the main class to othe target, of course, by providing appropriate interface implementations. That address well the mltiple inheritance gap. But can be better, and here comes annotations.

Annotations don't enforce types, don't enforce method signatures or exceptions, like interface does

Annotations are like interfaces, but there are suble differences.Interfaces defines a contract on a whole class. Annotations defines contracts for a class, method, field and others. Like interfaces annotations does not provide behavior. Still, the interfaces defines the form of a possible behavior in a complete way. Annotations don't imply these kind of restrictions. The consumer of annotations will have to handle evenrithing in a more generic manner. Annotations don't enforce types, don't enforce method signatures or exceptions, like interface does. That's way provider classes should alter their code to include the contract of it's implemented interfaces. Annotations don't pollute business code. Don't pollute contract of a class. They just decorate the class.

Annotations can be considered more like a part of the consumer which relies on the provider

Let's take the simplest case for the moment. The marker interfaces. A marker interface is an interface which don't have a body. The are used only to "mark" a component. Just to know at runtime that a class "is a" kind of something. You can't use a marker interface to call methods. A classic example of marker interface is java.io.Serializable. When a class implements Serializable, we know that this class is allowed to be persisted. The interface is only a semantic to serialization. The same effect could be achieved using an annotation on class level. We know that on serialization problem, because of the fact that annotations were not invented at that time. Considering that, the interface solution is a normal solution. Still, if we had to design serialization now, when we have all, what should we choose? I would still choose interface. Both annotations and interfaces are ment to adapt a class to a specific usage. Thought, the interfaces are more a part of a class, more dependent to a class than annotations. Annotations can be considered more like a part of the consumer which relies on the provider. That's why they are more dependent of consumer class than interfaces. If on marker interface teh case is not very clear, we go further.

The only discriminator to choose interface or annotations is the degree of business cognation or similarity

When we want that a consumer class to use another one we usually need that the provider class to tell somethings about that. We can do that using an interface to be implemented by provider class or by using annotations. When we provide information to the consumer we have to fight against code pollution. Even if the provided information is in small or big quantity the problem is still there. The only discriminator to choose interface or annotations is the degree of business cognation or similarity. If we want our class to provide a functionality closer to its bussiness purpose, the most appropriate is interface. If we want our class to be used in a completely different way, apart from it's original scope we should use annotations. Finally, if both ways conduct to a lot of work to adapt, we are probably on a wrong way. We should give a call to adapter or it's cousins to help us because in most of the cases our problem can't be handled by our class. We take a look on two examples for clarifying purpose.

We have a BusinessProcess class which handles information about a process of our business. This class is a java bean, so all properties have setters and getters. Nice simple class. This class provides some methods to run a process, to stop it while is runnings and to collect output data as results.

We have to implement a GUI interface which shows us a log with running events, when tasks have started or stopped. A simple GUI list and that's all. We decide that the model behind the GUI to be a class which handle running business execution events. Because announcing when a process has started or stopped fits very well with our class, we can define an interface for Observer pattern. That interface can have as a sample onStart and onStop methods, with process name as a parameter. So our GUI model will implement our ProcessNotifierListener interface. Our BusinessProcess class will have methods to add or remove listeners of that type, and will call them when any event appeared.

Our classes should not be aware of the problems which don't relates to it's business

Second task is to provide a way to specify the level of logging information for each type of process. The purpose is to show full logs for processes related to security transactions. The other type of processes will have only regular logs saved. We can do that by enforcing and interface with a method. But more appropriate is to use a custom annotation with a property defined. Like @LogLevel(LogLevel.FULL). At runtime we can read the annotation and action appropriate. Why is better to use annotations in this case? Because the logging activity is not even a secondary business purpose of our class. Our classes should not be aware of the problems which don't relates to it's business.

The discussion is never ending. For sure there are not rule appliable everywhere. And you always should reevaluate the case on using interface or annotations. That's whay good programmers are valuable. Thought, at least some of the questions, if not answers, will raise in your mind after reading that. Happy choosing!