When I was first introduced to Callisto, I understood it to be an effort to release several Eclipse projects simultaneously. This is still my understanding, but it seems that Callisto has evolved to mean a lot more to many folks. Some talk of Callisto in terms of a universal installer with a consolidated update site. In fact, there is some work going on to provide the consolidated update site, but an installer of any form was never part of the original plan. I'm pretty sure that it's still not part of any plan. While I agree that having a super deluxe GL-6000 installer would be cool, it's just not part of the original promise of Callisto.
What Callisto is is still pretty important. In the past, there has always been latency between the release of the platform and the release of other projects So, for example, if you wanted to use the latest and greatest version of the platform with--say--WebTools you might be out of luck for a few months while the WebTools team worked to their own schedule. With Callisto, you will be able to use the latest version of the platform with the latest version of WebTools on the same day. Or at least within a few days. Heck, in my mind even being able to use the latest and greatest of everything within a few weeks is still pretty good.
Eclipse hints, tips, and random musings
From archive: March 2006 X
I thought it was common knowledge, but after speaking with a bunch of people last week, I guess it isn't. So here it goes... the Java compiler that comes with Eclipse is not the standard javac compiler you get with the Java SDK. Nope, it's a completely separate compiler.
It does wonderful things. My personal favourite thing about the Eclipse Java compiler is the fact that it will compile code that contains errors. That is, when you compile code that has errors in it, the compiler will flag those errors for you and then generate the .class file anyway. You can actually run and debug the code and, should the runtime actually run into your errors, it will then throw an exception.
This is pretty handy when you're doing top-down development. Step one is write the top-level code. Step two is implement some piece of the top-level code. Step three is run and test it. As long as your tests don't run into the unimplemented code, you're golden. Even then, it's not the end of the world. Think about this in terms of unit tests. You don't actually have to make all your tests run right away, just the ones you actually want to test at any point in time. Any JUnit test cases you have that have errors in them (because the code hasn't been implemented yet) will be reported as errors, but everything else will run as normal.
How cool is that?
It gets better. Lots of folks think that the JDT compiler is pretty awesome. Did you know that when you use JSPs on Apache Tomcat 5.5 Eclipse Java compiler is used to compile them? Or that IntelliJ IDEA 6.0 will support Eclipse Java compiler? GCJ, the GNU compiler for Java is switching to use the Eclipse Java Compiler. There are many others.
The Eclipse Java compiler does not depend on the Eclipse platform. It has a front-end API which can be piloted either from the Eclipse IDE, from an Ant task, or from a simple command-line tool (batch compiler). I'm talking with a few folks about writing up an Eclipse Corner Article or two on compiler topics. Should be good stuff.
I spoke last night at the RTP WebSphere Users Group on the topics of Eclipse WebTools and Rich Client Platform. I think the talk went well. I measure success in two ways: number of closed eyes and number of folks who leave part way through. I counted no more than two sets of closed eyes and only one (maybe two) folks left before I wrapped up. And... there was only one open laptop that I could see. Out of a crowd of about thirty folks, that's not bad.
There were some decent questions, but one at the end threw me off. It was a pretty fundamental question that I actually have an answer for, but for some reason, I couldn't get the right words out. Perhaps it was because of how late it was in the evening after a long day of lecturing and chatting with folks at the Eclipse in Motion seminars we delivered earlier in the day ... (excuses, excuses)
"When should you use a rich client instead of a browser?"
Ian talked about this in his blog a while ago. Last night, I mumbled something about the richness of the user experience and working off line. Ian jumped in to save the day by discussing the type of users. The argument is essentially this: if your users are more on the casual side, then a web browser provides a fine interface. A good example is online banking. I don't need a rich client application to do online banking. However, a power user that sits in front of an application all day, tends to navigate with the keyboard rather than the mouse, and depends on insanely good responsiveness from the application might benefit from a rich client. A teller at the bank, helpdesk employee, or data entry clerk are potential examples. I'll have to add this to the talk.
You can download last night's presentation here.[Read More]