Monthly Archives: March 2005

Eclipse Easter Egg: Heap Monitor

Here is a nice little Easter Egg. OK, not exactly, since you do have to download it by itself. But it is written by the Platform UI Team and if Eclipse weren’t so darn pluggable, it probably would be included. I mean, there’s a flight simulator in Microsoft Excel! But since Eclipse is so pluggable (hmmm I wonder if anyone is working on a flight simulator plug-in), you get to use the built-in Update Manager to get…

…the Eclipse Heap Monitor. (Well, that’s my name for it. The official name is the Heap Status plug-in.)

I’m a former IntelliJ user and this is one of those things that I miss. It gives me a nice indication of how much memory I’ve got to work with. Also, with big projects, you can see if maybe you need to increase your initial and maximum heap sizes. And if you like, you can always press the Trash button to collect the garbage.

Here’s the install instructions as well as the official description from the “(Platform) UI Component Development Resources” page:

The Heap Status plug-in shows the current Java heap usage in the status line (total heap and amount used). A button allows you to force a garbage collect. It includes a preference page (Window > Preferences > Workbench > Memory Indicator) which lets you turn it on and off. This plug-in works on Eclipse 2.1, 3.0, 3.0.1 and 3.1.

The Heap Status plug-in can be obtained via the Platform UI team’s update site.
Use Help > Software Updates > Find and Install > Search for new features to install > New Remote Site, and give the following as the URL.

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/updates

When prompted, choose Yes to restart. If you don’t see the status indicator in the status line, or if the preference page is missing, restart eclipse with the -clean command line option.

Please report any problems to the Platform UI component in bugzilla.

Eclipse Mac tops 200 members!

The Eclipse Mac user group is now over 200 members strong. We started the group back on October 29th, 2004. We’ve added 81 members this month and there are still a few days until April, bringing the total membership up to 204 as of this writing.

If you’re using Eclipse on a Mac, stop on by.

Next stop: Demoing Eclipse at the Tysons Corner Apple Retail Store. (I wish!)

Now if only I had an iPod Shuffle to give away…

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.

Eclipse 3.0.2 due on Wednesday

Eclipse 3.0.2, which contains 70 bug fixes over 3.0.1 will come out next Wednesday, March 23. It was originally scheduled to release today, but is being kept in the lab for a bit longer for a bit more testing.

You can see the Endgame Plan, which has the most up-to-date status as well as a nice timeline.

Also, you can see the list of bugs fixed in Eclipse 3.0.2. This list is for the Platform, the PDE, and the JDT, which make up the base Eclipse download.

BTW, I looked at the equivalent list of bugs fixed in Eclipse 3.0.1 and I found that there were 267 bugs.

If you are still using Eclipse 3.0, I highly recommend getting 3.0.2 on Wednesday, as there will be a total of 337 bugs fixed in that release over 3.0.

PowerPC inside

Mac OS X runs on PowerPC (G4s and G5s).

Linus Torvalds runs Linux on a dual 2Ghz PowerMac G5.

Nintendo Gamecube is based on PowerPC, a customized design named Gekko.

Sony has licensed the Power Architecture. This has resulted in the “Cell” chip that will power the PS3 (PlayStation 3).

And now Microsoft’s XBox 2 is rumored to contain three(!) 3Ghz PowerPC chips [via Dylan]. That’s taking it to a new level, triple-processing. The Sega Saturn had a dual processor chip and developers had a hard time writing games for it, but that was probably a function of bad APIs.

I don’t know if we’ll ever get OS X on an XBox 2, though Linux on XBox 2 seems inevitable.

Hopefully these developments will have an effect of create a more competitive chip market, increase the production volume of PowerPC, lower prices all-around, and produce more rapid innovation in the PowerPC line. Specifically, I’d like to see PowerPC chips (and thus PowerMac G5s) ramp up to 5Ghz. Also, this might help in getting to the dearly desired PowerBook G5.

[Free bonus: Here's a nice little history of PowerPC and Apple from Ars Technica.]

[Another free bonus: Another bit of history, this time about the AIM (Apple, IBM, and Motorola) Alliance that created the PowerPC, which also spawned things like Taligent.]

The Eclipse revolution will be persisted (in a SQL database)

Eclipse seems like this big snowball rolling down the software industry hill, picking up code, contributors, and users as it rolls along. It has gotten much bigger in the past year and a good chunk of that snowball is SQL-flavored.

There’s three Eclipse projects for database tools: BIRT, Data Tools, and RDB (part of WTP). Also there is a growing partnership with Apache Derby.

I got to see BIRT at the big Actuate booth at the EclipseCon vendor hall. BIRT stands for Business Intelligence and Reporting Tools. It is a top-level Eclipse project and is backed by the fact that Actuate is a Strategic Developer, which means that they have to devote a big chunk of change and commit at least 8 developers to the project. BIRT doesn’t have database tools per se, but they do have a data source framework which now supports JDBC as well as other types of data sources.

Data Tools is another top-level project which is in the proposal phase, backed by Sybase, which is now also a Strategic Developer. This is an ambitious project covering the entire gamut of database tooling: connectivity to databases, exploring databases, SQL editing and debugging, database administration, Object/Relational Mapping(!), XML/Relational Mapping, and Extract-Transform-Load. There’s no code to see yet unfortunately, but this will be a big component of future Eclipse/RCP apps technology stacks. Hopefully we will see good progress by EclipseCon 2006.

RDB (which stands for Relational DataBase) is a sub-sub-project under the WST (Web Standard Tools) sub-project of the top-level Eclipse project WTP (Web Tools Platform.) There was a nice overview of RDB given by Der Ping Chou (who is a co-lead) in the WTP Sprint on the first night of EclipseCon 2005. I won’t go over it here, because there is a good RDB Tutorial available online that illustrates the features of RDB: a database connection wizard, a database server explorer, a table content browser, and an SQL scrapbook that lets you execute arbitrary SQL. Note that a SQL Editor is in the works that will allow multiple commands and will have content assist.

I got to try out RDB during the WTP tutorial and it worked quite well with Derby. I was impressed by the table contents browser as well as the database explorer. There’s support for several databases built-in and any database vendor can add their own support. I think WTP is open to providing as many database providers as possible (as long as they also commit to maintaining that support.) Der Ping noted that many of the things that RDB does can be reused in an RCP context. For example, you could use the Connection Wizard to configure a JDBC database for use in an RCP app.

As far as specific databases go, the open source Apache Derby database is represented well and seems to be a growing partner for Eclipse. I expect MySQL to also make its presence known. It is interesting to note that 3 of the 4 big database vendors are Eclipse Foundation members: IBM, Oracle, and Sybase. Note that IBM has a few databases: DB2, Informix, and Cloudscape. Oracle has been quiet recently, but they will probably at least ensure that their database has provider support. There is already SQL Server support in RDB.

So where is all this heading? Well from my perspective, RDB has the most code and the most usefulness currently. It is likely to be widely used as WTP starts getting adopted after it releases its 1.0 in July. BIRT has some useful code as well.

During the Q & A portion of the WTP Sprint, Arthur Ryman, who is a co-lead of the WTP project reminded us that Eclipse specifically and open source in general is about collaboration, not competition. So, after WTP 1.0, there will likely be some sort of merging of the Data Tools and RDB projects, which will probably draw in the relevant BIRT pieces.

Want to see more programming languages supported in Eclipse?

One of the interesting things I noticed at EclipseCon 2005 was that developers want to see more programming languages supported in Eclipse. Currently, the JDT which lets users develop Java code, is bundled with the base Eclipse. This is the plug-in which all other plug-ins are measured by and it has been one of the main drivers of Eclipse. Also, there is the relatively mature CDT (“Better than JDT or go home”) which lets you develop in C/C++ on a variety of platforms (and you can have a different target platform than the one you are writing on.) There’s a variety of other plug-ins that are in different states for such varied languages as Python, Ruby, Perl, COBOL, and C#, just to name a few.

There were two BOFs at EclipseCon that addressed this: Language Toolkits and Dynamic Languages that got good attendance. There were also a few sessions. BEA is spearheading an effort to create a new subproject in the Technology Project named the Language Development Toolkit (LDT) project based on its Javelin compiler framework. That framework was used to support Java-related languages like JSP.

Chris Laffra of the Eclipse FAQ has posted two good write-ups of the BOFs to the newsgroup for the LDT. Check them out.

If you’re interested in more language support in Eclipse, I would suggest posting to the news://news.eclipse.org/eclipse.technology.ldt. You can also read the Language Development Toolkit proposal. The project is in a very early stage and they are looking for feedback and input from the community.

Eclipse Easter Egg: Plugin Dependencies View

One of the great things about EclipseCon is that you get to talk one on one with the Eclipse Committers. Most of the time, you do not have access to the talented developers that write the software that you use everyday. They’re usually kept far away from the action. But Engineer to Engineer interaction is part of the game when it comes to Open Source and with EclipseCon being fundamentally an Open Source Conference, you have a lot of opportunities for interaction.

Also, I like to think of interesting and useful apps. I thought… wouldn’t it be cool if there was a way to graphically view all your plug-ins along with their dependencies? Of course, the way to do this would be with GEF.

So I chatted up the GEF Committers, Randy and Pratik, after they gave their session on GEF, asking them if anyone had done such a thing. Well it turns out they themselves already have done it and I’ve had access to it all along, but just never saw it: the Plugin Dependencies View. I think that qualifies it as an Easter Egg.

plugin_dependencies_view_1.jpg

It comes with the GEF Flow Example. So you need to download Eclipse, the GEF SDK or Runtime, and the GEF Examples. Note that some releases have a GEF-All, which contains both the SDK + Examples. Unzip the GEF features and plugins into your Eclipse (or use link files, which I prefer) and then go to Show View > Other…, then pick Basic > Plugin Dependencies (GEF Example).

This will bring up a view named Plugin Dependencies (GEF Example). It is a Draw2D representation of all your plug-ins and their dependencies. It is scrollable, but that’s about it. Randy and Pratik said that they are open to feedback on it.

So here’s my feedback. :) It would be nice if the example used GEF and not just Draw2D, which would enable the user to interact with the nodes more. Specifically, it would be nice to drag the plug-in nodes around manually to more clearly see the connections, if you could double-click on it to open up the associated manifest editor, and if you could highlight all the dependencies of a plug-in, as well as highlight all the dependents.