Among the most notable enhancements is the support for Java 1.5 language features that improve productivity, clarity and compilation-checking.
- Using Generics eg java.util.Map<String, Integer> mMap = new HashMap();
- Static import eg import static javax.swing.JLabel.*;
- Variable arguments in method eg public void test(int _i, String… _sArStr)
- Annotation eg @Annotate
- Improved For loop eg for (String _i : list)
A definition of Release Candidate from Wikipedia is cited as “a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage, the product features all designed functions and no known showstopper-class bugs. At this phase the product is usually code complete.” So in this version of GWT rc1, it means that the product is as good as feature-completed and the main task need to do is to iron out any known bugs during testing before deciding on whether another release candidate is necessary prior to final stable release. No doubt that GWT is a great piece of engineering work done by a great team of talented software engineers. However a product that rely on other system is not enough for its own merit and so this is where the disappointment comes from.
Lack of support from IDE
In current situation, compiling a GWT 1.5 application using existing support from Intellij gives error (Disclaimer: I never been able to use NetBean’s GWT plugin flawlessly, and I yet to try on Eclipse support yet. As one later see, this is not the issue.), let alone run it.
Errors generated from compiling GWT application using GWT 1.5 in Intellij
No doubt that support for GWT 1.5 from respective IDEs vendors will be expected due to its popularity but until the final release, the vendors most likely will take a wait and see attitudes in addressing such support (Especially that GWT plug-in in Netbean & Eclipse are delivered voluntary) , and this is where a catch-22 situation occurs. Without the current GWT 1.5 support from IDE, very few developers are willing to test the latest features of GWT and to find and report bugs. The most likely kind of bugs report are those that arise from running previous version of GWT application. Running unit test does not help much since it is only through permutation of using several features or APIs that highly likely to expose critical issues. In this aspect, it defeat the purposes of release candidate where the release should be tested and used ‘in the real world’ as much as possible so the final version will not exhibit obvious bugs.
My experience in using GWT 1.5 currently is tantamount to driving a Porsche with punctured tyre. Yes, one could still use ANT script as the last resort to do the development where compilation and debugging are done through command-line but why bother with so much in-productivity and pain ? Like majority of developers, I will rather do the testing in a IDE as it reflects the actual development environment.
So how to resolve this situation ? What if the GWT team works with IDE vendors to deliver acceptable reasonable support for major release that at least able to perform basic task like compiling and debugging and test important features prior to release to public ? What if the GWT team could dedicate more resources to work with partners to ensure that GWT’s major release will sync with support from IDE vendors (My understanding is that GWT plug-in in NetBean and Eclipse are surprisingly done by open-source volunteers not through employee like in Intellij) ? Coordination and partnership are important to ensure that GWT ecosystem is not broken and disrupt every time a major release is announced. It will be good if GWT team periodically update their work and finding with existing IDE vendors because such news of collaboration are very encouraging and give peace of mind to the developer knowing that such healthy work relationship will only strengthen the investment one make in the technology. GWT is only as good as its ecosystem. Its strong link is only as good as its weakest link, and lack of GWT 1.5 support is the weakest link so far.
I definitely wouldn’t want to see GWT team having to repeat those unredeemable mistake by Microsoft over the release of Windows Vista where by Vista is released to the public with catastrophic lack of support and compatibility for existing and legacy devices, where driver is not ready or stable, causing malfunction and disruption to users and business. Such wrath and dissatisfaction will dent the confidence of the user and make it harder to accept similar product from the vendor in the future. Hence it is paramount that GWT team works with GWT plug-in contributors to ensure that when GWT is finally released, it is ready to be used in any popular IDEs.