Community
Participate
Working Groups
Platform has moved to Java 1.5. Can we move JFace also to 1.5? That would allow for example to extend JFace Viewer with Generics.
(In reply to comment #0) > Platform has moved to Java 1.5. Can we move JFace also to 1.5? Just to clarify here: none of the 1.5 platform stuff is required by JFace, so that they moved up is not a good reason by itself.
We would need a more concrete usecase of where you'd be applying 1.5 language constructs. PW
I can think of plenty of examples where this would be very useful: IStructuredSelection, content and label providers, the viewer classes, etc. Lars are you interested in working in this area or do you know someone who wants to work on this?
I would love to work on this. I plan to suggest this as GSoC project and if possible mentor it. What would be a good setup for working on this? Github?
(In reply to comment #4) > I would love to work on this. I plan to suggest this as GSoC project and if > possible mentor it. > > What would be a good setup for working on this? Github? I'd prefer Gerrit over GitHub.
@Dani: platform is already using Gerrit?
No, but we can request to set that up if we use the same pattern as JDT/Core or Platform/UA PW
Btw, we can easily do both, work against a Github repo and push to Gerrit.
I opened Bug 402445 for the generic support in JFace Viewers.
As part of my Google Summer of Code Project (mentored by Lars Vogel) I'm trying to to bring generics support to the JFace Viewers. As initial action I've commited a patch to the gerrit system with adjustments in the MANIFEST.MF and .classpath files. https://git.eclipse.org/r/#/c/13664/ So if your interested, please review the changes.
This was applied this afternoon, apparently, though there's no note to that effect here, and caused bug 411321. Be sure to test local builds with -Pbree-libs.
(In reply to comment #11) > This was applied this afternoon, apparently, though there's no note to that > effect here, and caused bug 411321. > > Be sure to test local builds with -Pbree-libs. Well, I take this back ... sort of (its always a good idea :) ... but the actual bug 411321 occurs while running pom-version-updater.sh ... which is not part of doing a "local build".
As David noted, the pom.xml is not correct. There are other issues with the merged change: - the compliance was not updated (still 1.4) - the bundle version was not updated for Luna Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9ad2c79bfaa360f1fe848cb905886c72551dd67c
The next step is now to fix all the new compile warnings regarding type safety and raw types (around 1000). Not sure whether bug 402445 is meant to fix those.
And when changing the compiler compliance, you always have to make a pass over the Errors/Warnings page to make sure the settings make sense for the new language level. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=60778334e8a8c485df7d0c7cd301a6ff827bd9d9
(In reply to comment #15) > And when changing the compiler compliance, you always have to make a pass > over the Errors/Warnings page Ideally, this would happen when changing the compliance.
John, what's your plan with this? The JFace project can't stay with hundreds of compile warnings, and I don't think it makes sense to let an external contributor generify the project. Reviewing all the necessary changes takes a committer longer than doing most of the fixes himself. See http://wiki.eclipse.org/Generify_A_Java_Project .
Should we open a new bug for the warnings? I talked to Hendrik (GSoC project) and the plan was to provide Gerrit patches for generifing the project. Please let us know if that is not desired.
(In reply to comment #17) > John, what's your plan with this? > > The JFace project can't stay with hundreds of compile warnings, and I don't > think it makes sense to let an external contributor generify the project. > Reviewing all the necessary changes takes a committer longer than doing most > of the fixes himself. See http://wiki.eclipse.org/Generify_A_Java_Project . This is an accepted GSOC project that Hendrick will be working on over the summer. This bug was just the first step of enabling use of generics but more work is coming. Some pointers for more details: http://blog.vogella.com/2013/06/17/google-summer-of-code-at-eclipse-2/ http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/hendrik_still/1 https://wiki.eclipse.org/Eclipse_Platform:_Implementing_generic_in_JFace_viewers And yes, reviewing contributed changes is often more work than just doing the work yourself, but it is an investment in helping someone get started working in open source and potentially growing new long term contributors. For the compile warnings, I don't mind if we leave the warnings on while Hendrick, Lars, and others work to reduce them over the next couple of months. If it is preferred we could set the compile warnings in the official build to ignore them, but leave them enabled in the project settings. That way the build looks clean but people working on the code are reminded that they need fixing.
This bug is fixed. Further discussions (e.g. ignore warnings) should happen in a new bug.
Sorry for the inconvenience my first commit have caused. I opened a new bug for further discussions. https://bugs.eclipse.org/bugs/show_bug.cgi?id=411383
