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

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

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 >