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

----- Original Message ----- > 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. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility.

/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.

> >> >> 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 >>> > > >