Community
Participate
Working Groups
See bug 348155 for more details. We have been kicking this can along for long enough. We need to do the work ourselves to determine what package versions are available in the VM so that orbit bundles can do the right thing and have proper package substitution if the version of the package they export is provided by the VM. The issue so far is that we have not been able to find any definitive answer to the package versions included in the various Java SE versions. Sometimes it is difficult to get an accurate package list let alone accurate package versions. This has been causing us grief for too long and we should try to determine the information ourselves. Especially for the bundles in orbit which export (and should import) the packages they provide which may also be provided by the running VM depending on the VM version.
This is far from definitive, but for Virgo we researched the package versions for Java 6 and added appropriate export versions to http://git.eclipse.org/c/virgo/org.eclipse.virgo.kernel.git/tree/build-kernel/lib/java6-server.profile
Thanks Glyn, Can you explain the reasoning behind exporting at version 0.0 (no version) and a specific version? Also, javax.transaction is a known mess with types split between Java SE and EE but why do you export it at two real versions? javax.transaction,\ javax.transaction;version="1.0.1",\ javax.transaction;version="1.1.0",\ javax.transaction.xa,\ javax.transaction.xa;version="1.0.1",\ javax.transaction.xa;version="1.1.0",\ I'm not sure what the best approach is for javax.transaction. If we were to treat it like a split package the we should like place mandatory directive on it to prevent casual importers from importing the packge and thinking it is the complete Java EE package. Something like: javax.transaction; mandatory:="osgi.ee"; osgi.ee="JavaSE"; version="?.?.?"
(In reply to comment #2) > Thanks Glyn, > > Can you explain the reasoning behind exporting at version 0.0 (no version) and > a specific version? We wanted, out of the box, to support bundles which had been written to run in environments which don't attempt to provide non-zero versions of these packages. So if a bundle imported one of these packages with a version range such as [0,0], it would still resolve in Virgo. > > Also, javax.transaction is a known mess with types split between Java SE and EE > but why do you export it at two real versions? > > javax.transaction,\ > javax.transaction;version="1.0.1",\ > javax.transaction;version="1.1.0",\ > javax.transaction.xa,\ > javax.transaction.xa;version="1.0.1",\ > javax.transaction.xa;version="1.1.0",\ > > I'm not sure what the best approach is for javax.transaction. If we were to > treat it like a split package the we should like place mandatory directive on > it to prevent casual importers from importing the packge and thinking it is the > complete Java EE package. Something like: > > javax.transaction; mandatory:="osgi.ee"; osgi.ee="JavaSE"; version="?.?.?" This particular one is tricky. Virgo adds the JAR com.springsource.javax.transaction-1.1.0.jar (from the SpringSource Enterprise Bundle Repository) to the system classpath. This JAR contains sufficient classes to provide both 1.0.1 and 1.1.0 levels of the packages (1.1.0 is a backward compatible superset of 1.0.1) which are then made available from the system bundle without needing to be split.
*** Bug 348203 has been marked as a duplicate of this bug. ***
Going to move this to Kepler.
(In reply to comment #2) > javax.transaction; mandatory:="osgi.ee"; osgi.ee="JavaSE"; version="?.?.?" This boils down to the question of what is the specification of the javax.transaction package. IMHO trying to add on package versions in an afterthought is doomed to fail. Example: javax.mail 1.4.5 is offered as a bundle from the original provider - and that bundle exports 1.4.0 (!) packages. AFAIK, all previous wrappers, e.g. of javax.mail 1.4.1 guessed this wrong: they export the same package in version 1.4.1. This will happen over and over again, unless package versions and contracts are provided by the original provider of the library. This bug should hence be an JSR in the Java community process. FYI: p2 currently ignores mandatory attributes (bug 360659), so such a statement may lead to problems with installations create by p2.
We recently switched to Java 7 and bugs like this prevents our installation touchpoint to be executed. The problem is that eclipse just says that the action wasn't found, but users have no clue that this is caused by a "wrong" java version. Additional to this on some systems where java 7 is installed, eclipse still runs on java 6 due to a configuration problem during setup. Is it really that difficult that it takes over two years to solve such an essential feature. May be I don't see the complexity behind this, but there should be at least a small check when collecting the bundles before Installation telling the jre is not matching the required java.specification.version.
(In reply to comment #7) > We recently switched to Java 7 and bugs like this prevents our installation > touchpoint to be executed. The problem is that eclipse just says that the > action wasn't found, but users have no clue that this is caused by a "wrong" > java version. Additional to this on some systems where java 7 is installed, > eclipse still runs on java 6 due to a configuration problem during setup. Is > it really that difficult that it takes over two years to solve such an > essential feature. May be I don't see the complexity behind this, but there > should be at least a small check when collecting the bundles before > Installation telling the jre is not matching the required > java.specification.version. This bug is about the framework exporting the non java.* packages provided by the running java environment from the system bundle AND providing the proper package versions for these packages at runtime. It sounds to be like you are describing a provisioning issue (p2 perhaps?). Also bundles that require a specific java execution environment (or version) should use either the Bundle-RequiredExecutionEnvironment header or the osgi.ee generic requirement namespace.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
