Europa Comes into View
We've only got a week to go before one of the most important
products in our industry is released. And, as well as the iPhone, Eclipse Europa will also be
released on Friday 29th June. :-)
The last few releases of Europa have been very stable,
considering the number of bugs that have been addressed; over
the past week, over 6700 bugs have been updated. (A number of those are mass
migrations from REMIND/LATER status to P5/HelpWanted status, in preparation
for the post-Europa upgrade to Bugzilla 3.0.)
In particular, a fair bit of attention has been given to the 'new user'
experience, by trying to download and install plug-ins from a variety of
sources, as well as the existing testing that's gone on.
One of the bigger changes for a RC rollout was the rename of
Mylar to Mylyn. The rationale behind
the change (explained more eloquently on the Mylyn rename FAQ) was to do
with trademarks; Mylar is an existing trademark (albeit not for software) and
was decided that it needed to be changed. Europa will ship with the new name,
and update sites for the 3.2 builds will provide a transition to using the new
name by installing updates to the existing Mylar bundles to disable them as well
as installing new Mylyn bundles. This problem has come up a few times before,
and I think the Mylyn name change sets a good example to follow for those
needing to do something similar in the future.
Ian Skerrett of
the Eclipse Foundation has been encouraging discussion of the upcoming Europa in
blog posts; there's even a free
Eclipse shirt and the chance to win a prize for the best review; all you
have to do is blog about it (either on your own blog or at EclipseZone) and let Ian know about the link, such as
recommending it via DZone. Contact Ian for
terms and conditions.
In the OSGi space, this coming week sees the OSGi
community event in Munich. We've also been covering declarative services in the
latest couple of updates to the “Getting Started with OSGi” series; and the
latest “Getting Started with Eclipse plug-ins” describes how to create extension
points that others can extend. OSGi is also gaining strength elsewhere; Prosyst's implementation of Declarative
Services is undergoing the incubator process (though not in time for Eclipse
3.3) as well as partnering with db4objects, an
embedded OSGi database engine; and SpringIDE based on Eclipse allows
configuration of Spring configuration files, not to mention the Spring-OSGi implementation work
that's migrating the Spring codebase towards OSGi.
As for recent scare-mongering
about SWT and Mac, both the current Tiger and the upcoming Leopard will run both SWT and
RCP applications seamlessly. There's been a lot of work that Apple have provided on the
SWT_AWT bridge to make the Mac experience better, and improvements to Mac and
Java WebStart will be coming when Leopard ships. Although Carbon, an older
C-based API upon which SWT is currently based, is a 32-bit library won't be
updated to full 64-bit support, there's no reason to suspect that generic
server-side applications running Java won't be able to take advantage of the
64-bit memory space. And for the UI-based systems that need SWT (such as RCP or
indeed the IDE itself), chances are good that you won't be running it on a
system outside the range of 32-bit addressing (i.e. 4Gb) for the near future.
Even if your system supports (and has installed) much larger address space, the
IDE itself runs in a separate VM from any VMs that you launch, and the JVM
debugging interface will work seamlessly between remote VMs, regardless of how
much memory space each takes up. Although Apple is clearly focussed on the
Objective-C object-oriented/framework API, there's no reason to suggest that Mac
is any less of a development platform for Eclipse-using applications — and
remember, Eclipse isn't just a Java IDE; it's an IDE for C, for Python, for Ruby
... as well as other (non) IDE uses such as the Lotus Notes runtime. And on the
Mac, 64-bit data munging (such as image transformation) is almost certainly
handled better by CoreImage and CoreAnimation than it is with generic Java
code.
As with last year's release of Europa, there will be
(undoubtedly) a lot of interest hitting the Eclipse download servers; and the
Eclipse mirrors will be taking the brutn of that download hit. The download
router uses GeoIP to attempt to pick a
(geographically) nearby mirror instead of downloading something remotely;
primarily, that's because it gives better service (it's faster) but also to
reduce the global internet traffic. Recently, there's been an upsurge of
interest in Eclipse from
China, overtaking the US in terms of number of downloads. However, whilst
the US is well-covered as far as download mirrors go, China only has one
operational mirror. If you know of any providers able to offer
mirroring in China for the Eclipse downloads, please contact the Eclipse
webmaster to set up a dialogue.
Finally, I'd like to congratulate the Eclipse Foundation members,
project leads, committers and contributors for making Eclipse the continuing
success story that it is today. It's a testament to the agile project management
that year after year, despite hundreds (thousands?) of bundles, the final
release of Eclipse falls on or about the same day each year with a quality
reputation second to none.
Until Next Time,
Alex Blewitt
alex@eclipsezone.com