New Help for Old Friends II

This page to to collect miscellaneous notes and pointers to changes coming up in the WTP 2.0 (Europa) release. Its purpose it to be a central "jump off" point for those adopters of WTP 1.5, that are moving to WTP 2.0. Most of this information may be already contained in various mailing lists and bugzilla's, but ... we thought it best if there as a central place to get people started.

Adopters: if you run into trouble or notice things that are not covered here, please let us know (wtp-dev@eclilpse.org is a good place). This will not only help us keep this list up to date, but will help us better learn, over time, the discipline of "platform development" and help make sure we learn to provide compatible API's, migration instructions, etc., in the future. [ It isn't always easy, but our intent is to make it as simple and painless as possible for adopters to use WTP as a true platform.

One thing we've learned in the past is that some don't adopt every version ... some early adopters went from 0.7 directly to 1.5, for example. Unfortunately, it's hard for us to present the information in that way, covering perhaps multiple changes, but hopefully as we develop these for each release, they will all flow together to aide adopters.

Note: as these notes develop and grow in number, they may occasionally be re-organized into categories, etc.

Version Changes

Often, adopters will have to tweak the version per-req ranges to match the new ones in WTP (or the Platform, or EMF, etc). This is easiest to do by loading WTP as part of your PDE target and see what breaks. But, for a bit of peek ahead, we list versioning information with each build. See the M4 Build page for an example of "Versioning Information".

Also, below, are some of the more noteworthy changes.

Change required for users of org.junit

Anyone who has
org.junit
in their 'Require-Bundle:' header, in manifest.mf, must change it to
org.junit;bundle-version="[3.8.0,4.0.0)"

See bug 17251.

Change required for users of JEM

Since the JEM 1.x stream is incompatible with EMF 2.3, the version number of JEM will increment to 2.0. There will be no API changes, per se, in JEM, but, the JEM 1.x stream was was over optimistic in stating in there manifest.mf files that they would continue to work with EMF up EMF 3.0 (exclusive) but that's turned out not to be the case due to some subclassing of some ECore classes that are not considered API by the EMF team.

In this release, we are not planning on distributing the bundle in JEM named com.ibm.etools.emf.event. This is a very old bundle for which the source was lost (approximately 5 years ago, from what I hear). For this reason, I'm reluctant to perpetuate its distribution. So far, we have not found any clients/adopters who need it. If we do, we'll simply distribute the exact same (binary) version distributed previously. See bug 174700.

Classloading Behavior

There's some changes with OSGI classloading that I _think_ we've protected adopters from ... but, is still something Adopters should watch out for. This especially comes into play with xerces and DOM API's, since with the xerces bundle, we are essentially replacing what ever implementation comes with the running JRE. One typical symptom would be to see Classcast Exceptions from "dom.Node" to "dom.Node", for example. See bug 167695 for details. Again, we _think_ this should be transparent to adopters, so if anyone sees issues with xerces, let us know, as there might be more we can do on our end. And, naturally, if anyone uses other classes with identical names to JRE classes (e.g. some jmx api?) then you may also anticipate changes related to classloading. BTW, in general, these changes in classloading are a great, much needed thing in Eclipse's use of OSGI ... so, do not complain to them! :)

Some methods changed to use Java 5 Generics

This can be a perfectly transparent transition to make, but, there are various ways to react:

1. clients can set their compiler to compile to the 1.4 spec, in which case, all is transparent (but do not get the extra compile time checking that generics provide).
2. clients can compile to Java 5, and then do a bunch of quick fixes to add casts: quick and easy, but also hides the advantage of compile time checking.
3. clients that want to compile to Java 5 can actually change their code to use the proper types in the Collections so that they will get compile time errors, if the wrong type is ever used accidentally.

See also some EMF specific info at EMF_2.3_JVM_Requirements

Changes related to Dnd

There's some changes with platform text Drag-and-Drop that I _think_ only effects source editors. We are not sure if this effect's others, but, basically there is some hard-to-see-java-doc about using the styledText widget directly. We do not think the changes we had to react to will transfer or perculate up to adopters, but if anyone else uses source editors, they might want to read bug 173397 or bug 173405.

Changes to JSP content models

org.eclipse.jst.jsp.core.internal.contentmodel.JSPCMDocumentFactory.getCMDocument() now returns the JSP 2.0 CMDocument, not a wrapper around a JSP 1.2 CMDocument. The previous JSP 1.2 document may be obtained from the JSPCMDocumentFactory.getCMDocument(String) method using the new org.eclipse.wst.xml.core.internal.provisional.contentmodel.CMDocType.JSP12_DOC_TYPE key value. Keys for the 2.0 CMDocument as well as the CMDocument to use for .tag/.tagx files are also provided.