Michael Nascimento Santos's Blog

Tools Archives

Making your components work nicer inside Matisse

A co-worker had been developing some nice-looking custom components for a customer project. It was tightly integrated with the backend logic, though, so he tried to use it with Matisse, there were several issues, from class loading errors to slowness, since the component was trying to do its "real task" inside the designer.

So, when he told me that, I immediately recalled a trick I came to know way back in 1999, while I was struggling with Java and Swing for the first time. The java.beans package comes with a class named Beans that comes with a bunch of static utility methods. One of them, isDesignTime(), let your component find out if it's being used in preview mode.

He changed the component constructor to check for design time and skip the "black magic" section. It worked like a charm and he said it was the best tip I gave him last year. So now I've finally had the time to blog again, I thought it would be an interesting tip to share :-)

Desktop development made easier with genesis

It's been quite a while since the last time I mentioned genesis here. One of the reasons is I've been working on it a lot and there isn't much time left to blog about it. Hopefully I will be able to do so more often.

We have just released genesis 3.0 after almost two years and a half of development. genesis is all about making the development of enterprise desktop applications easier. To accomplish that, genesis provides UI-related features and also a neat way of building and integrating with the back-end of your application. For now, let's focus on the desktop itself.

genesis 3.0 comes with full support for Swing, SWT and Thinlet. It supports binding, validation, actions and conditions. Let us say that for the desktop it tries to address nearly the same problem space as JSR-295 (Beans Binding), JSR-296 (Swing Application Framework) @Actions and JSR-303 (Bean Validation), but there are enough conceptual differences between them (besides supporting SWT and Thinlet out of the box, of course). I've already explained the basic UI binding functionality last year, so here I will try to show why the genesis approach is better.

First, genesis works with an UI model, instead of plain binding. This means your JavaBean represents the UI data plus the presentation logic behind it. It makes your presentation logic UI toolkit-independent, testable and self-contained. It also doesn't require PropertyChangeListeners at all. Consider the most basic binding example in genesis docs:

@Form
public class LoginForm {
   private String user;
   private String password;

   public String getUser() {
      return user;
   }

   public void setUser(String user) {
      this.user = user;
   }

   public String getPassword() {
      return password;
   }

   public void setPassword(String password) {
      this.password = password;
   }

   @Action
   public void login() {
      System.out.println(getUser());
      System.out.println(getPassword());
   }

   @Action
   public void clear() {
      setUser(null);
      setPassword(null);
   }
}

If you were to do the same with JSRs 295 and 296, you would have to create a JavaBean with PropertyChangeListener support, fire property changes on setters and also create two @Action methods in your view that access your bean. As the number of properties, beans and actions involved in a view increases, your code with genesis would still be self-contained and testable, while JSR-295 would require individual bindings to be produced and your actions would be tightly coupled with Swing, manipulating your beans as value objects.

genesis also comes with some unique features of its own, such as declarative conditions. Let's analyze the classic dependent comboboxes issue: whenever the selected country changes, the state list should be reloaded. Here is what it takes to implement this with genesis:

@Form
public class StateSelectionForm {
   private Country country;
   private State state;

   @DataProvider(widgetName="countryTable", objectField="country")
   public List populateCountries() {
      return // business logic to retrieve countries
   }

   public Country getCountry() {
      return country;
   }

   public void setCountry(Country country) {
      this.country = country;
   }

   @DataProvider(widgetName="stateTable", objectField="state")
   @CallWhen("genesis.hasChanged('form:country')")
   public List populateStates() {
      return // business logic to retrieve states
      // Notice getCountry() will return the selected country
   }

   public State getState() {
      return state;
   }

   public void setState(State state) {
      this.state = state;
   }
}

So genesis will automatically invoke the stateTable @DataProvider whenever the selected country changes.

There are many other features and things to explore and I hope I can show them here in the next few days. The Brazilian Portuguese users list is quite active these days and there is of course an English users list. Check out genesis and let me know what you think.

Final JavaOne report

Ok, so after a long trip home, I finally managed to write the final installment about JavaOne.

In the morning, I attended Gavin King and Bob Lee's talk about Web Beans. The coolest thing about Web Beans is actually its dependency-injection support and the rich lifecycle model they are proposing. It is actually a merge between Seam and Guice strategies. It would be applicable to any kind of application, not only web-based, so my question was if they intended to split the spec so these features could be used, well, anywhere. They like the idea, but it is too soon to say. Let's hope they eventually do it. Watch out, Spring!

Then I attended the Effective Java Reloaded session. I haven't attended the 2006 session, but a few folks said it was too similar to last year's talk. I've already applied - and advocated - many best practices suggested during the talk, specially making everything final. By the way, Gavin, Bob and Joshua are great speakers and members of this group were in short supply this year. Sigh.

In the afternoon, I've (accidentally) spent some time with some NetBeans guys. First Roman Strobl:

I've told him a little bit more about my NetBeans pledge (expect a follow-up post about it). Then I came across Geertjan again, that showed me his musical notepad (you can find it at nbjfuguesupport). Guilherme Silveira was passing by and decided to make a video about it. He posted the first part in YouTube and hopefully he will upload the second part soon.

After that, I've attended the last few minutes of the session named "Stress Your Web App Before It Stresses You: Tools and Techniques for Extreme Web Testing". It was quite packed and it seems people liked it a lot. So, no need to be worried, Felipe!

Basically I spent most of the time in the afternoon and early in the evening. Then, I was at the Java Champions BOF. Java Champions are recognized by Sun as leaders inside the community. Some of them are Kathy Sierra, Bruce Eckel, Joshua Bloch, Neal Gafter, Jason Hunter, Calvin Austin and even myself. It was good to meet some of them and also to meet the program coordinator, Aaron Houston, a very nice guy.

Finally, it was show time: our BOF about JSR-310, Date and Time . As noted by Timothy O'Brien, the number of people who attended was impressive. Her is a partial picture:

We showed a few slides and some code Stephen started working on recently; we expect to commit this API to SVN soon. The audience made interesting comments and questions during the talk and after it - we had to stay there for almost an hour after our talk to address all questions. Some spec leads for JSRs that will make it to Java SE 7 were there and showed they intend to use our work and to support it. So, JavaOne selection team, keep it in mind for next year: date and time is a hot topic.

Once I had completed my main mission, I had a meal with some other Java Champions/JUG Leaders in a nearby restaurant. It was quite nice to meet these folks, shall I say.

From Thursday, I would like to highlight the excellent JFugue talk delivered mainly by David Koelle and with special guest star Geertjan Wielenga. David is a terrific speaker, his work is amazingly cool, his demos rocked and he managed to be funny. Geertjan also deserves congratulations for focusing on the main topic, JFugue, instead of just pushing NetBeans. Of course he mentioned his application was NB-based, but he actually focused on demonstrating how JFugue was simple to use, which just makes more people interested in his application and, well, NetBeans. So, another note to J1 selection team: we want more music-related talks, preferably with David!

Fabiane Nardon and Daniel Lopez's BOF, Designing Self-Evolving and Self-Configuring Java Platform, Enterprise Edition (Java EE) Applications, was also quite interesting and attended by several Java Champions. Nice job! The BoF I've attended after it was one of the coolest sessions in JavaOne: The "java.lang.OutOfMemoryError: PermGen Space" Error Message Demystified, presented by Frank Kieviet and Edward Chou. I couldn't believe they could actually spend 50 minutes talking about this topic with valuable information, but they actually did it. Having done a lot of profiling and OOME chasing before, I must say I could not explain the issue better. You must be on the Rock Star Speakers list for this year.

Fabiane and Edgar's session on Friday was very successful as well and Linda deMichiel and Kenneth, from JPA 2.0 and EJB 3.1, came to them after the session to look for input for their specs. Joshua's Puzzler session was really cool as well.

So, it was nice to meet everyone I didn't know in person before and to talk to all of you I've already known. See you in JavaOne 2008 (if any of my submissions is approved)!

Supporting script languages in your application

It's been over a month since we added generic script support to genesis, but it was such an interesting experience I've actually considered writing this entry part of my TODO list. I've finally managed to do it, so let's go to the main point before you all fall asleep.

Since its inception, genesis has been using JXPath in order to allow users to express conditions that controlls when fields are made visible or not, enabled/disabled, cleared, when a method should be called by the framework etc. JXPath is not exactly a script language, but rather a XPath implementation that works on JavaBeans as well. However, since I was particularly familiar with it, expressions written in it were clear and concise, it is possible to invoke arbritary Java methods from expressions and to export custom function libraries, it was very easy to use in our internal framework code, quite performant and had support for compiling expressions it was picked up as the way to express conditions.

Although we did like JXPath a lot, there were some reasons we thought it was worth supporting other options:

• XPath is tricky. For example, testing a boolean property using code such as value simply tests for the existence of a property named value, but not if it is actually true. You have to do value = true() for this, which is usually not what developers will try at first unless they really know these XPath specifics. It was never our intention that developers had to know this kind of things.
• People shouldn't be forced to learn JXPath to use genesis.
• People already know other script languages, such as JavaScript or EL, for example. It would be good if they could apply this knowledge while using genesis.

Since we decided we wanted to support new script languages, we had to come up with a design for that. Basically, instead of using an available abstraction as is, we wanted to make sure there was no performance degradation for our JXPath users and we were already aware of standardization efforts on this area - JSR 223 to be precise - that were not (and still are not) available for use. This motivated us to come up with a more generic design, in package net.java.dev.genesis.script. The general-purpose classes in this package are:

• Script: the main abstraction of the package, represents a script language implementation. It has methods that allows one to obtain an instance of ScriptContext (explained below) and to compile expressions.
• ScriptFactory: responsible for creating concrete implementations of Script
• ScriptContext: this interface allows one to perform context, script language specific tasks, such as obtaining the value of a variable, declaring variables, registering custom function libraries and evaluate expressions
• ScriptExpression: represents a compiled expression that can be evaluated in a context

The reason I said these are general-purpose classes is because there are other classes in this package that are more specific to genesis "business" itself, such as abstract support for genesis functions, but I won't explain these here though.

Now, back to the main plot, the next step was to add a JXPath implementation and that is what package net.java.dev.genesis.script.jxpath does. It wasn't hard at all since most concepts we abstracted are directly supported by JXPath in a quite direct way (such as generating a compiled expression for example).

The next step was to add support for two popular script languages: BeanShell and JavaScript. Although we could use our own infrastructure to build that, we were looking for a more general way of abstracting the usage of such languages and decided to use an already existing solution for that. BSF, the Bean Scripting Framework, an Apache Jakarta Project, proved to be a good way of plugging these languages into our infrastructure with minimum effort. Our general adapter package for BSF is net.java.dev.genesis.script.bsf and BeanShell simply worked perfectly with just that adapter. JavaScript required a minor tweak to work - class net.java.dev.genesis.script.bsf.javascript.BSFJavaScriptEngine - since it had problems with evaluating expressions in "child" threads (basically, its context is thread-specific, but genesis calls methods in a Script implementation in different threads, for several reasons) and boolean expressions do not return a java.lang.Boolean instance, but rather some bizarre org.mozilla.javascript.NativeBoolean object. Since this adapter class ended up being rather small anyway (71-line long, counting all blank lines and with the LGPL header taking up 18 lines), it was certainly worth it.

After we had support for at least 3 languages - we are still not sure how many BSF supported languages will simply work out of the box -, we still wanted to support another language web developers were familiar with. EL, the Expression Language first introduced by JSTL and later adopted by JSP, was chosen. Since EL as defined in package javax.servlet.jsp.el is just a SPI, we needed an implementation of it in order to support EL in genesis. The Apache Jakarta project provides an implementation of EL called Commons EL which we used in our solution.

As we started working in an implementation, we were amazed to find out most things we needed were defined in the SPI and not in the implementation itself. It is really rare for "young" specifications to have this level of support at the "standard" level, so I must congratulate the EL folks on that. Implementing package net.java.dev.genesis.script.el was mainly a simple task, except for the fact the SPI does not allow expressions to be pre-compiled without a FunctionMapper instance - which is not available when we do it - and it does not allow instance methods to be exported as functions. We got around the first limitation by using a specific method in Commons EL (as shown in ELExpression), but the second one would require EL specification changes and is a limitation our users will have to face for now.

So, it turns out supporting script languages in an application or framework is not a very hard task and it took us a few days to walk through the whole process, which included selecting the languages to support, study their documentation, look for an existing abstraction, modify our build process and a bunch of other tasks. In the future, when JSR-223 becomes final and an open-source implementation becomes available, it will be even easier to support script languages.

This work is licensed under a Creative Commons License.