Category Archives: RCP

RCP from my readers

I got two comments from my readers recently on RCP:

1. Henry wrote “Why Eclipse RCP is going to rule the world“, giving 5 reasons. I agree with his arguments that Eclipse RCP is the ideal platform for building desktop clients, especially if they need to be cross-platform. There is a lot of momentum behind it and you would be hard pressed to duplicate what it provides you on your own.

2. Kent commented that

“RCP saved me an incredible amount of time. I certainly cannot thank the Eclipse project enough. Without it I would have taken a lot longer to create the BigBlogZoo and it would not look as nice.”

Again, using RCP saves you time because it is just plain hard and time consuming to build a desktop application framework. Bonus points that it makes your desktop app look like every other app on your system, that is like a native app.

The state of Java on Mac OS X

James Duncan Davidson wrote about the state of Java on Mac OS X and I saw a comment that was dead-on:

I agree Apple is focused more on server-side Java on the Mac, but keep in mind that there is at least one really important Java desktop app that server-side developers care about: Eclipse. If Eclipse doesn’t run well on the Mac, all of those server-side Java developers go elsewhere…
-Andrew Shebanow

I don’t know if all those server-side Java developers actually would switch back to Linux or a Windows machine, but I think the point is that Eclipse needs to run well on Mac, period. BTW, there is an Eclipse on Mac users group.

Later, James added:

Important tasks like building GUI applications. There are a few decent Java based GUI apps out there. However, I find it telling that the best GUI applications out there written in Java are IDEs in which to develop Java code. I’ve seen a handful more, usually at the pace of one a year, that work well and provide a great user experience. But in general, the evidence says that Java, or at least Swing, isn’t the greatest language or library for building GUI applications with. SWT may be, but that still remains to be seen.

I’ll add some more observations:

1. Eclipse RCP Apps (which are built with SWT) will probably change things. On OS X, they are built on the Carbon framework currently and they look and feel native. More importantly, RCP makes building a full featured app easier. With Swing, you have had to build an app framework yourself. That is not a trivial task. I know since I have played a part in building and maintaining one.

That’s one of the reasons why the IDEs are the main Java apps right now, since they have enough people to build these application frameworks with enough left over to build the actual Java tooling bits. Fortunately for the rest of us, the Eclipse team is now sharing that wealth with us to build desktop apps (they call them rich clients).

2. Enterprise desktop apps that need to run multi-platform (Windows, Linux, OS X, etc) are usually written in Java. However, you don’t see many of these apps because they’re not marketed towards consumers.

3. Apple does have good support for Java, they had a strong presence at EclipseCon, and they are currently looking for an engineer (who knows SWT among other things) to improve the Java support even further.

I think Apple will probably continue to ensure a good Java experience on OS X, but continue to expose the OS X specific APIs mostly just to Cocoa and Carbon. That is ok, since they are (mostly) targeting different markets: Java / RCP -> Enterprise Cross-Platform Desktop and Objective-C / Cocoa -> Consumer OS X Desktop.

Yay – Kim’s got a blog!

Kim Horne, who gave a nice presentation on “Addressing UI Scalability in Eclipse” at EclipseCon 2005, has just started an Eclipse-focused blog, titled Kim’s Eclipse Musings. I enjoyed the session quite a bit due to her sense of humor. She demoed how you can, using one perspective and the Activities API, create two versions of a rich client app on RCP, effectively implementing role-based access. The first role was the “peon” who was told to work harder and the next role was the manager, kinda like a Dilbert RCP app. BTW she stressed that doing so does not constitute real security, but it is a useful API nonetheless and an interesting demo. And no, nobody threw food at her for suggesting it. :)

Check out the session slides in PDF, which explains the API (actually 2 APIs: Activities and Contexts) and gives good examples. An interesting thing to note is that it enables progressive disclosure, which is a fancy UX (User Experience) word which means that you hide parts of the UI until the user needs them. So, for example, you can hide an entire tool (say the JDT) until the user asks to create a Java class.

Anyway, back to Kim. She’s the first Eclipse Committer that I know of that has a blog. She is on the Platform team, I think focusing on the UI. Right now, she’s blogging about Content Type Based Editor Lookup, which in plain English means how to decide which editor to open up based on what’s in a file, instead of just look at its extension, which is what the current framework gives you. I didn’t know anyone was working on this until now, so its good to hear that she is. I’ll probably use this API when it becomes available.

To top it all off, Kim is also a fellow Eclipse on Mac user. Yes! She seems to have switched just this month, with a trifecta of PowerBook, Mac Mini, and iPod Shuffle. Maybe Apple will feature her in a future Switcher Ad? :)

Speaking of Mini, I got a phone survey asking about my Mac Mini experience and it was the most enjoyable survey I’ve ever given. Hopefully my input will help Apple decide to increase the base memory in a Mini to 512MB, which I think would be better for most users. My kids are OK with 256MB, but I’m sure there will come a day when I break out a putty knife and stuff in a 1GB stick.

RCP plenary

Nick Edgar and Jeff McAffer are presenting. They’re relating RCP releaeses to popular TV shows.

Eclipse 2.1 RCP – Monster Garage – this was hacks by pioneers who stripped down the Eclipse SDK to create a platform for building non-IDE apps.

Nick: This is similar to how Monster Garage gutted a PT Cruiser and stuffed a wood chipper inside.

I saw someone who did this at least year’s EclipseCon and it looked pretty good. However, they had to do a lot of things to get it work and they had to create custom builds of Eclipse to get to what they wanted.

Eclipse 3.0 RCP – What Not To Wear – my wife loves this show and apparently Nick’s does as well. They took the SDK hacks and remade it so that you can get RCP out of the box.

Eclipse 3.1 RCP – The Amazing Race – Not quite sure what to make of that reference, but 3.1 is where I believe that RCP will come of age.

RCP is middleware. I’d say it is more like an App Container, like there is a Servlet Container or an EJB Container. But the same principle applies: it lets you write the stuff that matters, not the plumbing.

RCP apps look native. Yes. The user doesn’t really want to be confronted that your app is built on Java. They want it to behave like the other apps that they use.

RCP helps academics do things that aren’t IDE related, like control instruments.

IBM uses RCP for its Workplace Client, which is reminiscent of Outlook.

NASA uses RCP for its Maestro – Space Mission Management app.

There’s Eclipse Trader, which lets you track stocks.

There’s also eRCP for embedded devices.

OK… there’s a good start. I’m hoping to see a lot more. Only problem… how can you tell? I guess you’d have to dig into the directory structure and see if you can find a plugins directory. If you were just looking at the UI, it would be harder to tell.

“Aggressive laziness” – this is a great phrase. Basically extreme lazy loading. Don’t load code until you really really need it. This helps Eclipse perform well even with lots and lots of plug-ins.

What people like about RCP: You can focus on the 20% of the app that is domain-specific rather than the 80% that is common infrastructure.

What people don’t like about RCP: Learning curve of the APIs. I’d say instead that learning the APIs is an investment. For example, you could argue that going to a university is hard. That’s true. But it is an investment in knowledge that you can reuse over and over again in your life. The same goes with RCP and other Eclipse APIs.

Also there are some challenges with security support, but hopefully some folks will step forward and help with this.

Also there are some problems with apps that expect class loading to work in a certain way. The Eclipse team is working to address this in 3.1. Great.

Base RCP = OSGi + Runtime + SWT + JFace + Workbench. This is about 5-6MB currently and they are looking into slimming this down even more.

Optional RCP = Help, Update Manager, Text, forms, Welcome Page / Intro, Cheat Sheets, GEF, EMF. And you can use any other plug-in really. I blogged earlier how you could grab the database connection wizard from WTP and use it in an RCP app.

3.1 adds a lot of tool support for RCP, which I think is a big enabler for the RCP community. There’s product tooling available now, along with RCP templates. Bundle tooling will come later in M6.

“The friendly blue screen” LOL That’s what the Eclipse team is calling the Eclipse welcome screen.

RCP Application vs RCP Product – Application is like any standalone Java app. Product has a product ID, a product Name, a launcher name (executable), a root directory, a spalsh screen, icons, a custom About dialog. Currently you need to update the build.properties file to tell it where the icons are. You can then export the product, which builds all the plug-ins and outputs it to a zip, which you can then unzip and run via the launcherName.exe (on Windows.) I’ll have to report back later to see if RCP Product creates a proper .app on Mac OS X.

You can deploy your features and thus your RCP via Java WebStart. The only thing is you have to handcraft a top-level JNLP file, which hopefully will be done by 3.1. The underlying JNLP files are created for you. This is done via Export Deployable Features. This is pretty cool. They did this with the entire Eclipse SDK(!)

There is system tray integration. Not sure if this is SWT, JFace, or RCP. I wonder if there’s OS X menu item integration…

I have to give a hand to the RCP guys. Their demos were very smooth. One of the demos was to show a chat client talking to an RCP-based chat client called “Hyerbola”. They showed off the system tray, update manager, dynamic menu adding, and integration with Swing (which was for an XMPP debugger).

Future: RCP started as a grass-roots effort and the team wants to continue to engage the community. RCP Tooling will continue to increase (great), making it easier to create and maintain RCP apps. There will be some more flexible layouts (for perspectives I think).

RCP call to action: Participate in the community. Think about building a platform around your industry. Post your application to the eclipse.org / community / rcp page, which I guess is like an RCP Sightings page.

“Eclipse is not just for tools anymore!”

The night owl gets the milestone build (Eclipse 3.1M5 is here!)

Eclipse 3.1M5 is here!

I like this quote from Kim Moir, the Master of Eclipse Build Ceremonies (OK, not an official title):

“The clock has struck midnight and M5 has emerged as a beautiful new stable build.  Enjoy.”

You can download 3.1M5 here. The mirrors probably do not have it yet, so I would go ahead and go to the main Eclipse download site in Canada.

Read about the New Stuff in Eclipse 3.1 M5 here.

Before I drop off to sleep, here’s some highlights that I hope to try out this weekend:

1. Starting up SWT apps will be easy, via a Run As > SWT Application menu item. That’s great! The only downside will be the decreased demand for my #1 blog entry. But that’s one small step back for Luis, one big leap forward for Eclipse-kind.

2. New Undo/Redo API. This is also great, since this is a tricky thing for Tool Developers, but also one that needs to be right for there to be a good user experience. Looks like this is still in its early stages.

3. TableTree has been deprecated and replaced by a Tree with multiple columns. Since I also do Swing, it was always weird to see TableTree instead of JTreeTable.

4. You can finally reorder Table columns by dragging. Another thing that I missed from Swing.

5. More RCP support in terms of startup, wizard templates, and branding. 3.1 is looking to be great for RCP Apps. I only hope that it is accompanied by a greater web presence and maybe even a marketing campaign. Perhaps a prominent link in the navigation bar, promotion to a top-level project, or maybe a place on the top of the home page would be good. Everyone knows that Eclipse does plug-ins, but RCP is not as well known yet.

6. iTunes-like searching of Properties as well as Preferences.

7. Import/Export of Preferences. This is good for developing in teams when you want to have shared preferences and something I’ve been wishing for a while.

8. New Help view. This hopefully will improve the user experience with help, especially with searching. I especially like the Eclipse.org search. I’ve been meaning to post a blog entry about how Eclipse.org isn’t fully in the Google Universe and how you can get around it, but perhaps now I won’t have to.

9. Install/Update Wizard Redesigned. Hopefully the user experience will improve here too. So far, it has been nicer to install via zip files rather than this wizard and hopefully that will be reversed soon.

10. More Java 5 support.

11. Better Source folder configuration.

Wow, it looks like there’s been some good work on the user experience. Hopefully this will make the EclipseCon demo even better, but I’m even more excited about the eventual 3.1 release after seeing these improvements. Note to Erich or whomever is presenting: Please make sure the power connections are good. ;)

Technorati tags: eclipse

A Desktop Java Renaissance

I finally got used to the new look of JavaLobby and am glad that the gliding nav toolbar stopped gliding. That’s one of those features that seems glitzy but just ends up distracting the user. Anyways, I responded to two posts and found myself thinking… there is going to be a Desktop Java Renaissance.

Why so? Hasn’t Microsoft frozen the JDK out of Windows? Sun has a workaround for that, with Java WebStart, the consumer-oriented Java.com, and the Java Auto Update system tray icon. Also, Java is installed by default on Mac OS X, SUSE Linux and Java Desktop System.

Doesn’t Swing emulate everything and make your apps seem slightly out of place? Sun has improved the L&Fs of Swing in 1.4.2 and 1.5, but if those aren’t native enough, you can use the Eclipse Foundation’s SWT / JFace.

Are there any Desktop Application Frameworks, so I don’t have to roll my own every time? Eclipse refactored the Rich Client Platform (RCP) out of itself, due to popular demand. Trivia: The RCP Birds of a Feather (BOF) session at EclipseCon 2004 was the most popular, leading people like myself to write my name sideways in the margin to jam myself in there. Thanks again to Ed Burnette for spearheading the RCP effort.
If you’d rather use Swing (since RCP requires you use SWT / JFace), then you have Spring Rich or NetBeans to choose from as a framework. I’m interested in trying out Spring Rich and will share my experiences with you.

Are there any components available, ala Visual Basic or Delphi, to speed my development? In VB or Delphi, there’s a large assortment of components that you can buy instead of build, which shortens your dev cycle. This has been lacking in the past. However, now there is a multitude of Eclipse plug-ins, most of which can be used in the RCP, with more being developed every day it seems. If that’s not enough, you can even embed native components (like ActiveX on Windows or WebKit on Mac OS X) through either SWT or JDIC (which integrates well with AWT / Swing.)

What about Enterprise Java? Don’t worry, that’s still alive and well and thriving. Not only will J2EE focus on ease of development, but there are alternative frameworks like Spring.

The reason all of this is occuring is due to plain and simple market competition. Eclipse raised the bar when it came to look and feel and plug-in infrastructure, RCP on the framework side, and Spring on the enterprise side. Eclipse plug-ins started to multiply as the platform became more viable. While this can cause some divisions for those deeply invested in one specific technology, I think this is good for the Java community as a whole, because the choices this competition creates lets us developers decide our own fates. (And if our choice is open source, we can even contribute to the production and not just be a consumer.) All the pieces seem to be falling in place for a renaissance for Java on the desktop. Things should get even better, once Eclipse 3.1, with its extensive support for developing RCP apps, is released, its alternative Spring Rich matures, and as the plug-in market continues to grow.

Interesting developments to watch: There seems to be an effort to make RCP easier to install via either: 1. RCP support for Java WebStart or 2. natively compiling Eclipse / RCP apps.

Native Browsers in Java on Windows (and Linux)

Last night I looked at embedded native browser components in Java, focusing on Mac OS X. Tonight we’ll look at what’s available on Windows. There are at least 4 contenders, perhaps more. In addition, there are 3 browser choices: Internet Explorer 5.x/6.x, Mozilla 1.4, and Mozilla 1.7.

First off, there is the Browser component that I talked about last night. Due to the elegance of the Eclipse plug-in loader (actually it is OSGi in 3.x), the name of the component is also called Browser. However, it is in the org.eclipse.swt.win32 plug-in instead of the org.eclipse.swt.carbon plug-in. This is the nicest of the bunch, with the caveat that it only embeds IE 5 or IE 6. Using the SWT Examples that you can download from the main Eclipse download page (look for Example Plug-ins), it worked pretty much like IE. You could even drag URLs to it and it would load them up and update the location bar. On my Windows XP laptop, I’ve got IE 6 installed and using the BrowserSpy information, I confirmed that it was indeed IE 6. Ryan Lowe pointed out that if you have IE 5.x on your Windows, then this component would embed IE 5.x. This came out with Eclipse 3.0.
Eclipse plug-in / RCP developers: I would use this implementation.

Second, we’ve got OLE/ActiveX integration on SWT Windows. I tried this via the SWT Examples again and was unimpressed, but probably because there was more work done in the SWT Browser widget. BrowserSpy couldn’t detect what it was, the location bar didn’t update, though it did otherwise work like IE. This has been around since at least Eclipse 2.x.

Third, there is the JDIC Browser component. This is an AWT component that can nest IE quite easily. There’s a demo available via JNLP. This can also embed Mozilla 1.4 (the whole thing, not Firefox), but you have to jump through some hoops to get there, including setting an environment variable and copying an .exe file. This performed well and the APIs are designed to work cross-platform. The SWT Browser API edges it out for completeness, though. BrowserSpy confirmed IE. This is licensed via LGPL. This project is looking for some help, especially with supporting Mozilla 1.5 and up. BTW, Mozilla 1.4 is around the timeframe of Firefox 0.7 – 0.8. This project started up around the JavaOne 2004 timeframe.
Swing developers: I would use this implementation.

Finally, there is the Webclient. This is another AWT-based implementation that predates the JDIC. This supports Mozilla 1.7 (the whole thing again, not Firefox) only. There is no IE support, but that only makes sense, since this is a collaboration between the Mozilla Foundation and Sun and is hosted at mozilla.org. BrowserSpy confirms that it is Mozilla 1.7. The installation for this was the most heavyweight, due to the reliance of Mozilla 1.7. Nonetheless, this performed decently. This project was started back in 1999 and is licensed with the Mozilla Public License. I suspect that this will either merge with JDIC or be overtaken by JDIC.

One more… JRex supports Mozilla 1.4+ and integrates with AWT/Swing. Haven’t tried this yet, but again, I think JDIC is the project to beat in the AWT/Swing universe.

Linux readers: The only problem is that the list would be almost the same as the one for Windows, except that IE gets the boot, with Mozilla being the only choice for embedding. Also, no OLE/ActiveX. SWT GTK2 3.0 supports Mozilla 1.4 – 1.6 and the 3.1 stream adds support for 1.7.

Update [11/3/2004 10:33PM] – I clarified which browser will be embedded using the SWT Browser widget on Windows. It will be whatever version of IE that is currently installed on your system.