Michael Nascimento Santos's Blog

JSR Archives

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)!

A public pledge to NetBeans

I could not be more disappointed after attending the Swing GUI Building With Matisse: Chapter II presented at NetBeans. It's not a problem with the Swing Application Framework or the NetBeans tooling; it's a problem with freedom of choice, vendor lock-in and a close-minded approach, not community-like friendly by the NetBeans guys.

I hate to make such issues public, but I've been trying to solve this in a civilized way for a year. Almost two years ago I've filed an issue about making Matisse extensible. It was ignored for a long time, but over time, I become hopeful again since the NetBeans roadmap indicated that Matisse would support binding for NB 6.

Over six months ago, I've emailed Tomas Pavek, the NetBeans Matisse lead developer (as far as I know) and Scott Violet, who was the spec lead for JSR-295, Beans Binding, to make sure Matisse implemented it as an abstraction, so it was possible to use Matisse with other binding technologies, such as JGoodies Binding or genesis. This email resulted in a thread in which I explained to Tomas what was needed in the API in order to support other frameworks (basically, abstracting how you interact with the binding "metadata"/API and providing extension points to generate the specific binding API code).

One thing that limited my analysis before was the fact there was no publicly accessible code for JSR-295 or the NetBeans support and I was told that a public preview would be available in January. Well, as most of you know, it has only been made available a couple of days ago.

Today, during the session, I mentioned that while I actually found the tooling fantastic, many folks (just for an example, read this) have all kind of issues with Beans Binding and whether NetBeans would allow its users to work with other binding frameworks, by providing a API that is extensible. While Shannon Hickey, the new JSR-295 spec lead, understood it's not like I'm bashing his work, the NetBeans guys simply said they just want to support the standard. What does it mean to you?

• If you don't believe that beans binding as a concept is the correct way to make GUI development easier (genesis does what we call "UI binding", which is different, much simpler and straightforward), you're lost
• If you are working with Java 1.4, sorry; NetBeans will never have a decent solution for you since JSR-295 is targeted at Java 5
• If you want to use a solution that already works with other UI technologies, such as SWT, sorry, no donut for you
• If you want to keep the binding logic apart from the UI logic, there is no way
• If you have an existing project or someone pushed another binding solution in your project, you will actually have to branch Matisse and override it to support it

Obviously, the first answer would be: "hey, but about maintainance?" but no one is asking for a JGoodies or a genesis binding module to become part of NetBeans; I am just asking for the possibility of doing so if needed without branching Matisse. And, heck, I've read Matisse's code: the kind of support I'm asking for would require just a few days to extract the dependencies and create an abstraction based on interfaces and going through the API review process, that would allow people with enough knowledge about other binding solutions to validate it. That is it.

So, to sum up, what I'm complaining about here:

• Sun has always promised us we would have freedom of choice, but NetBeans will get us locked in beansbinding (vendor lock-in)
• NetBeans should listen to the community and work with the community. For years, there weren't a standard approach for binding and there are tons of folks working with other frameworks right now that could benefit from having a plugin that allows them to work with their current binding solution.
• If NetBeans wants to become supported by the community, it shouldn't bite the hand of those that helped to evangelize it. I have been actively promoting NetBeans in Brazil for a few years now, both as a consultant and as a SouJava organization member. I just want to help NetBeans to help its users, but apparently NetBeans developers want to push Sun's solution down our throats.

Here is my request: show me I am wrong. Show you can listen to the community. Show me freedom of choice is not just some marketing rubbish. Please.

It's high time: a Date and Time API for the Java SE Platform

A few times in the past I've considered writing a blog entry summing up all the problems with Date, Calendar, TimeZone, DST rules and other JDK related classes. If you think these APIs are simple, functional and do not cause any harm, believe me, you really haven't done anything trivial with dates. Besides the classic "days are 1-based, month are 0-based" issues and the lack of many major concepts, such as date without time, any date/time calculation fails miserably when it includes a DST start or end date. There are simply too many issues with the current API to list here.

However, the point of this entry is not to bash the current Java SE API, but rather to talk about JSR-310: Date and Time API. As stated in the JSR, it "will provide a new and improved date and time API for Java. The main goal is to build upon the lessons learned from the first two APIs (Date and Calendar) in Java SE, providing a more advanced and comprehensive model for date and time manipulation."

Our main inspiration will be Joda-Time, a great open-source library originally created by Stephen Colebourne (who will be co-leading the JSR), that you should definitely use today to deal with date and time. We won't simply rename Joda-Time and bless it with the JCP approval stamp. We actually want to learn from it, use Java SE 5 features to design an easier-to-use API, remove all deprecated, complex and not mature enough features and also consider addressing a few issues currently not solved by it.

If you want to help us, join the jsr-310 java.net project and subscribe to the mailing lists. If you think you are an expert on the matter, consider joining the expert group. We intend to run this JSR as transparently as possible though, so your voice will be heard even if you just join the java.net project.

Bitten by the class literal change in Tiger

If you are a returning reader, you're probably aware of the enum implementation I wrote for Java 1.4 almost three years ago. Running some Java 1.4 compatible code compiled with Java 5 has just called my attention to a supposedly low impact change that was implemented in Tiger.

Since Java 5, a class literal, i.e., an expression such as MyClass.class does not trigger class initialization anymore. This is a well known, documented issue, but solutions are not clean nor cover all previously supported scenarios.

Let me explain how my enum implementation is affected by this bug so you can understand if this bug might affect your Java 1.4 code. Enum's sole constructor registers the newly created instance's in a few internal Map cache structures. I mean, when something like this is executed:

public final class MyEnum extends Enum {
   public static final MyEnum A = new MyEnum("A");
   public static final MyEnum B = new MyEnum("B");

   private MyEnum(final String name) {
      super(name);
   }
}

, cache is populated to tell what is the domain for MyEnum (A and B) and to be able to tell you that the instance that represents the String constant "A" in runtime for MyEnum is MyEnum.A

Ok, now that we have a real world example, let's see what worked with Java 1.4 and fails with Tiger and Mustang:

MyEnum m = (MyEnum)Enum.get(MyEnum.class, typedValue);

With Java 1.4, it works; with Java 5, you will get null. The reason is simple: A and B are never instantiated because the class is never initialized.

Now, to the shocking news: there is no way to tell whether a Class instance has been initialized nor a 100% reliable way to force it to initialize. Workarounds such as:

Class c = MyEnum.class;
Class.forName(c.getName(), true, c.getClassLoader());

will require you to handle an exception that should never been thrown in this situation (ClassNotFoundException) and will fail if c.getClassLoader() == null and your code haven't been granted the RuntimePermission("getClassLoader") permission.

Therefore, I've submitted a RFE to add Class.initialize() and Class.isInitialized() to Java SE. I really would like to see this implemented for Java SE 6, but I think it will have to wait for Java 7. This change involves messing with shared native C code and refactoring a lot of stuff on the way, so you are welcome to help me in this task in the JDK Collaboration project.

For now, beware of code that relies on class literal triggering class initialization and hope the ugly workaround above works for you if you cannot avoid it.

First draft for Common Annotations is out

The first early draft for JSR-250, Common Annotations for the Java Platform, has been published. There are less than 10 annotations specified in this version, most of them related to security.

Although many other annotations will probably be added for the next versions, as part of the expert group I would like to request your feedback. Download the early draft and send us your comments. The best time to change a spec is at its early stages. Don't miss this opportunity.

UPDATE: please send your feedback to jsr-250-comments@jcp.org instead of posting a comment to this entry. Thanks!

EJB 3.0 Early Draft Spec is now available for download

The Expert Group for JSR-220 has just published an Early Draft of the new EJB 3.0 spec. It is available for download at the JCP site.

If you want to know more about JSR related news and to participate in their active development whether you are a JCP member or not, check out the recently launched JSR community.

Welcome to the JSR community

Welcome to our newest community, the JSR community. The java.net JSR community has been created to support the goals of JCP version 2.6 to make the process more transparent. File sharing, news groups, mailing lists and other services are among the services offered to help to achieve these objectives.

Each JSR willing to join this community will start a new sub-project here. There, you will be able to subscribe to public mailing lists that will allow you to know and comment about what topics are currently being discussed by the Expert Group, get updated information about the spec status and know when drafts are available. Besides that, if the reference implementation and/or the TCK are open-source software, you will be able to access them here.

Expert Group Members will be able to take advantage of many valuable resources, such as version control and private mailing lists for internal discussion. By using java.net resources, they'll get feedback earlier and the end results will be better.

This community will also provide you news about the JCP, JSRs and related subjects, as well as support discussions about JSRs and the process in general. We hope you can be an active participant of our community and help the whole Java community as a result. Join us and help to shape the future of Java!

PS: many thanks to the whole java.net crew that has made it possible, specially to Sarah Breen, who has been like an angel to all community leaders.

EJB 3.0 - Is it going to solve our problems?

UPDATE: Brazilian Portuguese translation / tradução para o português do Brasil no JavaFree

To begin with, I must congratulate the JSR-220 EG for their braveness. I can't think of any spec in the JCP that has been changed in such a dramatic way as this one. Linda said during the last JavaOne she intended to kill deployment descriptors and to simplify the programming model as much as possible. However, I never thought the EG would take that words so seriously and would drop the current model - ok, "drop" may sound too strong, but, even though they are going to support it, anyone writing code will prefer the new API unless there is some political/business objection for not doing so - for a POJO-based one.

So, now it's time to explain why I think we can simplify EJB 3.0 even more and give tremendous flexibility for the hardcore developer without making any EJB look cluttered or ugly (some people said Linda stated it still will be necessary to use the "old model" for some hard stuff; this sounds extremely unpleasant to me, I must say). The new programming model for EJB 3.0 seems to rely heavily on annotations. This certainly is a good thing compared to the deployment descriptor hell, but there are two things missing that would make turn this idea into something really powerful:

• Annotation processors: what do you do when the security capabilities of your app server are insufficient or inadequate for your needs? Change vendors? But what if the first vendor has a feature you need, but that the second one doesn't offer something similar? That's one of the flaws we're still keeping: vendors will implement the spec in some way that may not be what you need/want. And what can you do about it? Almost nothing, besides throwing your app server away or relying on a non-standard solution - sometimes, it means not using EJBs for a part of your project they'd be the perfect fit if only that feature had been implemented in a better way by your app server vendor. What if you could write implementations for the services an EJB container should offer? You may now say: "hey, but that's exactly what I've paid for", but it's often needed. Vendors are not capable of foreseeing every need you'll have. It'd be even better if we had a standard spi for all the services an EJB container is supposed to provide. In that way, you could swap small components or, even better, write a decorator around a app server specific implementation so that you could only provide the one missing functionality you need - instance-based security for entity beans, for example - and delegating the other features to your app server default implementation. Imagine how many problems you would be able to solve if you could change or augment the functionality provided by an application server in a standard way! I can tell you it would solve around 80% of my issues with EJB. The other 20% would be solved as shown below:
• Support for custom, user-defined annotations: frequently, we need to add services to our components that are not part of the EJB spec. If this feature is not so domain-specific, chances are some vendor has provided support for it. And then, welcome to vendor lock-in! You are left with two choices: go for vendor lock-in or write terrible code just in order to have a portable application. Wouldn't it be nice if you could solve it in a elegant, portable way? Custom annotations and custom annotation processors could be the answer. Imagine if you could write an small session in an deployment descriptor declaring a custom annotation and an implementation of an interface, AnnotationProcessor, that's capable of handling it. You could define your own implementation or simply delegate the processing of your custom annotation to a class provided by your container of choice. You could get portability and still benefit from non-standard features your vendor offers you. Annotations without properly-configured processors would be simply logged at deployment time, since they could be there for a nice reason - for example, you might want to "tag" your methods for some functionality first and implement it after; or maybe that annotations are meant to provide enhancements during runtime and don't represent essential services, like caching, for example.

I am pretty sure some people will say: "Spring (put your favourite lightweight? container here) can do that" or "this is a case for an AOP-based container". I totally agree with the first and I think an AOP-based container would be a good implementation, but the real point is: these are not standards. There is only one Spring - some people might be writing a few implementations for its interfaces, but they are just some people, not major vendors with hundreds or thousands of experienced employees working full-time on that - and AOP frameworks I know are completely different from each other. If we could come to agreement on what basic services an EJB container should provide, a SPI for them and a way to plug custom annotations and to process them, we could get ease of use with maximum flexibility and ability to choose without limiting you to rely on a single vendor for the rest of your life. Vendors would have to provide amazing implementations for each EJB container service and offer a lot of high-quality custom services if they wanted to keep up. A new market of service providers would arise and we'd see a constant increase in the quality of each comercial container out there.

Besides that, there's another idea that annoys me: who said an interface is always a good thing? Even if the container generates it, I am sure I'd be glad to write:

OrderService os = new OrderService();
os.processOrders(orders);

instead of using a container-generated interface for my sesion bean. Plain Java code is great! If I don't need to use some javax.ejb.SessionBeanFactory or to have use a DI container in order to provide interface implementations to my client components, I can hire almost any person who knows basic Java to work with me in my enterprise projects and knowing I won't have to teach them a thing! That is easy of use. Interfaces are needed for a lot of reasons but, as I stated above, they are not always wanted.

Several techniques would be necessary to make these ideas work inside the container - a post-compiling phase, CGLIBed classes, etc. - but that's not my concern at the moment. If I am able to have a similar architecture right now using AspectWerkz - one of the greatest pieces of software I've ever came accross, with incredible support -, why can't enterprise vendors provide something similar?

I am sure that some people would still object saying this would be best addressed by an AOP JSR and a lightweight container JSR, but let's face it: EJB 3.0 started one year ago and it's expected to be finished next year; if we start these other JSRs now, when are we going to see a compliant implementation of them? Besides that, I am not asking for full AOP support; I just want annotation processors and maybe vendors would need to use AOP, CGLIB and/or custom class loaders for achieving my plain Java model. It may not be perfect, but it's better than what we have now in my opinion. What vendors would have to do to support the features doesn't concern me; all I want is a standard solution, with competing implementations, that offers me simplicity, total flexibility and portability.

I do hope someone from the JSR-220 EG reads this blog and post some comments about these ideas.

PS: I really think the JSR-220 EG members are doing great things and think their work must be acknowlegded and praised. They are doing the right thing, although it's hard to do. I just want more :-D. Don't get me wrong: Spring rocks, as well as Pico/NanoContainer. And AspectWerkz will be part of all my future projects unless my client objects, you can be sure. :-D

PS2: This post is inspired by the fact that, several months ago, I posted here some suggestions on how to improve the spec. They were not as drastic as the ideas presented during the last TSSS, but they addressed the most annoying issues I had to face with EJB at that time. Ease of use was, at that time, in my mind, very important for wide adoption, but my post reflected things that even XDoclet and my own frameworks couldn't solve in a decent, clean, non-application-server-dependant way. What amazes me now is that apparently most of those issues aren't going to be addressed by the new spec. Since I wrote that entry, I've been involved in lots of projects and got to know the now popular lightweight frameworks, besides getting my hands dirty with AOP. And I must say that, after playing with these ideas for a while, I got to understand things really must be simpler for the regular work - 95% of it -, but that I still do need a lot of flexibility. And I don't want this flexibility to make my code look harder when I use fancy, obscure, powerful features; I want my business code to always look as simple as the rest of my codebase. The only complexity I want to face is the inherent complexity of my business problem.

This work is licensed under a Creative Commons License.