Community
Participate
Working Groups
This is the top level bug to track Java 8 implementation effort in JDT/Core. At the moment the JDT team has been invited to listen in and so is privy to discussions on two topics: JSR308: Type annotations tracked via bug# 287648 and JSR335: Lambda Expressions tracked via bug# 380188
*** Bug 358387 has been marked as a duplicate of this bug. ***
Here is a query to look at all open & resolved tasks: https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5B1.8%5D;classification=Eclipse;query_format=advanced;short_desc_type=allwordssubstr;component=Core;product=JDT
Status update: For JSR308: ----------- - Completed: Scanner, Grammar/Parser + AST construction, semantic analysis, symbol/type resolution, control/data flow analysis. - In progress: DOM/AST, ASTRewrite - Pending: Code generation, code completion, code select, Java model, search/indexing ... For JSR335: - Completed: Scanner, Grammar/Parser, AST construction. - In Progress: Default method support - all phases. - Pending: Semantic analysis, symbol/type resolution, control/data flow analysis, DOM/AST, ASTRewrite, code generation, code completion, code select, Java model, search/indexing ...
Status update: For JSR308: ----------- - Completed: Scanner, Grammar/Parser + AST construction, semantic analysis, symbol/type resolution, control/data flow analysis, DOM/AST. - Under review: ASTRewrite - Scheduled/Under progress: Formatter, search engine, code generation. - Pending: code completion, code select, Java model, class file readers ... For JSR335: - Completed: Scanner, Grammar/Parser, AST construction, Semantic analysis, Symbol resolution, control/data flow analysis. - In Progress: Default method support, DOM/AST, Formatter, Overload resolution - Pending: type inference/resolution, , DOM/AST, ASTRewrite, code generation, code completion, code select, Java model, search/indexing ...
Is any of these work being integrate in Kepler (4.3) ?
if we could at least get default methods recognized (bug 380501). If you are currently e.g. subclassing AbstractList and your project is set to work against JDK8 you get compile errors because of the missing methods.
(In reply to comment #5) > Is any of these work being integrate in Kepler (4.3) ? No, Not also for SR1 and SR2. (In reply to comment #6) > if we could at least get default methods recognized (bug 380501). If you are > currently e.g. subclassing AbstractList and your project is set to work > against JDK8 you get compile errors because of the missing methods. There are various reasons why running a Java7- project against JRE8 is a bad idea. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=390889. Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=407010#c1
(In reply to comment #5) > Is any of these work being integrate in Kepler (4.3) ? We can't legally include Java 8 tools in an Eclipse release before Java 8 itself is released. Based on the current java 8 release date estimate, we would be able to include support in the Luna (4.4.0) release.
Thank you, Is there any possibility for a beta/unofficial/early access build with java 8 support. Sorry for being insistent, but without java8 anyone working with JavaFX (possibility other Java8 libraries) will be unable to use Eclipse :-(
(In reply to comment #9) > Is there any possibility for a beta/unofficial/early access build with java > 8 support. This is planned, but could be a few months away. We still have a few crucial pieces in various staged of development (in particular, overload resolution, type inference and 308 code generation are not completely done and released yet into BETA_JAVA8 branch)
Thank you, that would be great! The project I'm working has just started using java8 features and I suspect I should be able to survive even with a fairly incomplete implementation. As a matter of fact, Steve has managed to get a self-host Eclipse using JDT Core and JDT UI from the BETA_JAVA8 branch and it was "almost" good enough. I say almost because he ran in some other compiler bugs (not related to lambda). Either way, I would be happy to be your beta tester. I tried all major Java IDE and Eclipse is best one for me. But no lamba/defender method is a show stopper for me unfortunately.
The bug I ran into is Eclipse marking @Override methods as errors when there is an implementation somewhere in the hierarchy (there is no error for jdk7). I will isolate a test case and enter a bug when I get some time.
In reply to comment #12 I think that has already been fixed in BETA_JAVA8 (I hit it as bug 406928). I worked with Stephan to get it addressed. Although if you are running on the latest from the branch maybe it is something new...
I am running something from last night.
Thanks for the patch Andrew. I am now self hosting and building without compile errors.
(In reply to comment #13) > In reply to comment #12 I think that has already been fixed in BETA_JAVA8 (I > hit it as bug 406928). The fix for bug 406928 is actually in master (as of Kepler M7) but I don't yet see it cherry-picked to BETA_JAVA8. If anyone has issues with that patch please let's discuss that in bug 406928, thanks
Here are some more details for interested parties: http://wiki.eclipse.org/JDT_Core/Java8
I've managed to create a local SDK build which holds BETA_JAVA8 as JDT-Core so people can give it a try more easily. http://downloads.efxclipse.org/eclipse-java8/ I've build not directly from BETA_JAVA8 but use an extra branch on my github clone where I cherry-picked (https://github.com/tomsontom/eclipse.jdt.core/tree/BETA_JAVA8_CHERRY) the fix from bug 406928 until you cherry-picked it to BETA_JAVA8. I plan to produce and publish a new build from time to time - if you think there's a substantial fix/change that should go out give me ping on my e-mail address or my twitter acccount @tomsontom and I start a build.
Please update status on http://wiki.eclipse.org/JDT_Core/Java8. It seems to be a little bit out of date.
(In reply to comment #19) > Please update status on http://wiki.eclipse.org/JDT_Core/Java8. It seems to > be a little bit out of date. It's just been updated with the latest status: http://wiki.eclipse.org/JDT_Core/Java8
(In reply to Jayaprakash Arthanareeswaran from comment #20) > (In reply to comment #19) > > Please update status on http://wiki.eclipse.org/JDT_Core/Java8. It seems to > > be a little bit out of date. > > It's just been updated with the latest status: > > http://wiki.eclipse.org/JDT_Core/Java8 Since the developer preview of JAVA8 should be available shortly, I was wondering whether http://wiki.eclipse.org/JDT_Core/Java8 is up top date.
(In reply to Todor Dimitrov from comment #21) > Since the developer preview of JAVA8 should be available shortly, I was > wondering whether http://wiki.eclipse.org/JDT_Core/Java8 is up top date. There has been progress since the last update, but it could be another week or two before we could update it again.
We apologize for not keeping the status/meta-data up to date. We have been very busy with the work. We will update the wiki shortly. But here is the latest status: We are very pleased to announce the completion of core compiler work in the following Java 8 projects in JDT/Core: - JSR308 - Type Annotations support. - JEP120 - Repeating annotations support. - JEP118 - Parameter reflection support. - JSR269 - Annotation processor API & javax.lang.model API enhancements for Java 8. - JSR335 - Core compiler implementation is substantially in place except as relates to overload resolution and type inference. On the IDE enablement front, we are pleased to announce the completion of: - Basic IDE enablement viz AST APIs', DOM binding resolution support, Code Formatter, AST rewriting API support for all of Java 8. We also _believe_ we are completely done for - Full IDE support enablement (code completion, code selection, indexing, searching, model, reconciliation ...) for all of JSR308, JEP120, JEP118, JSR269 (i.e for all Java 8 but JSR335), However, this is a claim that we can make only after further/more intensive testing/scrutiny. Prima facie, this assertion appears justified We will ascertain the validity of this claim in the coming weeks and plug the gaps if any. As would inevitably be the case, some loose ends/corner cases remain in the aforementioned areas but as you understand, this is inherent to the business of delivering software and these are not ship stoppers. What work remains: ------------------------ The major pieces that still need attention are: - JSR335 - Overload resolution support and type inference support. - As the UI team's adoption of the Core APIs steps up to the next gears, we do expect that there will be a flurry of activity in the DOM/AST, ASTRewrite APIs. Markus Keller has been fully engaged with us in the specification and provision of these APIs. So these have undergone one level of whetting/suitability checks already. Nevertheless, we anticipate and are prepared for change requests as the actual adoption proceeds. - Full fledged IDE enablement for JSR335. - Various polish tasks. - Comparisons with reference compiler behavior in corner case scenarios. - Usability/performance improvements. Given the above, we believe we are well positioned to deliver a fully functional, feature rich, high quality, high performant implementation on March 18th 2014. Plenty of work and some significant challenges remain though: - We are continuing to be plagued by JSR335 specification gaps. The latest spec refresh 2 weeks ago has addressed many gaps we had pointed out earlier or were already acknowledged in the document itself, but quite a few gaps still remain. Stephan Herrmann, the Eclipse project lead for type inference work for Java 8 is on the 335 EG and has enumerated the holes he is blocked by and we are waiting for clarifications.
I also meant to add: Within the next few weeks, we expect to announce early access downloads for tech-preview/beta testing. Please wait for an announcement in eclipse-dev and jdt-core-dev Thanks!
Hi, what is the relation between your works and Eclipse available from Oracle site http://www.oracle.com/technetwork/articles/java/lambda-1984522.html? Let me just say that Eclipse version in question (based on Luna - eclipse.buildId=4.4.0.I20130913-1354) does not work very well e.g.: List<Person> people = new ArrayList<>(); people.add(...); // ... people.sort(Comparator.comparing(Person::getLastName)); does not compile saying "The type Person does not define getLastName(T) that is applicable here Main.java Java Problem" The exact same code compiles well with JDK8, as well as works fine under NetBeans. You also wrote "Within the next few weeks, we expect to announce early access downloads". It means that at the moment it is not possible to download any binary Eclipse supporting (early, of course) JDK8 features? Cheers, Przemyslaw
(In reply to Przemyslaw Bielicki from comment #25) > Hi, > > what is the relation between your works and Eclipse available from Oracle > site http://www.oracle.com/technetwork/articles/java/lambda-1984522.html? Both work together on the specs and then do their own implementation. > Let me just say that Eclipse version in question (based on Luna - > eclipse.buildId=4.4.0.I20130913-1354) does not work very well e.g.: ... > The exact same code compiles well with JDK8, as well as works fine under > NetBeans. Luna builds don't contain the Java 8 beta work. The update site which provides the feature patches will be announced no later than next week. > You also wrote "Within the next few weeks, we expect to announce early > access downloads". It means that at the moment it is not possible to > download any binary Eclipse supporting (early, of course) JDK8 features? Not yet, but soon. What you can do is to load the latest code into your IDE as described in wiki.
Hi Dani, thanks for you reply. > Not yet, but soon. What you can do is to load the latest code into your IDE as > described in wiki. I tried but I have lots of compilation errors. Maven build also fails on some unsatisfied dependencies. Anyway I will try to make it work but as it takes a lot of time (I don't have the environment of Eclipse Core developer) I can wait a week for the official build. BTW. Where can I report problems / ask for help regarding building Eclipse JDT? jdt-core-dev? Many thanks, Przemyslaw Bielicki
I've published a complete build at http://downloads.efxclipse.org/eclipse-java8/ but it is about a month old. It does hold lambda stuff, but not the latest bits
Hi Thomas, compilation errors I mentioned in my first comment come from this exact version i.e. 2013-09-13 Any ideas why I'm having these problems? Simple lambda expressions e.g. Runnable task = () -> System.err.println("I'm alive!"); work fine but it fails e.g. on method references (Person::getLastName) Cheers, Przemyslaw
(In reply to Dani Megert from comment #26) > (In reply to Przemyslaw Bielicki from comment #25) > > Hi, > > > > what is the relation between your works and Eclipse available from Oracle > > site http://www.oracle.com/technetwork/articles/java/lambda-1984522.html? > > Both work together on the specs and then do their own implementation. Sorry, I misread your question. My answer was regarding the difference between Oracle's JRE and Eclipse (compiler). I see they offer some Eclipse download on that Oracle page. This is probably just a build based on our beta branch. For more details you would have to ask them. > I tried but I have lots of compilation errors. That should not be the case. Please ask on jdt-core-dev or open a bug if you have compile errors when setting up BETA_JAVA8 as outlined in http://wiki.eclipse.org/JDT_Core/Java8 . Maybe we missed some obvious steps. > Maven build also fails on some unsatisfied dependencies. Since we currently mix 4.3 and 4.4 it mostly likely doesn't build via Maven unless you fix/modify some pom files. You have to wait until we've sorted that out.
(In reply to Dani Megert from comment #30) > (In reply to Dani Megert from comment #26) > > (In reply to Przemyslaw Bielicki from comment #25) > > > Hi, > > > > > > what is the relation between your works and Eclipse available from Oracle > > > site http://www.oracle.com/technetwork/articles/java/lambda-1984522.html? > > > > Both work together on the specs and then do their own implementation. > > Sorry, I misread your question. My answer was regarding the difference > between Oracle's JRE and Eclipse (compiler). I see they offer some Eclipse > download on that Oracle page. This is probably just a build based on our > beta branch. For more details you would have to ask them. They are pointing to my beta builds! Tom
(In reply to Przemyslaw Bielicki from comment #29) > Simple lambda expressions e.g. > > Runnable task = () -> System.err.println("I'm alive!"); > > work fine but it fails e.g. on method references (Person::getLastName) Hello Przemyslaw, As pointed out in comment#23, Overload resolution support and type inference support are not wired in in what is on BETA_JAVA8 branch: Comparator.comparing is a generic method, so your test code is triggering the missing implementation albeit being an elementary piece of code. Work on these features and the different sub-projects thereof are in various stages of evolution in private branches of the committers. We are proceeding on the basis of clarifications we have received for our questions regarding the missing parts and the more complete draft made available to us circa last week of Sep 2013. We expect to refresh the early access binaries once these pieces are cooked and ready to test allowing developers sufficient time to try out the early access versions and report back issues and have them addressed. Thanks for your patience.
Hi Srikanth, thanks a lot for explanations. I must have missed the comment in question. Cheers, Przemyslaw
Announcement of availability of early access builds and request to test can be seen here: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09679.html Status page here: http://wiki.eclipse.org/JDT_Core/Java8 (still needing a few tweaks, but substantially up to date)
(In reply to Thomas Schindl from comment #31) > (In reply to Dani Megert from comment #30) > > (In reply to Dani Megert from comment #26) > > > (In reply to Przemyslaw Bielicki from comment #25) > > > > Hi, > > > > > > > > what is the relation between your works and Eclipse available from Oracle > > > > site http://www.oracle.com/technetwork/articles/java/lambda-1984522.html? > > > > > > Both work together on the specs and then do their own implementation. > > > > Sorry, I misread your question. My answer was regarding the difference > > between Oracle's JRE and Eclipse (compiler). I see they offer some Eclipse > > download on that Oracle page. This is probably just a build based on our > > beta branch. For more details you would have to ask them. > > They are pointing to my beta builds! Tom, could you refresh the bits if you haven't already done so, since these are pointed to by other site, it would be best. I believe the update site we announced in the early access message gets builds and packages the bits every night from the top of BETA_JAVA8 branch. Thanks in advance.
I've now switch the efxclipse nightly build to include the bits from springsource and linked the directory to it => the nightly build of the 4.3.1-SDK will always included the latest bits from BETA8. People following the link from the blog will always get the latest 4.3.1+BETA8+a few other features
(not directly related to this bug) You may want to test the java 8 jdt features in conjunction with a maven project. I've built an update site of m2e for kepler which supports java 8. Please find it here: http://danieldietrich.net/p2/m2e/snapshot/java8/e43/ It is based on a patch (https://bugs.eclipse.org/bugs/show_bug.cgi?id=420848) which will probably go into luna m3.
Would it be possible to merge he Java 8 developments into master so that Luna user can get it out of the box? I think this would also result in more testers.
(In reply to Lars Vogel from comment #38) > Would it be possible to merge he Java 8 developments into master so that > Luna user can get it out of the box? I think this would also result in more > testers. We are not allowed to do that until Java 8 GA's. For JDT/Core master is merged frequently into BETA_JAVA8 branch. The recommended set up for early access users though is 4.3.1 + JDT bundles. This will likely stay the case for the GA in March. Other (platform) components have too many dependencies that they may not be able/want to resolve.
(In reply to Srikanth Sankaran from comment #39) > We are not allowed to do that until Java 8 GA's. Thanks for the info. Is this a JDT project rule? I'm unaware of such a rule by Eclipse.
This is a rule enforced by the JSR - if you make preview builds with this support available your are supposed to REMOVE them once the JSR is released or update them with the implementation of the final JSR spec.
(In reply to Thomas Schindl from comment #41) > This is a rule enforced by the JSR - if you make preview builds with this > support available your are supposed to REMOVE them once the JSR is released > or update them with the implementation of the final JSR spec. Is this a restriction? JDT anyway need to update to the final JSR spec once it is released.
They would have to update and or remove all Milestone builds of the SDK published with the JDK8 support! Milestone builds at Eclipse are guaranteed to not change after having been published.
See also comment#8 from Eclipse PMC member which alludes to legal requirements.
(In reply to Srikanth Sankaran from comment #44) > See also comment#8 from Eclipse PMC member which alludes to legal > requirements. Thanks, the comment from John seems to say that inclusion for Luna is OK. Maybe John could clarify if inclusion of Java 8 support in Luna pre-builds, e.g. milestone builds, is allowed or not. IntelliJ and Netbeans both ship already with Java8 support.
(In reply to Lars Vogel from comment #45) > (In reply to Srikanth Sankaran from comment #44) > > See also comment#8 from Eclipse PMC member which alludes to legal > > requirements. > > Thanks, the comment from John seems to say that inclusion for Luna is OK. > Maybe John could clarify if inclusion of Java 8 support in Luna pre-builds, > e.g. milestone builds, is allowed or not. IntelliJ and Netbeans both ship > already with Java8 support. They don't ship their own compiler but use javac, that's why they can ship it. The problem is that you are not allowed to ship a compiler which produces bytecode of the unreleased Java8 version. Please read the intro at http://cr.openjdk.java.net/~abuckley/8misc.pdf which states what I expressed in none legal language
(In reply to Thomas Schindl from comment #46) > Please read the intro at http://cr.openjdk.java.net/~abuckley/8misc.pdf > which states what I expressed in none legal language You mean this part? -------- The grant set forth above concerning your distribution of implementations of the specification is contingent upon your agreement to terminate development and distribution of your "early draft" implementation as soon as feasible following final completion of the specification. If you fail to do so, the foregoing grant shall be considered null and void. -------- I still think "as soon as feasible" would be in sink with future JDT development.
(In reply to Lars Vogel from comment #47) > I still think "as soon as feasible" would be in sink with future JDT > development. Gentlemen, please hold your horses. Whether it is feasible or not, we have no cycles to do this now - we are working wrap up the remaining features for Java 8 (Early access build II to be posted by Dec 15th with significant improvements in feature coverage over EA I posted 6-7 weeks ago) and this task cannot be scheduled for lack of time anyways !
(In reply to Lars Vogel from comment #45) > Maybe John could clarify if inclusion of Java 8 support in Luna pre-builds, > e.g. milestone builds, is allowed or not. IntelliJ and Netbeans both ship > already with Java8 support. I can only repeat what Srikanth and Tom already said. JDT team will put the work in master as soon they possibly can - both from legal and technical perspective. Meanwhile the feature patches is the best we can do. We can start promoting the feature patch download more widely when we are ready to get more user testing but I don't think lack of user testing is a problem right now.
Hello all, Since the time we announced Early Access Release I on Oct 21th this year, JDT support for Java 8 has grown by leaps and bounds. Here is an heads up that we expect to announce Early Access Release II on Dec 20th 2013 with much more evolved capabilities. I just updated the project wiki with the details of the overall Eclipse + Java 8 release schedule leading up to GA on 18th March: See details here: https://wiki.eclipse.org/JDT_Core/Java8 (This page will be updated again just before EA II to remove stale content)
Early access release II available: Announcement here: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09699.html
Early access release III avaialable. Announcement can be seen here: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09738.html 1.75 line inline summary: Compiler and many other components of the Eclipse SDK are feature complete for Java 8 and 45 beta program starts.
Not sure if this is the right place to point this out (please correct me if not), but the advice at https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_(BETA) about using the batch compiler is not 100% correct in that historically only the ecj.jar versions of the batch compiler supports annotation processing. This still seems to be the case for the org.eclipse.jdt.core_3.9.2.v*_BETA_JAVA8.jar files. As far as I can tell, there is no ecj.jar available for the JDK 8 BETA.
(In reply to Doug Simon from comment #53) > Not sure if this is the right place to point this out (please correct me if > not), but the advice at > https://wiki.eclipse.org/JDT/Eclipse_Java_8_Support_(BETA) about using the > batch compiler is not 100% correct in that historically only the ecj.jar > versions of the batch compiler supports annotation processing. This still Thanks for your interest, Eclipse releng/integration team is on it. Please see https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09744.html Thanks for your patience.
This umbrella ER has served its purpose. JDT/Core and JDT/APT are feature complete for Java 8. There are still several defects open but these can be tracked on their own. I'll document here a few useful links: JDT/Core Java 8 page: http://wiki.eclipse.org/JDT_Core/Java8 (contains schedule) Core/APT tasks in progress and in the reckoning for GA: https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse&component=APT&component=Core&list_id=8172785&product=JDT&query_format=advanced&target_milestone=BETA%20J8 UI/Text work items in progress and in the reckoning for GA: https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse&component=Text&component=UI&list_id=8172791&product=JDT&query_format=advanced&target_milestone=BETA%20J8 I'll post brief updates here of interesting events (release candidates and such) so the subscribers of this bug get updates.
We just announced Release Candidate I here: https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09764.html
(In reply to Srikanth Sankaran from comment #56) > We just announced Release Candidate I here: > https://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09764.html Luna support is still missing, if I get this right. I assume the Eclipse devs currently use only Luna, so if you want more testing, please provide the possibility to integrate into Luna.
This is not true i run all time on luna!
(In reply to Thomas Schindl from comment #58) > This is not true i run all time on luna! Thanks for chiming in Tom. Lars, my understanding is that if you don't use API tooling, the feature patch should work alright on Luna.
To forestall confusion and to allay any concerns, I should also point out that at GA time, Java 8 support will be available on Luna as well as Kepler SR lines.
(In reply to Thomas Schindl from comment #58) > This is not true i run all time on luna! Try using the Api tooling with this patch, my bug report for this was closed as invalid as Luna is not supported.
(In reply to Srikanth Sankaran from comment #59) > (In reply to Thomas Schindl from comment #58) > > This is not true i run all time on luna! > > Thanks for chiming in Tom. > > Lars, my understanding is that if you don't use API tooling, the feature > patch should work alright on Luna. That is a big restriction for Eclipse platform development.
Eclipse + Java 8 RC2 available. Announcement can be seen here: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09770.html
(In reply to Srikanth Sankaran from comment #60) > To forestall confusion and to allay any concerns, I should also point out > that > at GA time, Java 8 support will be available on Luna as well as Kepler SR > lines. I think we should restrict the patch itself to apply to only Kepler SR2 (if we can). I say this after doing some testing with M6 EPP packages and could see the patch "was workings" because it was "down leveling" some bundles. I've opened bug 430339 with more detail.
(In reply to David Williams from comment #64) > (In reply to Srikanth Sankaran from comment #60) > > To forestall confusion and to allay any concerns, I should also point out > > that > > at GA time, Java 8 support will be available on Luna as well as Kepler SR > > lines. > > I think we should restrict the patch itself to apply to only Kepler SR2 (if > we can). I say this after doing some testing with M6 EPP packages and could > see the patch "was workings" because it was "down leveling" some bundles. > I've opened bug 430339 with more detail. To clarify, Java 8 support on Luna will be available via regular I builds, milestone builds, RC builds and GA builds per Luna schedule starting next week at the GA time. The "patch" is applicable only for Kepler SR streams and David is trying to figure out ways to restrict the patch which is really meant for Kepler SR streams from being inadvertently used with Luna. David - does that sum up the situation correctly ?
(In reply to Srikanth Sankaran from comment #65) > (In reply to David Williams from comment #64) > > (In reply to Srikanth Sankaran from comment #60) > > > To forestall confusion and to allay any concerns, I should also point out > > > that > > > at GA time, Java 8 support will be available on Luna as well as Kepler SR > > > lines. > > > > I think we should restrict the patch itself to apply to only Kepler SR2 (if > > we can). I say this after doing some testing with M6 EPP packages and could > > see the patch "was workings" because it was "down leveling" some bundles. > > I've opened bug 430339 with more detail. > > To clarify, Java 8 support on Luna will be available via regular I builds, > milestone builds, RC builds and GA builds per Luna schedule starting next > week at the GA time. > > The "patch" is applicable only for Kepler SR streams and David is trying to > figure out ways to restrict the patch which is really meant for Kepler SR > streams from being inadvertently used with Luna. > > David - does that sum up the situation correctly ? Yes, exactly. Well, a little more exact, is not to say "Kepler SR streams" We'd not, for example, want someone to install it on "SR1" ... again, just for clearer maintenance/bug reporting ... we want it to be "SR2" specifically.
