Community
Participate
Working Groups
This is required to solve Bug 441116. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=441116#c31
Adding Stephan on CC as we had a discussion about a research project for annotating UI libraries for UI thread safeness and etc. Type annotation would enhance the possibilities for such work and open the door for work to really start but I'll Stephan explain details. This is another request so probably it's time to update to Java 8.
Sorry for the delay, meanwhile I've file bug 482891 describing the proposed enhancement. In a nutshell: - by specifying SWT's thread contracts using annotations we can enable a compiler to detect "Illegal Thread Access" already at compile time. - for the full power of that approach Java 8-style type annotations are required I've marked this current bug as blocking that proposal.
Lakshmi, Arun, I think Stephan's reasoning is sound enough to justify moving to Java 8. We should open the ground for such work if it is blocked by the BREE now. What I like about these annotation work is that it can be delivered and enhanced over time and don't have to be delivered at once.
I'm not in favor of moving to Java 8 for Neon.
(In reply to Dani Megert from comment #4) > I'm not in favor of moving to Java 8 for Neon. Can you also give your reasons?
(In reply to Alexander Kurtakov from comment #3) > Lakshmi, Arun, I think Stephan's reasoning is sound enough to justify moving > to Java 8. The most often root cause of issues in the UI related spaghetti code dealing with jobs and UI tasks is the problem for API consumers to understand on which thread they are supposed to do things. Having set of (RetentionPolicy.CLASS) annotations on the SWT/JFace API would be awesome not only for human consumers of the API's but also for the static code analyzers. So yes, a big +1 from me as consumer of that APIs. (In reply to Dani Megert from comment #4) > I'm not in favor of moving to Java 8 for Neon. Why?
Note that SWT has a very healthy adoption rate as a stand-alone widget toolkit outside of Eclipse IDE/RCP. Often we have kept the EE for SWT lower than everything else in order to support those consumers. I don't think Java 7 is dead yet in the user application community and I'm sure there will be an impact for users here. For example our AERI statistics show about 25% of Eclipse users are still on Java 7, and I expect it would be similar for other Java applications built with SWT. I realized Oracle no longer provides free public updates of Java 7 but that does not imply it is unused.
John, do I read it correct that this would be too big of a jump at once? E.g. SWT currently at 1.5 so we start bumping it to 1.6 or 1.7 for Neon first?
(In reply to Alexander Kurtakov from comment #8) > E.g. SWT currently at 1.5 so we start bumping it to 1.6 or 1.7 for Neon > first? Only if there is a very good reason why it has to be increased at all. Yes, I saw the one in comment 0 for Java 8, but that jump is really too big. We already had quite a lot of negative comments regarding the move to Java 8 for the IDE.
(In reply to Dani Megert from comment #9) > (In reply to Alexander Kurtakov from comment #8) > > E.g. SWT currently at 1.5 so we start bumping it to 1.6 or 1.7 for Neon > > first? > > Only if there is a very good reason why it has to be increased at all. Yes, > I saw the one in comment 0 for Java 8, but that jump is really too big. We > already had quite a lot of negative comments regarding the move to Java 8 > for the IDE. This is what I try to clarify - if jumping to Java 8 is too big jump at once and at the same time moving to 1.6/1.7 gives us nothing - we have chicken and egg problem. At one point we should either make big jump at once or start making incremental jumps with no sound reasoning so we can get to the point where a jump would not be too big.
(In reply to Stephan Herrmann from comment #2) > - for the full power of that approach Java 8-style type annotations are > required Stephan, as you are the original requester of bug 482891, can you please answer to the next few questions: Are the use of Java 8-style type annotations for bug 482891 really require SWT compile settings to be changed to Java 8? Is it only because compiler must allow those annotations to appear on local variables/type arguments? Or do you plan to put the annotation type definitions itself into SWT (I don't think this would be a good idea, external annotations project would be better)? I don't think that SWT / JFace use generics a lot, so most likely we want just annotate types, fields and methods only - and for this Java 5 level should be enough. If not - how much impact would limiting us to "pre-Java 8" annotations have on the planned features in bug 482891? (In reply to Alexander Kurtakov from comment #10) > (In reply to Dani Megert from comment #9) > > (In reply to Alexander Kurtakov from comment #8) > > > E.g. SWT currently at 1.5 so we start bumping it to 1.6 or 1.7 for Neon > > > first? +1, see below > > Only if there is a very good reason why it has to be increased at all. Yes, > > I saw the one in comment 0 for Java 8, but that jump is really too big. We > > already had quite a lot of negative comments regarding the move to Java 8 > > for the IDE. > > This is what I try to clarify - if jumping to Java 8 is too big jump at once > and at the same time moving to 1.6/1.7 gives us nothing - we have chicken > and egg problem. I think if Stephan can live with 1.5 level annotations, we don't even need to bump SWT to 1.8. However we should *at least* bump it to 1.7 for Neon with the publicly declared goal to be on 1.8 for the next release.
(In reply to Dani Megert from comment #9) > We already had quite a lot of negative comments regarding the move to Java 8 > for the IDE. Where did you see that negative feedback? I know where was a discussion before the decision to move to Java 8. But, to my surprise, your announcement of that decision on cross was followed by a silence on the relevant mailing lists. Several of our customers on the other hand were very happy about this decision, they took since as sign that "Eclipse is not in maintenance mode".
(In reply to Lars Vogel from comment #12) > (In reply to Dani Megert from comment #9) > > We already had quite a lot of negative comments regarding the move to Java 8 > > for the IDE. > > Where did you see that negative feedback? Mailing lists. > Several of our customers on the other hand were very happy about this > decision, they took since as sign that "Eclipse is not in maintenance mode". Then they do not understand what the JRE level means, and, they are probably not big corporate companies ;-).
Independent of whatever Java version you choose update to Java 8 also requires additional (functional) interfaces in controls to leverage the full power of lamda expressions. For instance I can not use lambdas as replacement for focus listeners since there are 2 method definitions in it: public interface FocusListener extends SWTEventListener { public void focusGained(FocusEvent e); public void focusLost(FocusEvent e); } With two additional interfaces as follows everything was fine and wouldn't even break the API: public interface FocusGainedListener extends SWTEventListener { public void focusGained(FocusEvent e); } public interface FocusLostListener extends SWTEventListener { public void focusLost(FocusEvent e); } And of course there are many more use cases where lambda expressions would be useful.
Only to allow API users to use lambas one does not need to switch the code base to java8 and btw there is already addListener(type ,listener) which is a functional interface! IMHO SWT API needs an overhaul but first one needs to create a vision where it should go, adding stuff here and there results in an inconsistent API
(In reply to Thomas Schindl from comment #15) > Only to allow API users to use lambas one does not need to switch the code > base to java8 and btw there is already addListener(type ,listener) which is > a functional interface! > > IMHO SWT API needs an overhaul but first one needs to create a vision where > it should go, adding stuff here and there results in an inconsistent API I don't want to switch the code base to java8 and the addListener method is too generic (downcast event object). But yes I agree SWT needs a clear future vision.
IIRC the decision was to move SWT to Java 1.7 for Eclipse 4.6 and to Java 8 for Eclipse 4.7. If that is correct (Dani please correct me, if necessary), we should update SWT early so that the SWT team can start offering Java 8 API during the 4.7 release cycle.
New Gerrit change created: https://git.eclipse.org/r/75240
(In reply to Lars Vogel from comment #17) > If that is correct (Dani please correct me, if necessary), we should update > SWT early so that the SWT team can start offering Java 8 API during the 4.7 > release cycle. Please see https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes
Created attachment 262607 [details] Child eclipse with SWT on Java 8 Child eclipse works well with SWT in java 8.
(In reply to comment #12) > (In reply to Dani Megert from comment #9) > > We already had quite a lot of negative comments regarding the move to Java 8 > > for the IDE. > > Where did you see that negative feedback? I know where was a discussion before > the decision to move to Java 8. But, to my surprise, your announcement of that > decision on cross was followed by a silence on the relevant mailing lists. > > Several of our customers on the other hand were very happy about this decision, > they took since as sign that "Eclipse is not in maintenance mode". I agree, I think moving SWT to Java 8 (for Oxygen?) will give it a more modern feel. A lot of people think that Eclipse is old and slow to move.
(In reply to Leo Ufimtsev from comment #21) > I agree, I think moving SWT to Java 8 (for Oxygen?) will give it a more > modern feel. A lot of people think that Eclipse is old and slow to move. Update to Java 8 is planned but Lakshmi said that they need to install Java 8 on local Hudson instance. See https://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg07936.html
AFAIK this hudson machine is not running tests so I might update tests, tools already updated as definetely not needed on non dev machines. Lakshmi/Arun please confirm.
Lakshmi/Arun, I plan to update tests to Java 8 is there a reason to hold on? AFAIK tests are not compiled/run on your builders so shouldn't be an issue.
(In reply to Alexander Kurtakov from comment #24) > Lakshmi/Arun, I plan to update tests to Java 8 is there a reason to hold on? > AFAIK tests are not compiled/run on your builders so shouldn't be an issue. Hi Alex, IIRC we do compile tests along with the SWT source mainly to check for compile errors but I don't see a problem with moving tests to Java 8 now, I've already updated the SWT Hudson instance with Java 8. As for updating the SWT project itself, I would prefer to do it once we have a good I-build, the current build still has too many comparator errors which need to be resolved and that makes it difficult to track possible errors that could happen in other projects because of updating SWT to Java 8. I know the chances of that happening are low but I think the possibility is there... WDYT?
Fine with me. I'll push for tests only for now.
New Gerrit change created: https://git.eclipse.org/r/76879
Gerrit change https://git.eclipse.org/r/76879 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=19f86cc43702bc82e3e79202feb740e2dea678dd
It would be nice to have this change for M1. I looked at the comparator logs and they look odd to me. http://download.eclipse.org/eclipse/downloads/drops4/I20160705-1600/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt
(In reply to Alexander Kurtakov from comment #29) > It would be nice to have this change for M1. I looked at the comparator logs > and they look odd to me. > http://download.eclipse.org/eclipse/downloads/drops4/I20160705-1600/ > buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt Yes, I guess there is some issue with the comparator mechanism itself and I'm not sure if it is already fixed or not. I don't think we should wait for that anymore, will go ahead and release the changes before today's I-build.
Gerrit change https://git.eclipse.org/r/75240 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ce5c183d4a069363d852b4b2abceb8a9dc2e3601
New Gerrit change created: https://git.eclipse.org/r/77149
Gerrit change https://git.eclipse.org/r/77149 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=465b1cdc59ad614023d2f03f6ef2e1963399711e
I would like to enable save action to convert to lambdas and do the conversion at ones to not hijack later commits if no one objects. SWT Tools as of tonight build Reason for that being smaller size and slightly faster code - as small as this is doing it at low level as SWT (where every bit count) is important.
(In reply to Alexander Kurtakov from comment #34) > I would like to enable save action to convert to lambdas and do the > conversion at ones to not hijack later commits if no one objects. SWT Tools > as of tonight build Reason for that being smaller size and slightly faster > code - as small as this is doing it at low level as SWT (where every bit > count) is important. +1 but I suggest to mark this bug as fixed and open a new bug for the lambda conversion.
No objection to the lambda proposal. Proceeding with it via separate bug and resolving this one.
For the record - lambda conversion is bug 497962 .
