[To be read with a drum roll and a David Letterman voice/accent:]
Here we go. The Top 10 Reasons to Integrate Struts and JSF
#10. You don't have enough letters in the acronyms in your project to make up your own alphabet.
#9. Job Security
#8. It looks good on your resume.
#7. It sounds sexy.
#6. Struts is for controlling. JSF is UI.
#5. You wanted to learn yet another set of tags.
#4. It's easier to integrate Ajax into Struts by using JSF.
#3. Because you're bored and have way too much time on your hands!
#2. You actually have a need to have a Telnet Front-End. (Or Flex, or XUL, or XAML, or WML, or ...)
And the #1 sign you've missed the point of
#1. Because J2EE doesn't have enough layers, you thought you'd add one more!
Thursday, March 20, 2008
Monday, March 17, 2008
The Real Cost of IBM Rational Developer Tools
Executive Summary: IBM's RAD Tooling cost companies tens of thousands of dollars per developer per year in lost productivity above and beyond the product's cost.
We frequently get asked many questions about the state of Java Enterprise Edition developer tools in classrooms and as consultants. By far, the most often tool comparison that is requested is IBM Rational Application Developer (or RAD) (or its bigger brother, IBM Rational Software Architect, or RSA) and MyEclipse. Occasionally we get asked about the completely free Eclipse Web Tools Project. There seems to be a lot of developer frustration with the IBM tooling, including in the areas of price, performance, and features.
Please note that we are not selling any product nor do we hold stock, options, or any form of equities in any of the products mentioned. Our mission is to increase the productivity of our constituents – whether they are students or clients.
WSAD 5
Before its acquisition of Rational in December 2003, IBM introduced the WebSphere Studio Application Developer tool (WSAD) version 5.0. Earlier versions were , TTBOMK, Visual Age evolutions. I had toyed with VA and many other similar tools in the past but had judged them all “Not Ready For Prime Time.” Like most J2EE developers, I continued to us “vi” and command line tools for most of my J2EE development. Other favorites included Emacs, but basically most serious J2EE developers found that tools of that era got more in their way while producing proprietary uneditable and unfixable artifacts to tie you to one platform or another. J2EE being about open choice, most of us “just said no.”.
For reference, I was also using earlier versions of NetBeans (and Forte) for the Swing development and a few other features, but J2EE development was largely missing. Command line and text editor development was still the predominant set of tools, even if you did replace your text editor with NetBeans.
WSAD 5.0 represented a quantum leap forward. It was a heavily integrated GUI develoment environment that significantly increased productivity while producing a mostly generic set of artifacts that could be deployed to any server. While initially only supporting IBM's Websphere Application Server (WAS) out of the box, only trivial additions like a jboss-web.xml file were needed to support additional servers. The biggest productivity gains were realized by code assist (the equivalent of MS' IntelliSense technology), near-automatic key XML artifact creation and manipulation (especially the key J2EE Deployment Descriptors), automatic compilation, automatic WAR/EAR creation, and automatic publishing to a WAS server. Numerous wizards and perspectives such as the Data Tools perspective (enabling a consistent graphical tool to issue queries against the supported database servers) and the Debug perspective (enabling 3-Tier debugging!) gave serious aid to the J2EE developer. Additional frameworks like Struts were supported with advanced wizards and XML-assistance, but work still needed to be done. In Struts case, IBM was only officially supporting 1.0 and had a 1.1 beta version. Validation artifacts were not addressed. The palette drag and drop needed some further evolution. The tool was expensive – around $5,000US – but compared to the amount of productivity gained for a J2EE developer making in the ballpark of $100,000 it was well worth it. Months of messing around with XML, WAR, and EAR files were instantly vaporized.
WSAD 5.1 and XDE
Still, WSAD 5.0 was not perfect. It had many bugs, including nasty memory leaks and other quirks and misfeatures. Hot-replace of server side code was fragile at best, and frequently required expensive WAS server restarts. Republishing errors were common, sometimes requiring deployed packages to be un-deployed and re-published. WSAD 5.1 fixed most of the critical issues and was considered a very good tool by most compared to its peers. Still expensive, but still well worth the money to serious J2EE developers.
Around this time, and just before the IBM purchase, Rational introduced a WSAD (and MS Visual Studio) plugin called “XDE”. XDE was the first attempt at a Model-Driven Architecture and Development tool (MDA/MDD). The idea was very simple – take a UML diagram that describes your system's architecture and have it generate code from existing templates. Modify or tweak the code by hand where needed and the tool should be able to automatically update the UML model (this is called “Round Trip Engineering”). In a practical environment, you needed to have a UML documentation package anyways. Getting it to do most of your coding for you following well-defined templates and practices – quicker, easier, cheaper, and higher quality – was a serious boon. This plugin attempted to realize the best practice of visualizing your code as well as keeping the documentation in sync with the code – something that had always been nigh-impossible to achieve before. This tool was a great idea but in practice never lived up to its marketing promise. Great academic proof of concept, but definitely not ready for prime time. The plugin itself was also very expensive – around $5,500US just for the plugin. To use it with WSAD, total tool costs were over $10,000US, which was about 10% of a J2EE developer's salary. Still, warts and all, significant productivity gains could be realized – as much as 5-6 months or so if the developer was experienced enough with the underlying technologies and patient enough to beat the tools into submission to get them to do what he or she wanted them to do.
RAD 6
After 5.1, IBM brought the Rational development team on to WSAD development and XDE integration for version 6. The tools changed names a bit – WSAD became Rational Application Developer (RAD) and the integrated WSAD+XDE became Rational Software Architect (RSA). Version 6.0 was released in May 2005 at a hefty 1.8GB, along with re-introducing many of the bugs that had been fixed in WSAD 5.1. Several wizards were removed, deprecated, or made extremely difficult to find, including several Struts tools that had been widely promoted by IBM in the previous generation. Struts support, which continues to be widely used to this day in the financial services, airline, automotive, and defense industries (among other similar mom-and-pop industries :-) stagnated. The highest version IBM has ever supported as of this writing was Struts 1.1. The rest of the world has moved on years ago to Struts 1.2, 1.3 and 2.0. In its stead, IBM selectively and exclusively pushed the strength of its JSF (Java Server Faces) tools. JSF was an evolving standard at the time – about to be included in future JEE versions. RAD 6 required about 3.8GB of patches (over twice the size of the original release) to be stable enough to attempt to use on a daily basis. Interestingly, RAD 6 shipped with Eclipse 3.0 as its core – even though version 3.2 was about to be released about a month after RAD 6 (Eclipse versions are released consistently at the end of every June). Subsequent patches failed to include updates to newer versions of Eclipse – which was about 2 years behind the current version at RAD release time. Fighting with the tool and its bugs became the norm – not the excepOverall productivity was significantly less than previous versions – many corporations continue to rely on WSAD 5.1 to this day rather than “upgrade” to RAD 6 or RAD 7.
On the positive side, IBM dropped the pricing of RAD to around $2000/year and RSA to around $3000/year. You can still purchase the product outright like before for around the same price. Considering the biannual release schedule, it's about the same price.
RAD 7
RAD 7 was released at the beginning January 2007, at an original size of 5.5 Gb. Quickly doing the math, it looks suspiciously like RAD 6 with all the patches already applied. Overall performance didn't seem to be any better – the same sluggish feel of RAD6 with patches continued in RAD7. Support for Struts was clearly dying on the vine and saw no improvement since the previous version. Even the touted JSF support seemed to not have improved at all, despite nearly two years since the previous release and some truly exciting things happening in the JSF space – including being officially included in JEE5.
The current patch set to bring it up to 7.0.0.5 is 1.8GB. (Total size for the those doing the math: 7.3GB.) Proponents of this tool assure me that it is now in fact a stable tool. My initial findings don't concur, but I've only had minimal interaction with this recent update.
RAD 7.5 is currently in beta, with a scheduled release of around the end of 2008. That's putting a release about every 2 years.
Bloated tools and Sit and Spin
One of the more difficult things to measure is the “sit and spin” time. Times where the UI is unresponsive due to a large number of background workspace tasks (such as builds and XML validations). You can disable automatic builds and publishes on RAD (which even IBM recommends in order to gain better reaction speeds), but this largely defeats the point of the tool in the first place. Similar tools also exhibit some “sit and spin” times, but are orders of magnitude less invasive.
Interrupting your Feng Shui
J2EE developers frequently publish to their server. Very often this requires a server restart, as the server wants to hold the in-memory copy of your application in-memory – even though it's received a new copy of the application on disk. Some servers hold onto the memory copy more aggressively than others. From a developer's perspective a tight hold is detrimental because of the frequency of changes made. WAS 6 has a switch to enable a more aggressive release, but even with this switch a J2EE developer will go through about 6-10 restarts a day while in heavy development mode. WAS 6 server restart time is measured typically in minutes – around 3-5 minutes for a server with minimal applications installed, or around 20-25 minutes for a WAS installation with something like WebSphere Portal Server installed. Imaging being in the “groove” of coding – focusing – developing – and then all of a sudden you realize that a server restart is required to see the latest batch of changes. At any where from 5 to 25 minutes, your “groove” is broken. You might as well get a cup of coffee. Or a pot. Maybe check your email, the latest scores or YouTube video. Whatever it is you're doing at this point doesn't matter – your feng shui is fenged. Even when the server finishes its restart, you're going to have to get back “in the groove”, and this might take significantly longer than the server start time.
Comparably, Tomcat 6 starts in milliseconds (around 600-800 for most modern PCs). JBoss 4.x is around 18-30 seconds. Of course, installing more applications and components will increase that. My fully loaded JBoss installation with my key 6 development apps, Alfresco, Seam, and all the database connection pools and queues takes 45 seconds to start. That includes JBoss Portal server.
Eclipse
The Eclipse core that IBM donated to the Eclipse foundation is OpenSource and the basis of a good number of tools, not just RAD. Adobe's Flex development environment, CompuWare's OptimalJ, and MyEclipse are just a few. The core includes support for Java Standard Edition Development. Honestly, the Java editor and debugger with built in code-assist (again, MicroSoft calls this IntelliSense in their Visual Studio product - they've had it since VB5, we just got around to conceptually stealing the feature from them around 2002) is the reason I switched from my primary tools of vi and NetBeans (I still use NetBeans in an alt-tab fashion until plugin-in compatibility is achieved - it's much much better at Swing, OpenGL, and MicroEdition, among other things). I still have issues with Eclipse - in particular I think the SWT widget set is architecturally a horrid piece of dung that is antithetical to everything we love about Java, but those issues are worth working with.
Eclipse has been released consistently at the end of every June for the last 6 years. The last several years they've also included a simultaneous release of popular plugins like C/C++, Web Tools, Testing and Performance, UML/Modeling, Reporting, Data Tools, XML, and many more, making as complete a tool environment as RAD itself. They've been naming the simultaneous release after the moons of Jupiter – Callisto was the first in 2006, Europa was last year (2007). June 2008 will bring us Ganymede. If memory serves, there are 16 moons total for Jupiter. Obviously they plan on doing this for a long time.
Aside from being a great OpenSource project, it is a great model for iterative project management. Doing what they do inside of a tightly controlled corporation would be challenging enough – doing it with a worldwide cast of volunteers is nothing short of awe-inspiring. I think NASA and Google are going to hire the team for the next moon landing.
MyEclipse
MyEclipse brings together a number of OpenSource projects together, such as EasyStruts and AST Wizards, their own version of server control, and a few other pieces. They clean them up significantly, along with adding a consistency that's impossible to achieve by just coupling the projects together yourself. They include support for most J2EE development tasks, including Web Design, JavaScript and AJAX development and Debugging, very up-to-date Struts 1.x support, JSF Support, EJB Development, and much more. There is a half-baked attempt to port the Matisse Swing Editor from NetBeans, but it still hasn't arrived. The Professional Edition includes UML and some limited MDA/MDD support and the ability to reverse engineer Oracle databases, triggers, and PL/SQL procedures. MyEclipse Blue – due to be released this Spring (2008), is a direct attack on IBM with WSAD 5.1 holdouts who don't want to upgrade to RAD6 or RAD7. It puts a little more focus on WebSphere connectivity.
MyEclipse has been my tool of choice since I gave up on RAD6. I've been using it since version 3.8.4 – and while I found it a little wanting back then compared to WSAD 5.1, they've consistently updated the product every 6 months or so and are right on top of new features.
Noticeably different between the tools is the installation size. For two products that are very comparable in features, MyEclipse Professional ships at 250MB. There are a few MB of patches to download to get it up to the latest patch level, but they're optional and only take a few minutes to download. RAD 7.5 is 5.5+1.8GB to get to a stable usable version, or 7.3GB. Even if you add the full WAS 6.1 server and the C/C++ features that RAD has – even if you add all of your favorite moon of Jupiter (Callisto/Europa/Ganymede), MyEclipse weighs in at less than 1.5GB. Runtime memory requirements are similarly fractional – MyEclipse runs well in 256MB to 384MB of memory with the embedded Tomcat server. I'd recommend 512MB if you're going to run JBoss with all the bells and whistles (Seam, Portal Server) and an Oracle XE or MySQL instance. Of course with all things Java, more RAM is better, but it can run under these circumstances. RAD7 recommends at least 1GB. 1.5GB is minimum if you're running WebSphere Portal Server. Make it 2GB if you want OracleXE.
The real RAD-killer – aside from the fact that it actually works out of the box – is the price. Regular edition is $30 for an annual subscription, Professional is about $60, and the Blue Edition is scheduled to ship at $149.
My only real problem with MyEclipse is that they're not OpenSource. They use a lot of it, skirt the GPL/LGPL to the point of disbelief. I don't mind paying for software – but I do want the ability to improve it or customize it by writing my own plugins and then to see the improvements go back to the rest of the world. I was an OpenSource convert in 1989 – way before it was “cool”.
Eclipse and the Web Tools Project
After RAD 6, IBM also donated a piece of their server control mechanism to the Eclipse Foundation. This was coupled with other donations to become the Web Tools Project, which can be plugged into the core. The first few versions were very light on features and functionality - like most OpenSource projects - but over time it has been maturing to the point of surpassing the commercial software. (Most OpenSource projects that survive their "infant mortality" will do this - look at the Gnu Compiler Chain/Collection - it is arguable if you can even buy a better compiler than this bedrock of modern software development.)
Web Tools is on that cusp. I'm currently beta-testing Web Tools Project 3.0 under Eclipse 3.4 (Ganymede) due to be released this June, and so far I'm very impressed. I'm not likely to renew my 18+ MyEclipse licenses when they come up in May.
Web Tools 3.0 (currently M5) includes support for EJB, Web Services, JavaScript/Ajax, JPA persistence, JSF, and the Server control.
Not all of these features are in the Web Tools 1.5/2.0 plugin we used in the quantification.
Quantifying the Difference
While the difference between tools is instantly visible qualitatively to anyone who has seen the tools in operation side-by-side, a quantitative analysis is often more compelling to decision makers – especially when the difference is spelled out in the most important factors – time and money. (We'll assume that the quality of output is a function of the developer, not the tool).
For the sake of this quantification, we recorded the development of the same application on IBM's RAD 7.0.0.5, MyEclipse 6.02 with embedded Tomcat 6, and Eclipse 3.3 with Web Tools 2.0 and Tomcat 6. We also did final deployment to JBoss and WAS 6.1 inside of the MyEclipse and Eclipse+Web Tools installations. We also compared Eclipse 3.4 + Web Tools 3.0 - both of which are pre-release software - but just as an interesting comparison. We wouldn't seriously recommend anyone use pre-release software for production development. We may do a future update of this report with RAD 7.5.
RAD 7 has no support for non-EJB JPA oriented persistence such as Oracle's Toplink or Hibernate, so we substituted EJB 2.0 Entity Beans instead. This is a significant architectural change from lighter weight JPA persistence, so we also included a hand-developed Hibernate project (which significantly disadvantaged RAD from a development time perspective, but we felt it was important for architectural comparison sake – apples to apples so to speak.) IBM's SDO could have been used as a possible alternative, but we are not aware of any significantly sized J2EE shop using this tool in production.
The same developer (Calvin Vette) was used for both tools to eliminate experience inconsistencies. Mr. Vette's bio is available at the link referenced below.
[Article Truncated. Contact author for details.]
We frequently get asked many questions about the state of Java Enterprise Edition developer tools in classrooms and as consultants. By far, the most often tool comparison that is requested is IBM Rational Application Developer (or RAD) (or its bigger brother, IBM Rational Software Architect, or RSA) and MyEclipse. Occasionally we get asked about the completely free Eclipse Web Tools Project. There seems to be a lot of developer frustration with the IBM tooling, including in the areas of price, performance, and features.
Please note that we are not selling any product nor do we hold stock, options, or any form of equities in any of the products mentioned. Our mission is to increase the productivity of our constituents – whether they are students or clients.
WSAD 5
Before its acquisition of Rational in December 2003, IBM introduced the WebSphere Studio Application Developer tool (WSAD) version 5.0. Earlier versions were , TTBOMK, Visual Age evolutions. I had toyed with VA and many other similar tools in the past but had judged them all “Not Ready For Prime Time.” Like most J2EE developers, I continued to us “vi” and command line tools for most of my J2EE development. Other favorites included Emacs, but basically most serious J2EE developers found that tools of that era got more in their way while producing proprietary uneditable and unfixable artifacts to tie you to one platform or another. J2EE being about open choice, most of us “just said no.”.
For reference, I was also using earlier versions of NetBeans (and Forte) for the Swing development and a few other features, but J2EE development was largely missing. Command line and text editor development was still the predominant set of tools, even if you did replace your text editor with NetBeans.
WSAD 5.0 represented a quantum leap forward. It was a heavily integrated GUI develoment environment that significantly increased productivity while producing a mostly generic set of artifacts that could be deployed to any server. While initially only supporting IBM's Websphere Application Server (WAS) out of the box, only trivial additions like a jboss-web.xml file were needed to support additional servers. The biggest productivity gains were realized by code assist (the equivalent of MS' IntelliSense technology), near-automatic key XML artifact creation and manipulation (especially the key J2EE Deployment Descriptors), automatic compilation, automatic WAR/EAR creation, and automatic publishing to a WAS server. Numerous wizards and perspectives such as the Data Tools perspective (enabling a consistent graphical tool to issue queries against the supported database servers) and the Debug perspective (enabling 3-Tier debugging!) gave serious aid to the J2EE developer. Additional frameworks like Struts were supported with advanced wizards and XML-assistance, but work still needed to be done. In Struts case, IBM was only officially supporting 1.0 and had a 1.1 beta version. Validation artifacts were not addressed. The palette drag and drop needed some further evolution. The tool was expensive – around $5,000US – but compared to the amount of productivity gained for a J2EE developer making in the ballpark of $100,000 it was well worth it. Months of messing around with XML, WAR, and EAR files were instantly vaporized.
WSAD 5.1 and XDE
Still, WSAD 5.0 was not perfect. It had many bugs, including nasty memory leaks and other quirks and misfeatures. Hot-replace of server side code was fragile at best, and frequently required expensive WAS server restarts. Republishing errors were common, sometimes requiring deployed packages to be un-deployed and re-published. WSAD 5.1 fixed most of the critical issues and was considered a very good tool by most compared to its peers. Still expensive, but still well worth the money to serious J2EE developers.
Around this time, and just before the IBM purchase, Rational introduced a WSAD (and MS Visual Studio) plugin called “XDE”. XDE was the first attempt at a Model-Driven Architecture and Development tool (MDA/MDD). The idea was very simple – take a UML diagram that describes your system's architecture and have it generate code from existing templates. Modify or tweak the code by hand where needed and the tool should be able to automatically update the UML model (this is called “Round Trip Engineering”). In a practical environment, you needed to have a UML documentation package anyways. Getting it to do most of your coding for you following well-defined templates and practices – quicker, easier, cheaper, and higher quality – was a serious boon. This plugin attempted to realize the best practice of visualizing your code as well as keeping the documentation in sync with the code – something that had always been nigh-impossible to achieve before. This tool was a great idea but in practice never lived up to its marketing promise. Great academic proof of concept, but definitely not ready for prime time. The plugin itself was also very expensive – around $5,500US just for the plugin. To use it with WSAD, total tool costs were over $10,000US, which was about 10% of a J2EE developer's salary. Still, warts and all, significant productivity gains could be realized – as much as 5-6 months or so if the developer was experienced enough with the underlying technologies and patient enough to beat the tools into submission to get them to do what he or she wanted them to do.
RAD 6
After 5.1, IBM brought the Rational development team on to WSAD development and XDE integration for version 6. The tools changed names a bit – WSAD became Rational Application Developer (RAD) and the integrated WSAD+XDE became Rational Software Architect (RSA). Version 6.0 was released in May 2005 at a hefty 1.8GB, along with re-introducing many of the bugs that had been fixed in WSAD 5.1. Several wizards were removed, deprecated, or made extremely difficult to find, including several Struts tools that had been widely promoted by IBM in the previous generation. Struts support, which continues to be widely used to this day in the financial services, airline, automotive, and defense industries (among other similar mom-and-pop industries :-) stagnated. The highest version IBM has ever supported as of this writing was Struts 1.1. The rest of the world has moved on years ago to Struts 1.2, 1.3 and 2.0. In its stead, IBM selectively and exclusively pushed the strength of its JSF (Java Server Faces) tools. JSF was an evolving standard at the time – about to be included in future JEE versions. RAD 6 required about 3.8GB of patches (over twice the size of the original release) to be stable enough to attempt to use on a daily basis. Interestingly, RAD 6 shipped with Eclipse 3.0 as its core – even though version 3.2 was about to be released about a month after RAD 6 (Eclipse versions are released consistently at the end of every June). Subsequent patches failed to include updates to newer versions of Eclipse – which was about 2 years behind the current version at RAD release time. Fighting with the tool and its bugs became the norm – not the excepOverall productivity was significantly less than previous versions – many corporations continue to rely on WSAD 5.1 to this day rather than “upgrade” to RAD 6 or RAD 7.
On the positive side, IBM dropped the pricing of RAD to around $2000/year and RSA to around $3000/year. You can still purchase the product outright like before for around the same price. Considering the biannual release schedule, it's about the same price.
RAD 7
RAD 7 was released at the beginning January 2007, at an original size of 5.5 Gb. Quickly doing the math, it looks suspiciously like RAD 6 with all the patches already applied. Overall performance didn't seem to be any better – the same sluggish feel of RAD6 with patches continued in RAD7. Support for Struts was clearly dying on the vine and saw no improvement since the previous version. Even the touted JSF support seemed to not have improved at all, despite nearly two years since the previous release and some truly exciting things happening in the JSF space – including being officially included in JEE5.
The current patch set to bring it up to 7.0.0.5 is 1.8GB. (Total size for the those doing the math: 7.3GB.) Proponents of this tool assure me that it is now in fact a stable tool. My initial findings don't concur, but I've only had minimal interaction with this recent update.
RAD 7.5 is currently in beta, with a scheduled release of around the end of 2008. That's putting a release about every 2 years.
Bloated tools and Sit and Spin
One of the more difficult things to measure is the “sit and spin” time. Times where the UI is unresponsive due to a large number of background workspace tasks (such as builds and XML validations). You can disable automatic builds and publishes on RAD (which even IBM recommends in order to gain better reaction speeds), but this largely defeats the point of the tool in the first place. Similar tools also exhibit some “sit and spin” times, but are orders of magnitude less invasive.
Interrupting your Feng Shui
J2EE developers frequently publish to their server. Very often this requires a server restart, as the server wants to hold the in-memory copy of your application in-memory – even though it's received a new copy of the application on disk. Some servers hold onto the memory copy more aggressively than others. From a developer's perspective a tight hold is detrimental because of the frequency of changes made. WAS 6 has a switch to enable a more aggressive release, but even with this switch a J2EE developer will go through about 6-10 restarts a day while in heavy development mode. WAS 6 server restart time is measured typically in minutes – around 3-5 minutes for a server with minimal applications installed, or around 20-25 minutes for a WAS installation with something like WebSphere Portal Server installed. Imaging being in the “groove” of coding – focusing – developing – and then all of a sudden you realize that a server restart is required to see the latest batch of changes. At any where from 5 to 25 minutes, your “groove” is broken. You might as well get a cup of coffee. Or a pot. Maybe check your email, the latest scores or YouTube video. Whatever it is you're doing at this point doesn't matter – your feng shui is fenged. Even when the server finishes its restart, you're going to have to get back “in the groove”, and this might take significantly longer than the server start time.
Comparably, Tomcat 6 starts in milliseconds (around 600-800 for most modern PCs). JBoss 4.x is around 18-30 seconds. Of course, installing more applications and components will increase that. My fully loaded JBoss installation with my key 6 development apps, Alfresco, Seam, and all the database connection pools and queues takes 45 seconds to start. That includes JBoss Portal server.
Eclipse
The Eclipse core that IBM donated to the Eclipse foundation is OpenSource and the basis of a good number of tools, not just RAD. Adobe's Flex development environment, CompuWare's OptimalJ, and MyEclipse are just a few. The core includes support for Java Standard Edition Development. Honestly, the Java editor and debugger with built in code-assist (again, MicroSoft calls this IntelliSense in their Visual Studio product - they've had it since VB5, we just got around to conceptually stealing the feature from them around 2002) is the reason I switched from my primary tools of vi and NetBeans (I still use NetBeans in an alt-tab fashion until plugin-in compatibility is achieved - it's much much better at Swing, OpenGL, and MicroEdition, among other things). I still have issues with Eclipse - in particular I think the SWT widget set is architecturally a horrid piece of dung that is antithetical to everything we love about Java, but those issues are worth working with.
Eclipse has been released consistently at the end of every June for the last 6 years. The last several years they've also included a simultaneous release of popular plugins like C/C++, Web Tools, Testing and Performance, UML/Modeling, Reporting, Data Tools, XML, and many more, making as complete a tool environment as RAD itself. They've been naming the simultaneous release after the moons of Jupiter – Callisto was the first in 2006, Europa was last year (2007). June 2008 will bring us Ganymede. If memory serves, there are 16 moons total for Jupiter. Obviously they plan on doing this for a long time.
Aside from being a great OpenSource project, it is a great model for iterative project management. Doing what they do inside of a tightly controlled corporation would be challenging enough – doing it with a worldwide cast of volunteers is nothing short of awe-inspiring. I think NASA and Google are going to hire the team for the next moon landing.
MyEclipse
MyEclipse brings together a number of OpenSource projects together, such as EasyStruts and AST Wizards, their own version of server control, and a few other pieces. They clean them up significantly, along with adding a consistency that's impossible to achieve by just coupling the projects together yourself. They include support for most J2EE development tasks, including Web Design, JavaScript and AJAX development and Debugging, very up-to-date Struts 1.x support, JSF Support, EJB Development, and much more. There is a half-baked attempt to port the Matisse Swing Editor from NetBeans, but it still hasn't arrived. The Professional Edition includes UML and some limited MDA/MDD support and the ability to reverse engineer Oracle databases, triggers, and PL/SQL procedures. MyEclipse Blue – due to be released this Spring (2008), is a direct attack on IBM with WSAD 5.1 holdouts who don't want to upgrade to RAD6 or RAD7. It puts a little more focus on WebSphere connectivity.
MyEclipse has been my tool of choice since I gave up on RAD6. I've been using it since version 3.8.4 – and while I found it a little wanting back then compared to WSAD 5.1, they've consistently updated the product every 6 months or so and are right on top of new features.
Noticeably different between the tools is the installation size. For two products that are very comparable in features, MyEclipse Professional ships at 250MB. There are a few MB of patches to download to get it up to the latest patch level, but they're optional and only take a few minutes to download. RAD 7.5 is 5.5+1.8GB to get to a stable usable version, or 7.3GB. Even if you add the full WAS 6.1 server and the C/C++ features that RAD has – even if you add all of your favorite moon of Jupiter (Callisto/Europa/Ganymede), MyEclipse weighs in at less than 1.5GB. Runtime memory requirements are similarly fractional – MyEclipse runs well in 256MB to 384MB of memory with the embedded Tomcat server. I'd recommend 512MB if you're going to run JBoss with all the bells and whistles (Seam, Portal Server) and an Oracle XE or MySQL instance. Of course with all things Java, more RAM is better, but it can run under these circumstances. RAD7 recommends at least 1GB. 1.5GB is minimum if you're running WebSphere Portal Server. Make it 2GB if you want OracleXE.
The real RAD-killer – aside from the fact that it actually works out of the box – is the price. Regular edition is $30 for an annual subscription, Professional is about $60, and the Blue Edition is scheduled to ship at $149.
My only real problem with MyEclipse is that they're not OpenSource. They use a lot of it, skirt the GPL/LGPL to the point of disbelief. I don't mind paying for software – but I do want the ability to improve it or customize it by writing my own plugins and then to see the improvements go back to the rest of the world. I was an OpenSource convert in 1989 – way before it was “cool”.
Eclipse and the Web Tools Project
After RAD 6, IBM also donated a piece of their server control mechanism to the Eclipse Foundation. This was coupled with other donations to become the Web Tools Project, which can be plugged into the core. The first few versions were very light on features and functionality - like most OpenSource projects - but over time it has been maturing to the point of surpassing the commercial software. (Most OpenSource projects that survive their "infant mortality" will do this - look at the Gnu Compiler Chain/Collection - it is arguable if you can even buy a better compiler than this bedrock of modern software development.)
Web Tools is on that cusp. I'm currently beta-testing Web Tools Project 3.0 under Eclipse 3.4 (Ganymede) due to be released this June, and so far I'm very impressed. I'm not likely to renew my 18+ MyEclipse licenses when they come up in May.
Web Tools 3.0 (currently M5) includes support for EJB, Web Services, JavaScript/Ajax, JPA persistence, JSF, and the Server control.
Not all of these features are in the Web Tools 1.5/2.0 plugin we used in the quantification.
Quantifying the Difference
While the difference between tools is instantly visible qualitatively to anyone who has seen the tools in operation side-by-side, a quantitative analysis is often more compelling to decision makers – especially when the difference is spelled out in the most important factors – time and money. (We'll assume that the quality of output is a function of the developer, not the tool).
For the sake of this quantification, we recorded the development of the same application on IBM's RAD 7.0.0.5, MyEclipse 6.02 with embedded Tomcat 6, and Eclipse 3.3 with Web Tools 2.0 and Tomcat 6. We also did final deployment to JBoss and WAS 6.1 inside of the MyEclipse and Eclipse+Web Tools installations. We also compared Eclipse 3.4 + Web Tools 3.0 - both of which are pre-release software - but just as an interesting comparison. We wouldn't seriously recommend anyone use pre-release software for production development. We may do a future update of this report with RAD 7.5.
RAD 7 has no support for non-EJB JPA oriented persistence such as Oracle's Toplink or Hibernate, so we substituted EJB 2.0 Entity Beans instead. This is a significant architectural change from lighter weight JPA persistence, so we also included a hand-developed Hibernate project (which significantly disadvantaged RAD from a development time perspective, but we felt it was important for architectural comparison sake – apples to apples so to speak.) IBM's SDO could have been used as a possible alternative, but we are not aware of any significantly sized J2EE shop using this tool in production.
The same developer (Calvin Vette) was used for both tools to eliminate experience inconsistencies. Mr. Vette's bio is available at the link referenced below.
[Article Truncated. Contact author for details.]
Subscribe to:
Posts (Atom)