Community
Participate
Working Groups
Java 5 generics can be added to the p2 code base while still retaining full backward compatibility with Java 1.4. See: http://wiki.eclipse.org/Equinox_p2_down_compilation. This addition would be a great API enhancement and in some cases also vouch for better resource utilization (one example is to make the IInstallableUnit fully immutable without returning copies of it's contained arrays).
I've done a lot of work on this already and I expect to have something finished before the December 28. Until then, I would appreciate if you could hold off major commits until then. Adding generics involves touching a lot of files. I will set a tag 'before_generics' on all involved projects prior to check-in.
(In reply to comment #1) > I've done a lot of work on this already and I expect to have something finished > before the December 28. Until then, I would appreciate if you could hold off > major commits until then. Adding generics involves touching a lot of files. I was looking for a good reason to actually stop working over holiday, and now you've given it to me! ;-) Looking forward to the changes, have a great holiday!
I have made the first major commit. In this commit I concentrated on: 1. Fixing all API's - Returning typed collections instead of arrays in many places - Using typed queryables, queries, and repositories - Using Map<String,String> instead of the more expensive Properties 2. Changing meta-data - Adding javacTarget=jsr14 and javacSource=1.5 to build.properties - Adding the J2SE-1.5 3. Fixing most of the core bundles in p2 - Adding generics to the code, getting rid of warnings - Simplifying some constructs (check for types when already typed) So far, I have not changed any for(...) constructs although I would very much like to. The reason I haven't is that I'm uncertain still if it will really work in all cases. Normally, if I replace the following: for(Iterator<String> iter = stringList.iterator(); iter.hasNext();) { String str = iter.next(); ... } with: for(String str : stringList) { ... } the compiler will use the fact that 'stringList' implements the Iterable interface. This interface is not present in Java 1.4 so unless the compiler does something very special for these cases, we cannot do this. At least not yet. There will be more changes coming over the next couple of days but they will not be major. So you should no longer feel blocked by my generics effort. I didn't change all bundles just yet. These remain: o.e.e.p2.afterthefact o.e.e.p2.artifact.optimizers o.e.e.p2.artifact.processors o.e.e.p2.examples.* o.e.e.p2.examplarysetup o.e.e.p2.garbagecollector o.e.e.p2.installer o.e.e.p2.jarprocessor o.e.e.p2.operations o.e.e.p2.profile.recovery o.e.e.p2.reconciler.dropins o.e.e.p2.sar o.e.e.p2.tests.optimizers o.e.e.p2.tests.verifier o.e.e.p2.ui.admin.rpc o.e.e.p2.ui.sdk o.e.e.p2.ui.sdk.scheduler o.e.e.p2.updatechecker o.e.e.p2.weblistener If you know that any of them has API, please let me know and I'll fix them next.
I did some tests with the enhanced for loops. And it works. I found this: bug 107783, comment 5, which seems to verify that it will indeed work just fine. Since this makes a lot of the code much easier to read, I'll make this change as well.
Simplified loops are now committed. Unfortunately, we cannot use the simplification on IQueryResults since it doesn't inherit Iterable. Even if this would be OK in the 1.4 world (since the iterator() method is present), the 1.5 compiler does not allow it. So it's a catch 22. Some more bundles were genericirized: o.e.e.p2.garbagecollector o.e.e.p2.installer o.e.e.p2.operations
Thank you for this work. It is great. A few questions: - Is there any particular reason why you chose to use List instead of Collection as a return type for IIU.getRequirements? - It is not required to add 1.5 as part of the BREE since 1.4 is a subset of 1.5. It is possible to use the enhanced for loop: for(String str : stringList), because Iterable is only used by the compiler to look for an iterator method. The Iterable type is not referenced in the generated byte code. However we can not make our query results iterable because this would force a dependency on 1.5.
(In reply to comment #6) > Thank you for this work. It is great. > A few questions: > - Is there any particular reason why you chose to use List instead of > Collection as a return type for IIU.getRequirements? It made the impact smaller on the existing code that used arrays (with indexed for loops). I can change this to Collection if you think that's better. The sooner the better in that case. > - It is not required to add 1.5 as part of the BREE since 1.4 is a subset of > 1.5. > The http://wiki.eclipse.org/Equinox_p2_down_compilation suggested that this should be done. It also made it easier to update the class path and retain it's conformance with the EE.
I will be taking care of adding Collection instead of List
Thomas, This is probably just my lack of understanding, but what happens when we list multiple BREEs in a manifest? Bundle-RequiredExecutionEnvironment: J2SE-1.5, J2SE-1.4, CDC-1.1/Foundation-1.1 Does this mean that the bundle requires a VM that satisfies all these constraints (i.e. a 1.5 vm) or one that satisfies any of these constraints (a CDC-1.1/Foundation-1.1 VM for example)?
(In reply to comment #9) > Does this mean that the bundle requires a VM that satisfies all these > constraints (i.e. a 1.5 vm) or one that satisfies any of these constraints (a > CDC-1.1/Foundation-1.1 VM for example)? The latter.
I think we are done.
