Bugzilla – Full Text Bug Listing
| Summary: | JRE container with EE is not backwards compatible with 3.1 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Darin Wright <darin.eclipse> |
| Component: | Debug | Assignee: | Kevin Barnes <cocoakevin> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | daniel_megert, dj.houghton, eclipse, francois, gunnar, jeffmcaffer, markus.kell.r, michaelvanmeekeren, philippe_mulet, pombredanne, pwebster, sonia_dimitrov, Tod_Creasey, wassim.melhem |
| Version: | 3.2 | ||
| Target Milestone: | 3.2 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Darin Wright
It looks like we've put ourselves in a difficult position here. In 3.1, a JRE container path that referenced a JRE looked like
segment 0: JRE container id
segment 1: vm type id
segment 2+: vm name
The code that extracts the name removed the first two segments and returned the rest as a VM name:
public static String getVMName(IPath path) {
return path.removeFirstSegments(2).toString();
}
This means segments 2 and greater will be used as VM name, making it difficult to make the two formats compatible. (If we add segment 3 as "this is an EE reference" and segment 4 as EE id, the segments will be picked up as part of the VM name in 3.1).
Suggestions?
Talking with Philippe, we suggest to make the new "EE" container path use segments 3 & 4 as: seg 3: key that denotes an EE reference seg 4: EE identifier This will break 3.1 using 3.2 EE's. We'll need to provide a patch for 3.1.x client such that it can still resolve a JRE based on type/name, and add it to the readme. re: "This will break 3.1 using 3.2 EE's." My understanding is that they are broken anyway with today's. At least it gives us a more consistent story looking forward, and we could fix 3.1 by changing the VM name retrieval (and from there on be forward compatible in 3.1). Looks like another PR for this issue against 3.1 would be needed, and a patch attached for later delivery (on demand). Filed bug 136372 for 3.1 required fix. Released new support to HEAD. This has the side effect of breaking any existing buildpaths/launch configs bound to an execution environment, as we have changed the syntax of the "container path". Fixed in JREContainerInitializer and JavaRuntime Please verify, Kevin. (In reply to comment #4) > Filed bug 136372 for 3.1 required fix. Released new support to HEAD. This has > the side effect of breaking any existing buildpaths/launch configs bound to an > execution environment, as we have changed the syntax of the "container path". > When I reselect J2SE-1.3 it generates one of the new "format" classpaths: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/j2sdk1.4.2_08/executionEnvironments/J2SE-1.3"/> Is it normal that it would reference j2sdk1.4.2_08? What if I'd done it on a 1.5.0 JRE? PW The build path indicates that it is bound to a J2SE1.3 JRE. The 3.2 tooling will attempt to bind to a JRE that matches that. However, if your workspace does not contain a J2SE1.3 JRE, it binds to a compatible JRE (in your case, 1.4.x - which is a superset of 1.3.x). The 3.1 tooling will continue to work because it does not know about the execution environment segments - just the JRE type & name. We have an open bug to warn when the JRE bound to an EE is not strictly compatible with the resolved JRE. So, you will get a build path warning for this in the future (perhaps RC2). It's a little unfortunate that 1.4 shows up as the JRE for 3.1 tooling - but the 3.1 tooling has no way to hint at compliance levels for JREs - just JRE names. If you had a 1.3 JRE in the workspace, then it would have shown up on the container, and would be used by the 3.1 tooling. darin, unless I'm missing something, I also find it disconcerting that a hardcoded vm name is saved along the EE in the sharable .classpath file. The tooling does not user the name when the environment is specified. It's just there for forwards compatibility with 3.1. This was discussed approved by Philippe and Jeff. The chosen solution does not work for me in 3.1.2. I checked out org.eclipse.core.expressions from HEAD and changed the classpath entry to the new format: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.3.1/executionEnvironments/J2SE-1.3"/> But even if I define a JRE with name "jdk1.3.1", the JRE container stays "Default System Library (Unbound)". Since the new format is also not compatible with 3.1.2, I suggest to revert to the previous format in HEAD. 3.1.3 could then be fixed (bug 136372) to resolve a path "org.eclipse.jdt.launching.JRE_CONTAINER/executionEnvironments/J2SE-1.3" to an installed JRE with name "J2SE-1.3". Markus: read comment 4 We took the 20060413 build and updated our execution environment and it is compiling fine for us now. Fixed in 3.2RC1. We settled on this format: segment 0: container id - JRE_CONTAINER segment 1: vm type id segment 2+: vm name or execution environment id In 3.2, to resolve a VM we first see if the name corresponds to an EE. If so, we bind to an EE. Else we look for a VM with the given name/type. In 3.1, this also works if your JRE is named the same as the EE. This allows 3.1 developers to create a JRE with that name and continue without a patch to 3.1.x. Please verify, Kevin. For RC1, we accept all recent formats. For RC2 we will only support the required formats (so those that migrated will not be broken immediately - but if they update classpaths they will use the new format). Changes to JavaRuntime, JREContainerInitializer, StandardVMType. (In reply to comment #14) > For RC1, we accept all recent formats. With I20060413-0010, the org.eclipse.jdt.apt.* plug-ins will not compile (unless the classpath is updated). 1) I wonder whether some broader distribution of this late and breaking change is in order? E.g., posts to the newsgroups, mail to eclipse-dev? 2) Should I be updating the classpath of these plugins and committing the change? 3) The new classpath contains the path segment "org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType". It feels somewhat troubling to be using an internal package this way. Are these going to become API at some point? 1) there will be a post next week about updating classpaths - we intend to have all plug-ins migrate to using Execution environments. 2) for now you can update the classpath and commit the change. You will likely have to do it again next week. 3) We've always used the vm type identifier (StandardVMType) to identify a vm type - its not API, and not meant to be human readable/editable - it is for the tooling to generate and use. verified |