Community
Participate
Working Groups
Currently we compile certain projects (org.eclipse.osgi, and p2) with source 1.5, target jsr14. This allows us to use generics (but not annotations, enums) and still generate version 48 class files for Java 1.4 (also JME Foundation). These class file have generics attributes which are processed by javac from Java 5 and Java 6. However, starting with Java 7, javac no longer recognizes generics attributes from version 48 class files. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7078419 I propose that we stop using jsr14 and simply claim a minimum execution environment of Java 5. This cannot be taken lightly since we are talking about the lowest component (the framework) of the eclipse platform stack.
+1 to goodbye Java 1.4.
+1. Most of the Eclipse Platform has moved on already. The trade-off at this point is to continue supporting embedded consumers we would be preventing anyone using javac against Equinox libraries. As an ecj user myself I can live with that, but it doesn't seem like a good trade-off for the wider community.
Just to be clear, does this mean we won't be able to support embedded consumers? I'm not using JavaME myself, but IIRC one of the goals of OSGi was to be a component runtime for embedded systems. Does the OSGi spec say anything about this? How far reaching will this be?
Another question if you don't mind ... is this advice that everyone should follow? Or is it something specific to Equinox? I'd assume people could still "compile against" 1.4 if not using generics, etc., but you would advise everyone to not write to 1.5 while targeting to jsr14? (I do not know of any other cases ... just thought it should be clarified explicitly). Thanks,
(In reply to comment #3) I second Ian's concern. I'm not doing embedded Java myself, but every year at EclipseCon there's an impressive number of talks regarding OSGi / Equinox usage on embedded. What does an 1.5 BREE mean for J2ME ? What do other OSGi frameworks like Apache Felix ? The eRCP folks may want to comment on this.
I suspect that this also means that the generified OSGi APIs will stop compiling with JavaC 7. Thomas, can you clarify this? In any case, anything other than "org.eclipse.osgi[.*]" should move up. Frankly, I really doubt that anybody runs p2 or DS or the Jetty HTTP Service on an embedded device. In terms of org.eclipse.osgi I'm not sure about alternate options. How do embedded developers compile their code? Do they use Javac 7 or is there some other compiler that still works? Will it still be possible to compile org.eclipse.osgi with an older compiler for a lower execution environment?
(In reply to comment #6) > I suspect that this also means that the generified OSGi APIs will stop > compiling with JavaC 7. Thomas, can you clarify this? Yes, this is a problem for all OSGi implementations since the core OSGi APIs now include generics. > In terms of org.eclipse.osgi I'm not sure about alternate options. How do > embedded developers compile their code? Do they use Javac 7 or is there some > other compiler that still works? Will it still be possible to compile > org.eclipse.osgi with an older compiler for a lower execution environment? Yes, the alternative is that embedded developers would need to compile OSGi themselves using jsr14 (Equinox, Felix, or whichever they choose). Or, they use an older OSGi version. The tradeoff is that if we continue using jsr14, then *nobody* can use javac from Java 7 to compile their own code against Equinox/OSGi. Everyone would need to use either the Eclipse compiler or an older Sun compiler. In other words, to continue supporting the embedded case we need to restrict everybody. I think the only path forward for embedded is the JCL modularization in Java 8, which will allow them to use a small subset of a more modern class library implementation. Until then they are stuck on Foundation 1.2 / JDK 1.4 level class libraries, and likely an older OSGi version to go with it.
(In reply to comment #3) > Just to be clear, does this mean we won't be able to support embedded > consumers? I'm not using JavaME myself, but IIRC one of the goals of OSGi was > to be a component runtime for embedded systems. Does the OSGi spec say > anything about this? How far reaching will this be? This is why I raised the issue. At some point we need to move on. Foundation 1.2 is based on a dead Java SE 1.4 VM. I suspect embedded folks WILL NOT be able to use the R5 OSGi framework implementation in Juno. There is hope that a new embedded VM will be produced out of the Java 8 modules work. We cannot live in this mode indefinitely, we either move up and accommodate the future at the risk of loosing the embedded folks (until a new embedded VM is available) or we continue in the jsr14 mode and risk loosing the rest of the Java crowd that is continuing to move up.
(In reply to comment #5) > (In reply to comment #3) > I second Ian's concern. I'm not doing embedded Java myself, but every year at > EclipseCon there's an impressive number of talks regarding OSGi / Equinox usage > on embedded. What does an 1.5 BREE mean for J2ME ? What do other OSGi > frameworks like Apache Felix ? > > The eRCP folks may want to comment on this. I have not heard from the eRCP folks in a long time and I am not aware of any future planned releases from them based on the Juno release.
Ok. Looks like what we need is input from anybody who actually uses an embedded VM with Equinox. I suggest you raise the question on cross-project as well (since eclipse-dev may not be read by everyone), maybe also blog on PlanetEclipse. In case there's no response I'd think it is fine to move up -- embedded folks could still use the Indigo version of Equinox, right ?
(In reply to comment #8) > [...] we either move up and accommodate the future at > the risk of loosing the embedded folks (until a new embedded VM is available) > or we continue in the jsr14 mode and risk loosing the rest of the Java crowd > that is continuing to move up. Sounds like a plan! Given the Eclipse LTS initiative I don't think that we'll actually loose the embedded folks. Previous Equinox release will still be there. I've also heard that a majority uses an optimized (commercial) framework implementation anyway. +1 for moving on.
First off, no new development is being done on eRCP. My own believe is that Android has almost completely superseded eRCP, so there is no longer any point in maintaining backward compatibility for eRCP. Secondly, should there be any die-hard users of eRCP or Equinox on embedded, they can use compatible Equinox versions like Indigo. It's unlikely they need (or even want) extra features provided in newer releases. Lastly, I believe Oracle made some noise at Java One about submitting a new JSR for an upgraded JME CDC that would be Java 6 compatible. So if that comes to fruition, the latest Equinox using Java 6 features will again be able to run on CDC.
I guess that in that case the jsr14 target need also to be changed on dependencies, right? (I am thinking at least about Sat4j and asm for instance)
(In reply to comment #13) > I guess that in that case the jsr14 target need also to be changed on > dependencies, right? > (I am thinking at least about Sat4j and asm for instance) Yes, Daniel I think the right think for sat4j to do is move to Java 5 (assuming you don't have others that want sat4j on a Foundation 1.2 VM).
Just a clarifying question/comment. This change is about setting the minimum JRE version that can run our libraries, but doesn't necessarily change what class library subset Equinox uses, right? I assume Equinox and OSGi in general will continue to target a reduced subset of the class libraries available in Java SE 5? I think this is still valuable given the future possibility of a modular class library with smaller profiles available in java 8. If we start using lots of extra class library packages now it would be difficult to scale back again in the future.
Excellent point John. I agree, you want to keep library dependencies minimized so that Equinox can still run on future versions of JME CDC and minimum subset of Java 8.
(In reply to comment #15) > Just a clarifying question/comment. This change is about setting the minimum > JRE version that can run our libraries, but doesn't necessarily change what > class library subset Equinox uses, right? I assume Equinox and OSGi in general > will continue to target a reduced subset of the class libraries available in > Java SE 5? I am in the middle of this same issue at OSGi as we use -target jsr14. However, when changing to -target 1.5, the compiler demands types which are not part of ee.minimum (an intersection of JavaSE 5 and JME Foundation 1.1). For example, Iterable to support foreach over Collections and StringBuilder for string constant concatenation. These types are not in ee.minimum and can't be since they are not in JME Foundation 1.1. So one must compile against JavaSE 5 class libraries. This then opens the source code up to introducing usage of types which are not in JME Foundation 1.1. For OSGi, I plan on compiling projects using -target jsr14 twice: Once with -target jsr14 and ee.minimum class libs to verify we do not use types outside of JME Foundation 1.1 and the second time with -target 1.5 and JavaSE 5 class libs. We will ship the second set of class files. Since we have confirmed via the build that the code does compile with -target jsr14 and ee.minimum, JME Foundation 1.1 users are able to safely compile the source code for their use. > I think this is still valuable given the future possibility of a > modular class library with smaller profiles available in java 8. If we start > using lots of extra class library packages now it would be difficult to scale > back again in the future. For now, you would need to do something like what I outlined above. Of course, once Java 8 arrives and you want to use it as the baseline, you can select which JRE modules to depend upon at compilation and runtime. But there are many issues here for an OSGi implementation which we hope to investigate via the proposed Penrose project at OpenJDK.
We can move up to Java 5 for compiling against and use API tooling to ensure we don't have additional creep of API usage outside of the smaller Foundation 1.2 profile. This keeps hope alive for folks that may want to recompile equinox for an embedded VM. But our minimum execution environment will not be telling the truth unless we remove the entry for the osgi min execution environment, because the binaries we produce really will not run on that VM any more.
Assigning to me to reduce spam.
(In reply to comment #18) > We can move up to Java 5 for compiling against and use API tooling to ensure we > don't have additional creep of API usage outside of the smaller Foundation 1.2 > profile. This keeps hope alive for folks that may want to recompile equinox > for an embedded VM. But our minimum execution environment will not be telling > the truth unless we remove the entry for the osgi min execution environment, > because the binaries we produce really will not run on that VM any more. Just wanted to note that leaving the BREE header in and changing it to 1.5 would require more than simply recompiling the source using -target jsr14. Folks would also need to change the BREE header. So, perhaps, removing the BREE header completely might be the best approach. The OSGi companion jars, for example, do not include one. Either way (changing it to 1.5 or removing it altogether) would require a means within Eclipse to override the BREE manifest setting in order to use the api analysis builder for workspace compilation purposes. I don't see a way to do this, but that doesn't necessarily mean there isn't one.
(In reply to comment #17) > (In reply to comment #15) > > Just a clarifying question/comment. This change is about setting the minimum > > JRE version that can run our libraries, but doesn't necessarily change what > > class library subset Equinox uses, right? I assume Equinox and OSGi in general > > will continue to target a reduced subset of the class libraries available in > > Java SE 5? > > I am in the middle of this same issue at OSGi as we use -target jsr14. However, > when changing to -target 1.5, the compiler demands types which are not part of > ee.minimum (an intersection of JavaSE 5 and JME Foundation 1.1). For example, > Iterable to support foreach over Collections and StringBuilder for string > constant concatenation. These types are not in ee.minimum and can't be since > they are not in JME Foundation 1.1. So one must compile against JavaSE 5 class > libraries. For your information, Sat4j was based on Java 5 before shipping with Eclipse. compiling with jsr14 was not sufficient to allow the code to run on a Java 1.4 VM : references to post 1.4 API such as Iterable, Integer.valueOf(), StringBuilder was a problem. It meant indeed to avoid forEach loops in the code. Changing the target to 1.5 instead of jsr14 won't prevent people to recompile the code on an older VM if we still point the API tools to a 1.4 VM and do not use syntactic sugar such as forEach loops. (or tp revent us to provide a build for embedded use).
I don't think anything will be done here at this point.
I released changes to stop using jsr14 for the following bundles: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=afd5f96ac81c0cc17918da755c85b32ce4fabded org.eclipse.osgi org.eclipse.equinox.supplement http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=c239b4595c36da8371c91ae8b64f288e873187df org.eclipse.equinox.coordinator org.eclipse.equinox.event org.eclipse.equinox.metatype In all five bundles above I decided to simply move up to BREE JavaSE-1.5 and not try to do anything fancy to limit the execution environment usage. In theory the source code, as it is today, can still be down compiled to J2SE 1.4 but over time I expect this no longer be true as the code changes and we introduce hard dependencies to APIs in JavaSE-1.5.
