First off, a big, fat disclaimer: Eclipse is a long-time client of ours and they’ve hired RedMonk to do a series of 5 screencasts on the Eclipse Europa release. The first two are currently available: Equinox and BIRT.
June 29th
Intriguingly timed (by coincidence, no doubt) to be released on the same date as the iPhone and the GPLv3, Eclipse Europa is the second go at a coordinated release of Eclipse projects.
There are three interesting dimensions to the Europa release:
- A platform for platforms – as Burton’s Joe Niski put it:
Europa is good for the overall development-tool landscape, and worth some attention.
- More tools for programmers – projects like Mylyn (formally Mylar) for task-tracking integration and GTD-ish focus on projects, database browsing and DbUnit tools in DTP, Dash for GreaseMonkey like ease-of-re-tooling, end-user centric (rather than just platform-providing) enhancement to the reports engine BIRT, and other additions for day-to-day tasks.
- A move into the server-side – Eclipse has so far been primarily about desktop/GUI development. As our Equinox screencast mentioned above shows, the OSGi tooling and features in Europa are moving Eclipse’s ambitions into the server side.
Platform for Platforms
The primary Eclipse mission is to provide the raw tools for building other software. Those tools can be in the form of IDEs (like the Java Development Toolkit, the C/C++ Development Toolkit, and the Dynamic Languages Toolkit) or in the form of frameworks that are used to produce other software rather than “finished tools” themselves. Eclipse’s foot-in-the-door to grab attention and drive downloads was always it’s Java IDE, but over the last few years, developers as a whole have realized that the Eclipse platform is development ecosystem on it’s own. While you don’t hear the phrase “Eclipse developer” as much as you hear “Java developer” or “Microsoft developer,” it’s clear that we there is a the space and technology for a such developer type.
As the Eclipse platform is largely focused on providing tools for creating tools, tools vendors like Borland/CodeGear, IBM’s Rational, and Geniutec were the first to dive into the Eclipse platform for their own software offerings. Cases like NASA’s use of Eclipse as a platform point towards success as well.
Above just providing frameworks for tool software, bits and pieces I’ve seen in the Europa in particular are interesting for producing software in general. The Eclipse Modeling Framework (EMF) in particular seems like a low intensity way to create domain models, while the component model and technology provided by Eclipse’s OSGi component, Equinox, looks interesting as a Java component model for those who don’t want to wait until the officially sanctioned Java component technologies shake-out over the next few years.
Tools for Programmers
I’ve mentioned my attraction to Mylyn (formally “Mylar”) several times before. For those who don’t already use it, Mylyn will be incredibly helpful for developers, and the Europa bundled release looks even more so. Even if you don’t immediately “get it” with the task focusing features of Mylyn, the bug/task-tracking system integration is enough to warrant a look-see. Having an Eclipse native UI built into Eclipse to manage your bugs and tasks is much better than switching context out of Eclipse and into whatever issue tracking software you have to use. After that feature-foot is in the door, the even more awesome and helpful task focusing and context-pickling should follow.
Also, as I saw in one of the screencasts, the Data Tools Project (DTP) looks like it will deliver an out-of-box, free database browser and query tool in Eclipse. While DTP does much else, providing a simple database browser and query tool is a big check-box to fill. The DbUnit integration looks handy as well.
Eclipse has sort of had a spotty reputation when it comes to flashy, usable tools. Geniutiec has been successful covering up those spots. While Europa is focused primarly on platform-cenctric concerns, things like Mylyn and DTP’s database browser further cover up those spots.
Another subtle shift in Europa comes in the form of packaging. Where-as Callisto included documentation for how to cobble together the Eclipse and the relevant plugins for different roles (Java, C/C++, “Enterprise Development,” mobile, etc.), Europa will include the actual downloads there-in. As one developer mentioned to me, NetBeans had always been good at that and it’s good for Eclipse to catch-up.
The Broader Context of OSGi
For me, the OSGi tooling and thinking is the most interesting aspect to watch. There’s a big, important standard discussion/battle looming over the horizon in the Java world. Everyone wants and is working on or thinking about how to break up Java projects and Java itself into smaller, more manageable pieces. We’re all under a flag that reads “Remember CORBA!” but we can’t quite agree on how to code ourselves out of bloatsland.
On the Sun devotee side we have in-development superpackages and JSR 277. On the other side, which includes Eclipse and several other Java leaders I’ve spoken with, we have OSGi. While OSGi was developed as a standard, it wasn’t developed in the standards church of Java, the JCP. So, the question of which technology Java on a diet with is up for grabs.
The Java church has experienced the painful lessons of not bringing successful technologies into the fold, instead rejecting or duplicating them. We had the log4j/java.util.logging snafu at first, then the Java world seemed to have figured it out a tad more (though with duplication rather than embracing) with annotations/xdoclet and Hibernate/EJB3. The integration of the concurrency APIs seems to have made most happy.
Still, I don’t think we’ve seen the sort of successful open source technology gobbling up rather than NIH re-engineering that we take for granted in the broader Java world, or even the aspect-y, layering approach Spring takes with successful Java code-bases rather than re-tooling from the ground-up.
So, there’s the context. Europa’s Equinox is a good line in the sand from Eclipse: it’s running code, for a long-used way to provide modules/components in Java. Running code can be hard to beat, but so can accepted standards that are eventually shipped with the platform. For me, how the JCP handles this component question over the next year or so will be good background for discussions of an “open source” JCP.
The Usual Question: NetBeans
In comparing NetBeans and Eclipse — as everyone is apt to do — keeping the platform notion in mind is key. NetBeans is primarily “end-user centric,” as it were, while Eclipse is primarily “platform centric.” This means that NetBeans is more centered around providing a product ready to use out of the box than Eclipse, and then around providing a general-use platform, while Eclipse is the opposite. The answer in Eclipse-land, of course, would be to point towards all of the “partners” who take that approach such as MyEclipse, IBM, CodeGear, Oracle, and the numerous others. Of course, the answer would also be that things like the JDT are ready to use out of the box, which they are. The point is subtle, but nonetheless there.
Indeed, in neither case does this mean that either innately fails to fulfill it’s secondary goal: NetBeans can be used as a platform to deliver other tools and other GUI applications, while Eclipse has long shown that you can start developing software after download as quick as you can type code.
But, just browse through their respective web-sites: NetBeans typically wants to first tell you how to start pounding nails, while Eclipse wants to first tell you about the hammer. As an example — which I’m sure both camps can fully link-caviot — check out the NetBeans ruby page vs. the Eclipse Dynamic Languages Toolkit page: the fact that NetBeans goes with the specific — ruby — over the general — dynamic languages — is really all you need for the “ready to use tool” vs. “tool for tools” frame. Like I said: subtle.
In my mind, for most people (people who want raw development tools) the most useful comparisons between Eclipse and NetBeans are between the IDEs and development tools in both: Java, C/C++, (now) ruby, or the utilities like the NetBeans Profiler and Eclipse TPTP. If I were to start writing code again full-time (Java or ruby), I’d certainly check out NetBeans for awhile and compare it to Eclipse. I wouldn’t have considered a non-Eclipse option until recently. For all you horse-race, zero-sum fans out there, we’ll have to keep our eye on NetBeans 6.0. It’s looking slick, esp. with the Ruby support and Jackpot. I suspect that best of breed features will be NetBeans killer feature in the present and medium future.
On the other-hand, looking at the bigger, architectural issues — modeling, packaging and code segmentation, data-tooling, and other technology-injected-practices — my gut is to go with Eclipse. I know Eclipse will take care of my raw IDE-needs and pulling in the rest of the framework, both technology and theory, would tip the scale heavily onto the Eclipse side. For Eclipse, the platform is the killer feature, and Europa seems to deliver on that whole-hog.
Disclaimer: Eclipse and Sun are clients. As is Genuitec and IBM.
Technorati Tags: eclipse, equinox, europa, java, jsr277, mylyn, netbeans, osgi
"Sun devotee", "NIH re-engineering", ''Java church", "the standards church of Java, the JCP", those comments sound like OSGi messaging rather than analyst comments. There really is no value in simplistically opposing the two.
NetBeans will need a version or two after 6 to mature, but it'll eventually get there (wherever "there" is…)
Sorry to rub you the wrong way with the diction, John.
I’m not saying the notion of getting an agreed on standard worked out in the JCP is worse or better than the alternative, but devotion to either “church” seems the problem. Indeed, as I indicate above, the progression from the — forgive the use again — classic “Java church” to a more inclusive church seems like it’s on track. We’ll see.
Thanks cote'. I guess I was hoping for more analysis on how this should move forward. It is not a question of incompatible "alternatives", only incompatible people. The technologies can and should live together.
Great posts and podcasts btw.
John: I agree, and the Java component/module topic is actually one of the top three, if not the top thing, I talk about with Java people now-a-days. As I've told all of them, I'd really like to do a podcast, a post, a panel, or some other sort of public discussion with all sides involved. Obviously, it's worth writing on more frequently, so thanks for the input 😉
OSGi wasn't developed inside the JCP "church", but it certainly now has a seat in the choir with JSR 291. I wonder if that changes the game for those whose devotion to JCP is paramount. Or do they just care that the high priest himself (Sun) voted against the JSR, in opposition to the rest of the priesthood?
Another aspect of the NetBeans versus Eclipse comparison, aside from focus on the platform, is the community. I don't need to tell you how enormous the Eclipse community is. How about NetBeans'? It appears to be a community consisting of just Sun, and that's not healthy. Even Microsoft does better at building an ecosystem around Visual Studio, despite all their devious license terms and occasional suing of valuable business partners.
Neil, this is just not constructive and I hope this tone is not representative of the OSGi community. Or is it?
We have JSR 277 and 291 overlapping. What should we do next? Kill one of them? Doesn't make sense to me.