Michael Nascimento Santos's Blog

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.

Comments

• IMHO SUN / Netbeans gueys decided right. There are too many (extensible) APIs, but at a time with lot of pressure from Flex/Silverlight we are more in the need of good tools to compete.

  Posted by: zero on May 08, 2007 at 02:11 AM

• Michael; These are valid points, and the answer you got from the NB team was kind of a short "no" which really demanded more elaboration. Not representing the NB team, let me try to answer it from my perspective:
  
  We can all agree that this type of binding should have been part of the language and part of all if not most Java IDEs *years* ago. In this area, Sun is definitely playing catch up. While it would be nice to have a "pluggable bindings", what is more important is to have bindings at all. If the binding solution is good enough, I don't see many people wanting to have to hunt and evaluate a binding framework.
  
  This just highlights one problem Java has with UI apps, there are too many different ways to build the interfaces. Swing or SWT. Netbeans RCP or Eclipse RCP. Let's not even talk about the web and AJAX frameworks.
  
  Choice is good, but for desktop apps consistency is king. I often have .net colleagues who are baffled at the multitude of paths that exist in the Java platform to build anything. Again, it's good to have different implementations of something, but we need standards and out of the box functionality.
  
  I think what is needed here is a good review of the current proposal, and if it's inferior to existing solutions, then it should be noted so and fixed. Rather than have a pluggable arch for bindings, let's just make sure the binding JSR is a good solution.
  
  Augusto

  Posted by: augusto on May 08, 2007 at 02:23 AM

• I have worked with Tomas on a few things. He is very easy to get along with. I think he has been covered up here lately with a lot of work to do. He is very open. I would put together a patch which shows what I want to do and show it to Tomas. I'm sure he'll work with you on it, but I bet he doesn't have much time right now. I have a few things I want to work with him on as far as extending Matisse to do certain things, and I'm sure he'll be one of the easiest people to work with.

  Posted by: wadechandler on May 08, 2007 at 07:08 AM

• Hello, have you actually tried to provide the hooks you need in a form of a patch that would be applicable to the current Mattise code? Because that is the way I do it, e.g. with the NB module system. We wanted to have a feature, it was said it will not be supported by NB code directly, so I wrote a patch allowing me to plug in some hooks that I needed. My patches were accepted. Cannot you do the same? Were your patches rejected? Best regards, David Strupl

  Posted by: dstrupl on May 08, 2007 at 07:09 AM

• I agree with dstrupl: why thinking of forking? If you - or another guy - could provide the code with the few changes you mention, I don't see why they should be rejected.

  Another two cents for me: I don't see a "vendor lock-in" as JSR-295 is an open specification, others could provide alternate implementations; and for what concerns JDK 1.4, sorry but I think that we can't ask for new technologies to support it any longer, especially on the desktop (while on the server things are different, many manufacturer still don't provide updated version of their application servers) .

  Posted by: fabriziogiudici on May 08, 2007 at 07:47 AM

• I agree with Fabrizio on the desktop version. To upgrade a desktop application would take changes any ways, so making a requirement for a next release is usually pretty normal in desktop applications.

  Posted by: wadechandler on May 08, 2007 at 08:35 AM

• Well, a generic structure is much harder to maintain and evolve than a focused one. More public interfaces means more backwards compatibility burden.

  I agree that would be useful to have such generic structure (mainly for SWT guys and you with that Thinlet thing), but wouldn't this make it harder to implement new, Swing- and Beans Binding- specific features?

  Posted by: ronaldtm on May 08, 2007 at 06:46 PM

• @fabriziogiudici: JSR 295 is open but it is inherently "broken" in some aspects when compared to other API's s I and others have detailed in many related discussions (including linked in the article).

  @dstrupl: I would love to do such work, but I doubt I will have the time to do something like this... I'm sure many people would use the 295 bindings and many would just avoid this feature altogether, I don't think Sun engineers have actually grasped the degree to which 295 is problematic. They are betting on a standard which is normally a good thing, but in this case its quite obvious that the decision makers haven't taken a proper look at the alternatives.

  Posted by: vprise on May 17, 2007 at 07:43 AM

This work is licensed under a Creative Commons License.