Re: [Engine-devel] java 1.6 compatibility no more?

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Allon Mureinik" <amureini(a)redhat.com&gt; Cc: "Livnat Peer" <lpeer(a)redhat.com&gt;, "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, "Michael Kublin" <mkublin(a)redhat.com&gt; Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" <lpeer(a)redhat.com&gt; >> To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Michael Kublin" >> <mkublin(a)redhat.com&gt; >> Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org >> Sent: Sunday, July 22, 2012 9:50:47 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 21/07/12 15:15, Itamar Heim wrote: >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>> >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>> syntax >>>>>>>>>> in >>>>>>>>>> GWT code? >>>>>>>>> >>>>>>>>> That's a very good point. >>>>>>>>> >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note that >>>>>>>>> there >>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>> reason, >>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>> someone >>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>> >>>>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>>>> and >>>>>>>>> any >>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>> referenced >>>>>>>>> by >>>>>>>>> frontend code. This shouldn't affect the backend, however. >>>>>>>>> >>>>>>>>> We could do something like this: >>>>>>>>> >>>>>>>>> - let oVirt root POM declare source and target compliance >>>>>>>>> to >>>>>>>>> Java 7 >>>>>>>>> - let frontend modules POM >>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>> >>>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Vojtech >>>>>>>> >>>>>>>> +1 - I really like this idea! >>>>>>> >>>>>>> +1 from me as well. >>>>>> >>>>>> >>>>>> There are two calls to make when it comes to JDK7 (regardless >>>>>> of >>>>>> GWT - >>>>>> excuse me for taking this discussion some steps backwards) >>>>>> >>>>>> 1. Are we running with JRE 7? >>>>>> The answer is yes we agreed on that a few months ago. >>>>>> >>>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>>> >>>>>> I think the answer to the above should be no (at least for now >>>>>> - >>>>>> maybe >>>>>> until the next ovirt release?). >>>>> +1 >>>>> exactly. Why starting with jdk6 incompatible constructs unless >>>>> there >>>>> is a good (or at least any) reason for them… >>>> >>>> +1 >>> >>> +1 - there is merit keeping backward compatibility to allow >>> comparing >>> behavior while java 7 is still young. >> >> Since no one objected, we'll go with JDK6 syntax compatibility for >> Now. > I'm a very small fan of enforcing policy by reviewers. > Not that the community reviews aren't great - but people miss > things. > > Here's my take on Maven's enforcer plugin to actually verify we > aren't compiling with JDK 7: > http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.

> > comments welcome. > >> >> Kublin - can you please send a patch to remove the usage of >> Long.Compare >> in StorageDomainCommandBase >> >> Thanks, Livnat >> >> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >>