#958 Exception for updating ecj across major version boundary in f17
Closed None Opened 11 years ago by jvanalte.

= phenomenon =

ecj should be updated in stable f17 release from 3.4 to upstream current 4.2 release stream.

= reason =

The Java programming language had a new version (7) and if users want to use ecj to compile java source files containing 7-specific features they currently cannot. This includes indirect use of ecj, such as via gcj or tomcat. Newer versions of ecj do support Java 7. There is still a lot of time before f17 goes EOL, so users can benefit from this change. The only jdk distributed as part of Fedora is openjdk7 so it only makes sense for other java tools such as this to also support the current language standard.

= recommendation =

From what I can tell, the main potential reason for disallowing this change would be a technicality: not wishing to see the "major" version number change during a stable release. There is backwards compatibility (in fact, extra arguments are required in order to enable the support for java7 features). As part of eclipse project upstream I believe it to be well-tested. So there is very little chance of any negative user experiences (while there is good chance of negative experience if this is not updated). Finally, eclipse itself has updated to the 4.X stream.

I must confess, I had at first considered this justified under the "interoperability" exception class (interoperable with the rest of java dev tools). Before creating update I did take one more read over policy and see that it is pretty specific about networking or hardware interop which this is not. But, at that point I had already done a build which I now realize I should not have. Sorry!


I was told by sochotni from Java SIG it should be fine, but:

1/ leave it for few weeks in rawhide

2/ check if dependencies of your packages can be still build (eg. jboss, tomcat).

Does this package update change the 'user experence' of people using it? Ie, change the interface, etc?

Does this package update require rebuilding or modifying any packages that used it to build against?

Replying to [comment:2 kevin]:

Does this package update change the 'user experence' of people using it? Ie, change the interface, etc?

Does this package update require rebuilding or modifying any packages that used it to build against?

Sorry about delayed response, some higher priority things came up.

I don't believe users currently using ecj need to change anything. I'm not aware of changes to command line flags, etc. The flags for java source version accept additional arguments pertaining to Java7, so users have the additional option of compiling Java7 code. Existing packages building against it should not require change or rebuild, unless they are already getting an update that uses Java7 features (in which case they need this updated ecj to succeed). Rebuilding an otherwise unchanged package should not be required.

However, I have had feedback from kdaniel of a strange problem in some tycho build which uses reflection to check some things before running ecj. I will try to have this sorted before tomorrow's meeting.

FESco agreed on today's meeting that the ecj update is acceptable for F17.

Login to comment on this ticket.

Metadata