Michael Nascimento Santos's Blog

Community: Java Specification Requests Archives

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.

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!

The JCP EC (and the community) did the right thing: JDO 2.0 approved

I have to say I'm really happy. As I woke up today, and visited the results

What is really interesting about it is this vote is not only the result of all efforts made by the JSR 243 EG - which certainly made a difference -, but also is due to the "noise" made by the community. Many people said they had previous investments on JDO, couldn't wait for a spec (JSR 220, EJB 3.0) that wouldn't be available for a long time, wouldn't trust the JCP itself if it rejected a spec that complied to its original request etc., and it seems these claims had a positive effect on the decision after all.

So, what is the point of this entry? Make noise! :-) Express your concerns about JSRs and the evolution of the platform, join the JCP, nominate yourself as an expert to JSRs you are interested in, do something! It does matter.

Rick is right: join the JCP!

In this week newsletter, Rick Ross talks about the importance of joining the JCP. I couldn't agree more with what he says. Here is an extract:

Sun deserves great credit for its efforts to bring meaningful community into the guidance and evolution of a major technology platform. The Java Community Process (JCP) is one of the most innovative and adaptive tools I have ever seen a corporation devise to allow general public participation in the management of a core technology in which it is deeply invested. The JCP isn't perfect and has numerous critics, as any review of Java websites and blogs will quickly prove, but I still feel it has a great deal of merit and potential.

Some people complain a lot about the JCP, but they don't seem to understand that, if there's something they don't like about it, the best way to change it is to join it! Why should them? Well, Rick proceeds:

• Individual JCP membership is FREE
• Individual JCP members are entitled to vote
• Individual JCP members can run for election
• Individual JCP members can view and comment on JSRs
• JCP members are not obligated to attend any meetings

And what does it take? Rick also touches that:

Joining as an individual member is slightly tedious, but it shouldn't take you very long. All you have to do is download, print, sign & fax the Java Specification Participation agreement (JSPA) as well as Exhibit B of the Individual Expert Participation Agreement (IEPA.)

What seems to have motivated Rick to write this post was the fact that only a few hundred votes were cast in the last JCP elections and that we are, according to sun, 3 million Java developers. So, join the JCP for free right now and help to shape the future of Java technology. Thanks for reminding us, Rick.

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.

This work is licensed under a Creative Commons License.