Bugzilla – Full Text Bug Listing
| Summary: | [1.8] Allow compiling on Java 7 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Alexander Kurtakov <akurtakov> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, jarthana, srikanth_sankaran, stephan.herrmann, thanh.ha |
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Alexander Kurtakov
Adding David Williams on CC as it needs to be verified that this would not break releng somehow. David, are there builds happening on Java 7 yet? Yes, our builds run with Java 7. Is that what you meant to ask? Not sure I understand the activation logic of <jdk>1.8</jdk> That almost sounds like you meant to ask if we are using 1.8 when we do the the compile? (Which, we do not, and do not plan to). Assuming that's all just a matter of my education and it "works fine", I'd also be concerned that we have a feature that "calls for" two versions of jdt.annotations (1.1 and 2.0), but only one was available. That would certainly break _our_ build, but not sure if this is to help others re-build the platform .... or ... just parts of it? (In reply to David Williams from comment #3) > Yes, our builds run with Java 7. Is that what you meant to ask? > > Not sure I understand the activation logic of > > <jdk>1.8</jdk> So this means that the module is activated when maven is run with Java 8 or the module is activated manually ( -P java8). > > That almost sounds like you meant to ask if we are using 1.8 when we do the > the compile? (Which, we do not, and do not plan to). Just to verify. Maven is running on Java 7 and toolchains.xml points to Java 8 right? If this is the case I can revert the logic to enable the profile by default and people that don't need it can deactivate manually (-P !java8). Does it sound better that way? > > Assuming that's all just a matter of my education and it "works fine", I'd > also be concerned that we have a feature that "calls for" two versions of > jdt.annotations (1.1 and 2.0), but only one was available. That would > certainly break _our_ build, but not sure if this is to help others re-build > the platform .... or ... just parts of it? Which feature exactly do you mean? As the new module has BREE JavaSE-1.8 which will not be available if run on Java 6/7 I thought it's not call for two versions but call for one or the other. This is to help people build the platform on Java 7 that intend to run on Java 7 and don't have Java 8 available nor will have it supported for these builds thus the bundle with BREE JavaSE-1.8 being useless. (In reply to Alexander Kurtakov from comment #4) > (In reply to David Williams from comment #3) > > Yes, our builds run with Java 7. Is that what you meant to ask? > > > > Not sure I understand the activation logic of > > > > <jdk>1.8</jdk> > > So this means that the module is activated when maven is run with Java 8 or > the module is activated manually ( -P java8). > > > > > That almost sounds like you meant to ask if we are using 1.8 when we do the > > the compile? (Which, we do not, and do not plan to). > > Just to verify. Maven is running on Java 7 and toolchains.xml points to Java > 8 right? Right. > If this is the case I can revert the logic to enable the profile by default > and people that don't need it can deactivate manually (-P !java8). Does it > sound better that way? > Yeah, sounds better that way, to me. > > > > Assuming that's all just a matter of my education and it "works fine", I'd > > also be concerned that we have a feature that "calls for" two versions of > > jdt.annotations (1.1 and 2.0), but only one was available. That would > > certainly break _our_ build, but not sure if this is to help others re-build > > the platform .... or ... just parts of it? > > Which feature exactly do you mean? As the new module has BREE JavaSE-1.8 > which will not be available if run on Java 6/7 I thought it's not call for > two versions but call for one or the other. > This is to help people build the platform on Java 7 that intend to run on > Java 7 and don't have Java 8 available nor will have it supported for these > builds thus the bundle with BREE JavaSE-1.8 being useless. It is in the jdt feature. And it's not "one or the other" ... but both. <plugin id="org.eclipse.jdt.annotation" download-size="0" install-size="0" version="1.1.0.qualifier" unpack="false"/> <plugin id="org.eclipse.jdt.annotation" download-size="0" install-size="0" version="2.0.0.qualifier" unpack="false"/> The latter being the one that requires Java 8, naturally. This was to support cases where someone could be running their IDE with Java 7, but writing code for Java 8. (Or, vice-versa). = = = = = = Out of curiosity, what platform's don't have support for Java 8? ppc? All packages for RHEL must be built on RHEL with OpenJDK version shipped with this RHEL. As Java 8 is pretty new release no RHEL version contains it but our eclipse products have to support them so even if one can download Oracle's Java it's not something that is allowed to be used for building. Also on Fedora we do Eclipse builds (full ones with native parts rebuild) on ppc/ppc64/ppc64le/arm/aarch64/x86/x86_64/s390/s390x and OpenJDK is shipped on all of them but I'm not sure neither I checked whether Oracle Java 8 is available for download for all of them. The problem here arise from the fact that on Fedora only single OpenJDK version is supported so having a build pointing to two separate JVMs is problematic. Ammended patch submitted to gerrit: https://git.eclipse.org/r/#/c/23773/ Thanks for the explanation, and "reversing" the default ... but, the "repository build" we do at the end will fail, if that bundle is not there, as required by the feature. (Well, and that's the problem I am aware of ... there might be others?) ... So ... need a solution for that (even if you personally didn't care about "getting the repository" I think some people would. No? [And, to be clear to casual readers ... this would not effect _our_ builds ... just those who wanted to omit the jdt.annotation 2.0 bundle.] Thinking loud about it, it might be easier to just keep local patch for that than getting it properly. I can't think of a way to change the feature in a sensible way to make this happen. If others are on the same page feel free to close it. If someone have some hints I'll try to do it. I give up on this one. |