Wednesday September 13, 2006
Wednesday September 13, 2006
Eclipse RCP vs. NetBeans Platform: A Developer's Insights
Kai Tödter is a Principal Engineer in the Siemens Corporate Technology department. He has many years of professional Java experience. His current project is about Smart Clients, with special focus on the Eclipse Rich Client Platform. Kai was delegated by Siemens as "Technical Liaison Manager for Java" to the USA and he has represented Siemens in the Executive Committee for J2ME of the Java Community Process.
I met Kai in Munich, where he is based, at the Siemens conference I went to a few months ago (described here). Recently he ported an MP3 manager/player based on the Eclipse Platform to the NetBeans Platform.
This is his original application, built on the Eclipse Platform:
...and this is the result after porting it to the NetBeans Platform:
In the process of porting his application, he learnt a lot about the NetBeans Platform and, with his extensive Eclipse Platform experience, he shares his perspectives and insights below.
Kai: First of all, here at Siemens we are not religious about our choice of Java rich client platforms. We want to know everything important about all the available technologies. So we want to be able to look at the several different platforms out there and choose the platform that matches our Siemens development requirements. We have different business units and, depending on their needs, they might find one platform more useful than another. Personally, I have a very rich Eclipse RCP background. With that starting point, I started looking at other platforms. For example, I've also looked at the Spring Rich Client Platform, which is at an early stage currently, but looks promising. Next I looked at the NetBeans Platform.
Me: And then what happened...
Kai: Well, the first thing was that I had to install the NetBeans IDE and work with it. Coming from an Eclipse IDE background, using NetBeans IDE was quite painful and still is. :-) But with regards to the platforms, I found Tomohiro Iizuka's article comparing NetBeans to Eclipse (here) very useful.
Me: And how did you progress with the NetBeans Platform?
Kai: Well, overall I had a very positive experience with the NetBeans Platform. When you're at a level where you've mastered the main challenges (for example: lookups, nodes, file systems, branding, update centers), once you've mastered all of that, and you know what you're doing, then it is not too complicated. For me, it was a bit hard to get started, because the tutorials available at that time were pretty basic—I started with the Paint application, then the FeedReader, which both gave me a glimpse of what I needed to know. But when I started with my own application, after just 15 minutes I had issues that were not available in tutorials; issues relating to nodes, selection and so on. But, the more use cases I implemented, the more understanding about the platform’s software architecture I got. However, often I ran into specific details, how to do some specific things. For example: "What is the best way to leverage a specific aspect of the NetBeans Platform rather than re-inventing the wheel."
Me: How did you solve these questions you had?
Kai: There are some very good resources. For one thing, the mailing list (click here) is very good. However, it is too unstructured. Even though I can search for keywords, I often got a very long unstructured list, from 2001 to 2006, totally mixed! So then I had to browse through all these topics. I would have maybe 50 matches, while 2 would turn out to be useful. But, besides that, it is a good resource.
Me: Now that you've ported your application, what would you say is your level of understanding of the NetBeans Platform?
Kai: Right now, I wouldn't consider myself an expert and I know way more about Eclipse RCP. However, I am at the stage where I could definitely start a domain-specific application and be able to focus on domain-specific things, because I am able to use the NetBeans Platform to leverage the boilerplate underlying infrastructural code. The result of such a domain-specific application that I can now build on the NetBeans Platform is decent, looks professional and has good usability. Basically, I could ship such an application within Siemens, and it would be a completely acceptable RCP application.
Me: Excellent. Aside from the difficulties you had getting started with NetBeans IDE, are there things you have come to like about it?
Kai: Well, as I mentioned, the NetBeans IDE is not my favorite IDE, but there are definitely some things that I like. What I like a lot are the wizards in the module development area. There are many very useful wizards that generate code that you can use directly with very little modification. But, my initial issue with every wizard is that I want to understand what is behind it and what it generates, before using it. For example, with the File Type wizard, you get five or six different files, so I first needed to know what's behind those files in terms of the architecture and know what I would get and how to use it efficiently.
Me: What were some painful moments you experienced while porting your application?
Kai: Very painful using the NetBeans IDE was the turn-around time in the application development cycles. In normal development, I make very small changes and then test them. For example, I might change an icon and then want to test it immediately. When using Eclipse, I make one change in the source code, save and everything compiles in the background automatically in no time. Then I just launch the application and almost immediately see the result. With the NetBeans IDE, I make one change in the source code and when I run the application, many Ant scripts are run—and then only about 45 seconds later my application is started up. I do this so many times a day that I would save 30 minutes to an hour in my normal programming with the Eclipse IDE, because there I don't have to wait after every little change to be visible. (Update: See this blog entry to turn your module development turnaround time from 45 seconds to 3 seconds.)
In fact, one of my interns is now trying to build a launcher for NetBeans applications in Eclipse IDE, and is making good progress. In NetBeans, since I like the module development wizards and lots of its good tools, I would like to use the NetBeans IDE wizards for initial setup, and for populating layer.xml files and so on, but when it comes to coding, I would like to continue to use Eclipse IDE, where I can just click run and debug and everything more quickly. Therefore, from my point of view, it would be a big improvement for the NetBeans IDE if the development cycles could be reduced.
Me: Looking at your application, I see nodes, a TopComponent, a TreeTableView... so you must have used quite a few of the NetBeans APIs. Can you share your experiences with them?
Kai: I really like the resource management with nodes and data objects. It is a pretty general thing that can be used in domain-specific applications pretty well. But it is, of course, a little bit hard to get started with all the nodes stuff. When you come from the Eclipse Platform, you know about resources, adapters, content & label providers and so on, and there isn't a concept similar to NetBeans nodes for encapsulation of API objects. But, when I got used to it, I found it quite useful.
I had a hard time understanding the selection mechanisms and how they work together with activated TopComponents (like the ID3 Editor). I had to create a node in my editor just for enabling actions—I created a SaveCookie in the editor, based on the state of my API object. On the other hand, I like the file and loader stuff. It is nice that it is possible to declare external actions from the outside that are bound at runtime to a given file. So now I could define the Play action in an external module and bind it to the MP3 file declaratively. What I also like is that I can use my own MIME types and folder types. It’s a nice feature being able to bind actions to every folder via "any" in the layer.xml file.
With regards to the Nodes API, in the beginning I had a few problems with leaf nodes and Children.Keys, which are different objects, and where to initialize them.
What I like is that I can separate initialization of a model from visualization via, for example, the BeanTreeView. The nodes are lazily loaded and created when expanded, but I could initialize the underlying data model eagerly if I wanted. The Explorer Manager API is nice because of its concept of an explorer manager being loosely coupled from views. These are easy to use once you have mastered the Nodes API. Another nice thing is that table columns are created by properties of nodes. However, I want to use the TreeTableView as a view and not as editor. So, the small buttons for editing are superfluous to my needs and get in the way. I would like to know how to remove them. What I also like, is that the first column gets its own scroll bar, but why aren’t the column widths made persistent by default? Of course, these are minor things, but I'd like to know the answers! But it is really great to have a component such as the TreeTableView in the NetBeans Platform.
Me: Other comments on the NetBeans Platform?
Kai: For me, branding is very important for two scenarios: Firstly, for product line development, secondly, to be able to deploy the same software base for different customers with customer specific branding. What I really like is how easy it is to define a splash screen, progress bar, and a line of text for the splash screen, in the module suite. It is nice that you can preview your splash screen with text and progress bar in the IDE. In this particular case, the NetBeans IDE is even a bit better than the Eclipse IDE! So, one of my interns implemented a plug-in for Eclipse based on the NetBeans splash screen preview functionality! In fact, that was the first time I thought that NetBeans IDE provided a feature that I would really love to see in the Eclipse IDE. Probably I will make our plug-in for splash screen preview open source soon.
However, compared with Eclipse RCP branding, in NetBeans the branding support is too basic. In NetBeans you can brand a splash screen and icon, but what’s missing is the launcher icon (issue 64612). The About dialog box isn't really possible to brand. The splash screen is copied and a bunch of system properties, but it would be great to put other branding information there, such as a smaller image, localized text which is branding specific, for specific customers. For example, for a customer-specific branding, end users would expect to read something specific about the customer in their branded application's About dialog box. Currently, I would have to create a whole new About dialog box, instead of adding some specific information to the existing one. In the Eclipse RCP there is good support for that. In fact, you can brand each feature and plug-in separately, in addition to the application product branding. When you create a domain-specific RCP application that is extensible, and third parties can provide their own plug-ins, the long/short descriptions in NetBeans are probably not enough, I would like visible clues (such as icons per module) to identify what third parties have provided.
Aside from the branding support, what I also like is the ease of integration of the JavaHelp help system. However, there are some issues with details—to provide internationalized help systems, and you have to do some hacks when you want to use application specific start ups for help. And I don't know how to change the title "IDE Help" to something different! But, in general, the binding of the help system to the application is pretty easy. JavaHelp is a little bit out dated, but is still okay.
Eclipse provides also very good help support. It is very easy to integrate the help system of the Eclipse IDE, which uses Tomcat as the web server and Lucene as its indexing engine. The good thing with this approach is that you could provide sophisticated stuff, such as JSP pages for dynamically changed context. JavaHelp is purely static, which is totally okay for most use cases, by the way.
I also like the Update Center mechanism. Of course, using it straight from the NetBeans Platform is not the best usability for many domain specific applications. The users might just want to click a button that says "Update" and then the update is done automatically in the background, without the user being required to work through the Update Center wizard. The related API should be useful to create such an approach. Eclipse RCP uses a similar approach; you could reuse the IDEs Update functionality or use the fine grained Update APIs.
Something else I wondered about is Web Start in the context of Update Centers. If third party libraries are installed via an update center in an application started via Web Start, would a new version of the Web Start application not overwrite the modules installed via the Update Center?
It is even possible to deploy Eclipse RCP based application through Web Start. What I would do then is—I would provide only the most basic application via Web Start and then use the platform update mechanism for the rest. I guess this approach would probably work with NetBeans too.
The last thing I investigated was the issue of long running processes and asynchronous tasks that can be canceled through the user interface. For these I used the Progress API, with its progress handles and progress factories, and it worked fine for my use cases.
What I really like in the NetBeans Platform is its docking system! Being able to move the windows around and dock/undock them... nice. Makes my application look pretty mature!
Me: What are some of the remaining concerns that you have?
Kai: Well, with the NetBeans Platform, when you want to do one specific thing, as a beginner it is often hard to find a best practice example. For example, with lookups you have several approaches. There's the general lookup, which is good for simplicity and easy to use and understand and you could use some declarations in the layer.xml files, too.
Similarly, with the layer.xml files—in every module you can see a tree view for the current layer.xml file as well as the entire context, and I like that. On the other hand, I had problems when I wanted to reuse the Tools menu provided by the NetBeans Platform, but I wanted to delete a few menu entries from that menu. But I had also created a module that used those entries that were deleted. So, there were some inconsistencies about that and, once deleted, it was hard to get the entries back. For example, several modules contribute to the application's File menu. So, I screwed up the File menu and then I had to delete everything in it and then build it again from scratch.
Application life cycle handling could also be better. Module installers are nice but very basic. The Eclipse Rich Client Platform has very good application life cycle management. The NetBeans Platform needs hooks such as PreMainWindowOpen, PostMainWindowOpen, and PostMainWindowClosed. In JSR 296, probably there will be an approach for application lifecycle management that the NetBeans Platform could adopt.
Something else—I'm not able to sign all NBM files belonging to a suite with my own keystore. I found two approaches on the web, but neither worked for me. Even when I use the default keystore, I couldn't start Web Start because some of the JAR files were generated corruptly. I am not sure what causes that, but since it worked with a smaller test application there is probably a detail I just don’t know yet.
Me: Can you comment on your perspective on the factors that could determine whether one chooses to use the Eclipse Platform or the NetBeans Platform?
Kai: Well, it often depends on the "legacy" of the users involved. For example, if there is already an existing monolithic RCP application that you want to port to a platform, to get rid of all the underlying mechanisms that a platform provides out of the box, if the application is built on Swing components it would be a pretty big effort to port them to SWT. In contrast, porting such an application to the NetBeans Platform, would make it easier to reuse UI components. If the requirement is that the application is to be built in Swing, then the NetBeans Platform makes the most sense.
If there is no such requirement about which UI toolkit to use, there might be a requirement that the application should look & feel as native as possible. SWT based Eclipse RCP would then be a very good choice, although the native look of Swing is constantly improving and in Java 6 should be even better in terms of native look and feel. In fact, both Swing and SWT are getting better and better and both are really fantastic UI toolkits. I started with Swing 0.2, and still am a Swing fan but I also like SWT, JFace and Workbench very much. :-)
Software engineers are notoriously bad user interface designers with Swing, with a few exceptions :-), but Matisse should make things a lot easier.
If you have a developer community that uses NetBeans already, then it would probably be much easier for them to use the NetBeans Platform, because they are familiar with the concepts already. In terms of documentation, NetBeans is really catching up too.
In summary, right now there are several players in the Rich Client Platform space and the NetBeans Platform is definitely worth considering.
Me: And so, after your whole experience porting your application, what's your personal perspective on the two platforms?
Kai: Well, I already love Eclipse RCP and I like the NetBeans Platform, too. They both give so much functionality, even though it takes a long time to understand everything fully. However, only a few people need to know everything, but there are a couple of core things that are needed to be understood to work with each of the platforms. In these core things, both platforms provide a lot of functionality, and it is worth it to evaluate the application's requirements first and then choose the platform that fits best. Right now, when I get to coach or assist in making platform choices, I would present both, Eclipse RCP and NetBeans Platform, because, as I said before, there are use cases where the NetBeans Platform would be a truly excellent choice.
Sep 13 2006, 08:25:22 AM PDT Permalink
33 Comments
Trackback URL: http://blogs.sun.com/geertjan/entry/eclipse_platform_vs_netbeans_platform
Comments:
Really great interview, Geertjan! I'd be really interested to browse the source code for both implementations of MP3 manager. I think it would be very educational to see how the different platforms implement identical pieces of funtionality. Any idea if Kai intends to make the source public?
Posted by Rich Unger on September 13, 2006 at 11:25 AM PDT #
I have a feeling he will, but don't want to promise on his behalf. Hopefully he'll answer here or I'll pass the question on to him. It would be cool to do a 1:1 analysis of features and see how each feature is implemented in the different platform, what the pros and cons of the approaches are, etc. But Kai and I have talked about various ideas we have for doing this, i.e., various formats in which we can share the similarities/contrasts. This is not the last we'll hear of Kai.
Posted by Geertjan on September 13, 2006 at 12:37 PM PDT #
By the way, here's an interesting reference to this interview, with other comments by an Eclipse RCP user who is using NetBeans Platform: http://www.nautsch.net/?p=21.
Posted by Geertjan on September 13, 2006 at 11:19 PM PDT #
A point made by Jaroslav Tulach, one of the original NetBeans engineers, in an e-mail to me this morning: "The NetBeans API Support does allow to reload a module under development and then one does not need to wait 45s for its change of icon to appear."
Posted by Geertjan on September 14, 2006 at 01:30 AM PDT #
Actually I plan to release both versions as source. I currently do some polishing on both versions, but the current Eclipse RCP version is allmost ready to be deployed under EPL. I will publish the URL in another comment. Currently the Eclipse RCP version contains more functunality since this is my private playground for Eclipse RCP :)
I plan to release the NetBeans Version under CPPL, but have to do some checks with our legal department first. This will take a while and it also will take a bit longer to polish the code a bit.
Posted by Kai Tödter on September 14, 2006 at 01:37 AM PDT #
I think that the speed of development cycle is crucial for many developers. I spoke with many Eclipse users and they are addicted to the "compile-on-save" feature. I wonder if NetBeans will ever have this feature - I am hoping for 6.0 :)
Posted by Roumen on September 14, 2006 at 01:41 AM PDT #
Oops, CPPL => CDDL :)
Posted by Kai Tödter on September 14, 2006 at 01:41 AM PDT #
Very cool Kai! And, also by the way, Kai's problem with TreeTableViews and the "..." buttons, is answered in this bog entry from a few days ago.
Posted by Geertjan on September 14, 2006 at 01:56 AM PDT #
Oops. I didn't mean "bog entry", but "blog entry". Hmmm. Freudian...
Posted by Geertjan on September 14, 2006 at 01:58 AM PDT #
Two years ago I was looking for a Java client framework. For Netbeans I could neither find good documentation nor samples, whereas for Eclipse RCP there were lots of good articles, mailing lists and some books. I did never regret choosing Eclipse RCP.
Posted by Jürgen on September 14, 2006 at 03:57 AM PDT #
Jürgen, in the area of samples and documentation, NetBeans is continually improving. In fact, we're working on a module development book as we speak!
Posted by Geertjan on September 14, 2006 at 04:01 AM PDT #
I am sitting right next to Kirk Pepperdine, from TheServerSide.com, in Oslo at a session and, in the middle of the session, we wrote this new article on TSS. Check it out! Support the Java rich client platforms!
Posted by Geertjan on September 14, 2006 at 04:02 AM PDT #
As promised, here are the download URLs for the Eclipse RCP based version of my MP3 Manager demo app: Windows Executable (18MB): http://max-server.myftp.org/eclipse/MP3M-3.2.1.20060914.zip,
Sources (833KB): http://max-server.myftp.org/eclipse/MP3M-3.2.1.20060914-src.zip, User: eclipse,
PW: eclipse4ever --- have fun :)
Posted by Kai Tödter on September 14, 2006 at 04:37 AM PDT #
Thanks Kai. And please make the password for the NetBeans Platform based version (whenever it is ready) "netbeans4ever"!
Posted by Geertjan on September 14, 2006 at 04:43 AM PDT #
Sure :)
Posted by Kai Tödter on September 14, 2006 at 04:47 AM PDT #
BTW, he had a lot of valid comments about the time it takes to compile a single class due to the Ant build having to run.
Will that be improved in NB 6.0 with the new java compiler API that allows to compile classes on the fly?
Posted by Jacek on September 14, 2006 at 05:33 AM PDT #
As others, I am too much addicted to the "compile-on-save" feature to leave Eclipse (most IDEs have it: IDEA, Eclipse, CodeGuide...). Give this feature to NetBeans, plus code editor improvements and NetBeans will look much more attractive and productive too (it's sooooo boring to wait for ANT compilation).
Posted by Dominique on September 14, 2006 at 06:04 AM PDT #
NetBeans already support compile-on-save, in a way... Just press Ctrl-S and then F9. Now you've saved and compiled a file... It involves three keys, but so do other shortcuts, it isn't unique in any way. If you want to use two shortcuts instead, remap "Save" to something else (for example, F10 is free, so map "Save" to F10, and then all you need is to press F10 and then F9 and then you've saved and compiled a file). The same approach can be taken for projects too...
Posted by Geertjan on September 14, 2006 at 07:00 AM PDT #
Or, the other way round -- you'd probably want the compile to be before the save, so F9, then Ctrl-S, or F9 F10, if you remap "Save" to F10, as suggested above.
Posted by Geertjan on September 14, 2006 at 07:14 AM PDT #
See also this blog entry.
Posted by Geertjan on September 14, 2006 at 08:30 AM PDT #
I'm a bit late to the party but let me stress that the development cycle really should be shortened. Way too much ant is being executed for every application run / debugging session.
Posted by Javier Molina on September 14, 2006 at 11:13 AM PDT #
Great article. To start we wrote a Swing app and used Netbeans 5 as the RCP. The big attraction was Matisse. Headless builds were a breeze. Some classloader issues but online docs for Netbeans are getting better and better. Then we moved to Eclipse RCP, used Matisse4MyEclipse, kept most everything in Swing via SWT-Swing bridge. Transition wasn't too bad really except Matisse inside Eclipse isn't fully stable. There were some big hassles getting a headless build working since the Eclipse gui build team and the PDE(?) build team differ in approaches but it finally worked for 3.2 only and the instructions were lacking. After doing both RCPs (again, this is basically a Swing app even inside SWT) Netbeans is preferred and, if there is time, we'll move back to Netbeans. Kai is on the mark. If you choose Swing, Netbeans/Matisse leads.
Posted by NetbeansToEclipseAndBackAgain on September 14, 2006 at 02:32 PM PDT #
Hi Javier -- several people have commented on this, I'm hoping to be able to give a response on this in one form or another soon.
Hi NetbeansToEclipseAndBackAgain! Very nice, and very interesting comment, thank you very much!
Posted by Geertjan on September 14, 2006 at 03:42 PM PDT #
We are currently porting a Swing applet to Eclipse RCP and the new product has tremedeous improvement:
- Speed (runs like a native app)
- Perspective concept (only available Elipse RCP)
and many more benefits which you can get from Workbench. I was a Swing developer since 1.0.2 but I would bet Eclipse would be the next generation of RCP platform.
Posted by Raymond Tsang on September 28, 2006 at 05:54 PM PDT #
Yes, but here you're not talking about the Eclipse RCP. You're talking about the IDE. If you're using perspectives and so on, you're using the IDE. What this interview was about was about the underlying core of Eclipse and NetBeans, and about using that core as the basis of an application, and the positives and negatives of using that core.
Posted by Geertjan on September 28, 2006 at 08:57 PM PDT #
We have a solution where we can launch a NetBeans RCP application from within Eclipse and gain the advantages from using hot code replacement/incremental compilation etc. This solution, however, uses a somewhat hacked NetBeans launcher which must be included in the class path, and is not really clean. This is mainly due to a rather inflexible launch mechanism (an inflexibility which is also present in OSGi/Eclipse RCP) which makes a really clean solution hard to achieve.
My problem with the NetBeans RCP vs. Eclipse RCP is that NetBeans RCP has incredibly clumsy code in a lot of places and suffers from generations of cruft piled onto each other in others.
Examples for this are:
- the Wizard API which forces one to separate GUI from panel logic, even if there is no advantage to it. (I'll be more specific, if abybody cares). In understand that Tim started to address this problem by factoring the Wizard API out of the NetBeans code base.
- the launch and module infrastructure which makes it hard to use anything but NetBeans for development (which is something I'll just not going to do)
- the not entirely smart and flexible branding
- the Lookup vs. Cookie vs. ... fiasco
- the node API which is a lot harder to use than necessary
All in all those problems drove us to the decision to migrate several applications we developed on NetBeans RCP and port them to a more modular Swing-based framework we developed in-house. This was and will be a painful process, but better this than suffer from NetBeans RCP indefinitely.
Posted by jh on October 09, 2006 at 05:44 AM PDT #
Lots of things are improving in the NetBeans APIs, don't give up hope, jh. :-)
Posted by Geertjan on October 20, 2006 at 03:46 PM PDT #
have been playing around with the Eclipse platform since 2004 & I found it then to be very difficult to down, update, understand & use. The current version has shown lots of improvement. The same seems to apply to NetBeans - it is early days yet. I have seen a lot of improvement over the last few months. I have deplowed my first real application using the NetBeans IDE and on the Netbeans platform. It took a good while to figure out enabling & disabling actions, lookups, etc.
But I believe I'll stick with NetBeans - I am NOT fond of SWT.
Posted by Errol Dennis on January 19, 2007 at 08:24 AM PST #
Thanks for the support, Errol!
Posted by Geertjan on February 06, 2007 at 02:57 AM PST #
Responding to Raymond Tsang about perspectives, they are most definitely available in the Eclipse RCP. It is not necessary to include the IDE plugins to use perspectives. They are useful for many applications beyond just those related to an IDE.
Posted by cmorriss on April 05, 2007 at 09:00 AM PDT #
Regarding renaming "IDE Help", you could do the following:
- Hidden the original Help Menu, create your own with localizing bundle with link to your master.xml help files
eg:
<folder name="Menu">
<folder name="Help">
<file name="master-help.xml_hidden"/>
<file name="kiyut-citra-modules-userguide-master.xml" url="master.xml">
<attr name="SystemFileSystem.localizingBundle" stringvalue="kiyut.citra.modules.userguide.Bundle"/>
</file>
<attr name="kiyut-citra-modules-userguide-master.xml/Separator1.instance" boolvalue="true"/>
</folder>
</folder>
- In your localizing bundle put the following
Menu/Help/kiyut-citra-modules-userguide-master.xml=Help &Contents
In regards to signing jar problem, you need to put in the project properties or private properties the following
keystore=${suite.dir}/yourkeystore.keystore
nbm_alias=your_alias
storepass=your_storepass
jnlp.signjar.keystore=${keystore}
jnlp.signjar.alias=${nbm_alias}
jnlp.signjar.password=${storepass}
# for nb 6.0
jnlp.signjar.storepass=${storepass}
jnlp.signjar.keypass=${storepass}
It is described on the Harness readme
Posted by Tonny Kohar on August 09, 2007 at 11:18 PM PDT #
Good article and a nice comparison. Thanks Kai.
Posted by Iskender Yigitel on May 08, 2008 at 12:47 AM PDT #
Hi.
I have been working with both platforms, and I need to say that I really like the NetBeans Platform, I found a good presentation with a good comparison of Eclipse RCP and NetBeans Platform
http://java.cz/dwn/1003/7087_nb-vs-eclipse.pdf
Posted by Yamil Bendek on June 04, 2008 at 11:39 AM PDT #
Post a Comment: