Every now and then, somebody asks a question about whether or not the Eclipse IDE supports Java 5. If you look at the 3.1.2 release notes, you’ll see that version 3.1.2 has been tested on Java 1.4.2 on variety of platforms (Linux, Windows, Mac OS, AIX, Solaris, HP-UX) as well as Java 5 on Windows XP. Based on this information, one might conclude that Eclipse 3.1.2 only supports Java 1.4.2.

When the release notes talk about the tested platforms, they are referring to the platforms upon which the Eclipse IDE itself runs. That is, the Eclipse IDE is itself a Java program that runs on a Java virtual machine (JVM). The Eclipse IDE, version 3.1.2, including the views, editors, compilers, and what-not are all tested and validated on the Java 1.4.2 JVM (and Java 5 on Windows XP). While the 3.1.2 plan doesn’t specifically discuss running on Java 5, many people are doing just that. In fact, if you take a look on news.eclipse.org/eclipse.platform, you’ll find several messages from folks who have been successfully running an Eclipse 3.1 version (including pre-release versions) on Java 5. It works (I’ve been running 3.1.1 on Java 5 on both Windows and Linux for months). So… while it’s not officially tested in the lab, it is certainly tested in the field.

That aside, the Eclipse SDK 3.1.2 does support the construction of applications using Java 5. You can build, edit, compile, debug, and test Java 5 projects with all the bells and whistles you’ve come to expect from Eclipse (you can, for example use code completion to fill in the type for a generic).

Out of the box, Eclipse 3.1.2 is configured for creating Java 1.4 applications. You can turn on Java 5 support using the preferences window as shown below.

If you set the “Compiler compliance level” to 5.0, it’ll let you use all the wonderful new syntax introduced with Java 5. If you’re not running Eclipse itself on a Java 5 JVM, you’ll have to add one to the “Installed JREs” in order to gain access to the Java 5 libraries and source code (look here for help). You can also specify what version of Java you want to work on a project-by-project basis. You can have some projects in your workspace that use Java 1.4 and some that use Java 5 (and some that use other Java versions).

Eclipse 3.2 is tested against Java 5 on all platforms; it says so right in the plan. Version 3.2 doesn’t officially ship until June (as part of the “Callisto” release train), but you can get it today so long as you don’t mind running into an occasional bug (as should be expected when using a pre-release build). If you do run into a bug, be sure to report it so that development teams can address the issue. I’ve been working with Eclipse 3.2M3 for a few months now and it’s been great.

So… does Eclipse support Java 5? It sure does. In summary:

• Eclipse 3.1.x is tested and validated on Java 1.4.2
• Though not officially tested and validated, Eclipse 3.1.x is run on Java 5 by many people who use it every day for development
• Eclipse 3.2 is tested and validated on Java 5
• Both Eclipse 3.1.x and 3.2 can be used to build, compile, debug, and test Java 5 applications

With Bug# 125649, Chris has suggested that somebody out there should setup an “Eclipse Store” selling Eclipse-branded merchandise. I think he’s suggesting that the Eclipse Foundation should probably do something along these lines; I thought that there might be something in the rules that would prevent us from setting up a store, but I can’t find anything and neither can Mike. So it’s in the realm of possibility. I’m not sure that I want to figure out how to process credit card orders, but if there’s enough interest, maybe we’ll go for it.

Other open source organizations have online stores for buying logoware. Take a look at some of what’s available for Apache enthusiasts. But, I warn you: don’t look here. Trust me. It may look comfy and right, but it’s wrong. Very, very wrong. Very wrong (btw: this will explain the horrified look on my face during my next meeting with Apache folks).

As Mike suggested in his blog last week, Eclipse logos are made available under the EPL so an enterprising individual or organization can get a jump on us by setting up their own Eclipse logoware business.

In the meantime, if you’d like to be able to buy your own Eclipse logoware, add your thoughts to the bug.

I hope that everybody out there is planning to attend Waterfall2006!

I’m gearing up fo the Eclipse in Motion seminar series. I’m running the afternoon technical session with assistance from some very experienced Eclipse developers. The format of the technical session will be very loose. I’m not planning to deliver very much slideware, but rather will be soliciting input from the audience to determine what we’re going to cover. I’m bringing some slides to cover as many contingencies as possible, and we’ll use ‘em as we need ‘em.

I’m really looking forward to this, because the format will be far more relaxed that what I normally get to deliver at a conference: we’re hoping to break into small groups, roll up our sleeves, and actually get some real work done. We’re keeping the attendance numbers small so you can get some real value out of the session.

I’m being joined in San Diego (February 7th) by Wassim Melhem from IBM and Cliff Collins from Sybase. In Dallas (Febrary 9th), Chris Aniszczyk and Douglas Pollock from IBM along with Rob Cernich from Sybase will be on hand. Chris will also be joining me in Raleigh (February 28th) along with IBM colleagues Pat McCarthy and David Williams and John Graham and Karl Reti from Sybase. John and Karl will continue onto Altlanta (March 2) and be joined by John Arthorne (who you may know as one of the authors of Eclipse 3.0 FAQs). For the February 9th and 28th sessions, Chris (who is currently working on a eRCP Redbook) will be showing off some cool devices running Eclipse applications.

If you want to meet some of the big brains developing on Eclipse, you should attend one or more of these sessions. Be warned that this session is not intended for folks who are new to Eclipse. We’re expecting that you have experience building Eclipse-based applications and either need some help from the experts or want discuss your issues with like-minded individuals. Bring your laptop and your issues. We’ll work through them.

For more information and to sign up, click here. Be advised: the registration website is a little weird; by default it organizes the sessions by location rather than date.

I recently got this question from a developer building Eclipse plug-ins:

What should I do about classes with discouraged access? For example IAntUIConstants is “internal”.

To start with, if you haven’t encountered this yourself already, here’s what it looks like in the Java editor when a class in your plug-in attempts to make use of the IAntUIConstants type:

Access to this class is discouraged and shows up as a warning in the editor (and in the “Problems” view). This warning does little to stop you, other than give you a creepy feeling that you’re doing something wrong. You can discourage the use of certain classes in your own plug-ins using the same mechanism, allowing you to share that creepy feeling among your friends and colleagues.

The answer to this question is simple: when you get a discouraged access warning, stop using the type that’s causing it. However, that may be a little too simplistic. What if you really, really, really need the functionality? In this case, the answer is still “don’t do it”. But what if you really, really, really, really need to use the class? In that case, you can use it, but you need to be aware of what it means (four really’s usually does it for me).

Discouraged access is provided for your protection (it’s for the plug-in provider’s protection as well since it gives them the ability to say “well… we warned you”). The idea is that you are discouraged from accessing things that are not part of the public API. The things that you are discouraged from accessing may change in future versions of Eclipse and break your code.

You will notice a couple of things about discouraged access code in Eclipse. First, you’ll very likely see the word “internal” somewhere in the package name (the Eclipse Platform Naming Conventions talks about this). The other thing you’ll notice is that the documentation is a lot less evolved in these types than in those that are part of the API.

If you really do need access to types that you are discouraged from accessing, you may be able to make a case for adding them to the public API through Bugzilla. Be prepared to make a pretty strong case as most teams take adding public APIs very seriously (they are a huge liability to them; once something is declared API, it must be supported and is hard to change).

Bobbie Wang and Cliff Liang have translated the Eclipse User Interface Guidelines article into Chinese. I obviously don’t have my browser configured properly, because it appears as a bunch of characters that look very little like Chinese (lots and lots of umlats) with a occassional word that I can actually read. I’ve been told (and have to take on faith) that it appears quite well in properly-configured browsers. Let me know if your experience is contrary. I find having translations like this particularly cool, and really wish that I could say more about it, but since I can’t read Chinese (not for lack of trying; perhaps I should actually learn Chinese first), there’s not much else to say about the translation…

You can find the translation on the Eclipse Corner Articles landing page. If you scroll about halfway down the page, you’ll see a little Chinese flag with some comments next to it. I’m curious to know if you think this is a good way to represent translations (we’re looking into have some other articles translated). Should translated articles be grouped with the original or should they be considered new articles? Do you like the idea of the flag? Is it clear enough what it means? Is there anything I need to do to make it more clear?

The article itself is a pretty handy resource if you’re building Eclipse plug-ins. One of the huge challenges of building plug-ins is making them integrate well into the environment. While the Eclipse platform provides a great integration point, the flexibility it provides can be a bit of a curse. You can get away with a lot in your plug-ins and–if you’re not careful–you can end up making a real mess of the user experience.

Anyway… take a look at this article. Keep it in mind and refer to it often when you’re building plug-ins. Your users (and the Eclipse community at large) will thank you for it.

Today I’ve been working through some of the outstanding bugs raised against existing articles in Eclipse Corner. It’s a lot of work, but most of the changes are relatively small things that are relatively easy to fix. It’d be nice if the authors could fix the problems themselves, but I understand what it takes to find time for such things. I have nothing but respect for Eclipse Corner authors and can relate to the challenge of finding time to make these updates.

Today, I managed to update a minor bug in some sample code for “Creating JFace Wizards” by Doina Klinger. The bug, unfortunately, had nothing to do with the main focus of the article, but was none-the-less distracting to readers. From the comments in bug #101884, and based on my own quick review of the paper, the advice it gives is still pertinent and correct. This, in my opinion, is a sign of a particularly good article: it stands the test of time (the original was created in 2002). That’s not to suggest that articles containing great information that go out of date are bad; they’re also very good.

I also fixed a bug in the sample code for “How to Write an Eclipse Debugger” based on comments left in bug #81575.

There were some other minor edits in some of the other articles. I’m going to continue working through the outstanding bugs. I can’t promise that I’ll get to them all, but I’m going to try. In the meantime, you can make my job harder for me: if you know of any problems in any of the articles, please create a bug report in Bugzilla. Be sure to set the classification=”Eclipse Foundation”, product=”Community”, and component=”Articles”; if you do this, I should get notified immediately.

Apologies to Chris. I had John Arthorne’s name in my head as I was typing this and erroneously gave John credit where it was due Chris. Somebody please call me an idiot.

Chris Aniszczyk and Lawrence Mandel are taking a stab at revolutionizing the way that Eclipse articles are authored. And they’re taking a novel approach: why not use Eclipse to author articles about Eclipse?

In their article “Authoring in Eclipse“, Chris and Lawrence outline how Eclipse and WTP, combined with accepted document formatting standards (e.g. DocBook, DITA) can make authoring easier. I’m using the word “easier” selfishly: It certainly makes things a lot easier for me. For authors, there is certainly a learning curve as you get used to the format if you choose to work directly with the native format; it’s XML-based, so it’s not that hard, it’s just a little weird if you’re used to authoring documents using word-processing software. As the article suggests, there are editors available that understand the format (even one that’s an Eclipse plug-in) which should greatly decrease (though not totally eliminate) the entry cost of authoring in the format.

For me, the beauty of the process is that authors can build their documents without worrying about the format. The authors have provided transformations that will turn the document into HTML and/or PDF. The real power (for me) lies in the ability to rerender the documents into other formats when required. I can, for example, extract just the summary, date, and author information from the document to display on the articles landing page (and the Eclipse home page). All of the existing articles are in a pretty cruddy (and I feel comfortable using the term ‘cruddy’) format that I’d really like to update to something closer to the Phoenix look. At this point, I’m looking at hiring a student from the college across the road to go through the painful manual process of converting all these articles. If I had them all in DocBook format, I’d just rerender everything based on a new template.

I’m pretty excited about adding this new option for Eclipse authors. I invite authors to consider reading this article and using the template they provide. We’re not imposing this on anybody, but are instead providing this as an option.

Authors have been very busy this month. Yesterday, Frederic Plante’s article, “Introducing the GMF Runtime” was added to the Eclipse Corner Articles site. Oddly enough, in this article Frederic introduces the GMF runtime. A lot of folks have been waiting for GMF to make their lives easier (during his talk at JavaPolis, Nuno of the European Space Agency specifically mentioned GMF as one of the hot projects they’re planning to make use of).

At any rate, this article provides a good introduction to the project and what you can expect to get from it.

Earlier today, I posted an article on Eclipse Forms by Dejan Glozic onto the Eclipse Corner Articles site. It’s pretty powerful stuff; using the Forms API, you can build user interface components that look and feel “browser-like”. As the article suggests, forms are probably best suited for views and editors (not dialogue boxes), but you can use them anywhere it makes sense for you. The PDE makes extensive use of it and is a good demonstration of the power provided.

While editing this article, I made use of the advice it gives in my EBay sample RCP application. I created an editor that uses the Forms API to display some information about the selected item.

I especially like the collapsible sections and the form text control for the description. Using form text was a little problematic: the documentation for form text explicitly states that it is not intended as a replacement for a browser, but it does support a lot of HTML markup. Unfortunately, EBay descriptions tend to contain a huge amount of arbitrary markup, so I had to write a little code to sanitize the HTML and parse out all the weirdness (tables, divisions, etc.) It’s not perfect yet, but is getting very close to what I want.

In any case, Dejan’s article was very helpful.