----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Allon Mureinik" <amure...@redhat.com> > Cc: "Livnat Peer" <lp...@redhat.com>, "Juan Hernandez" <jhern...@redhat.com>, > engine-devel@ovirt.org, "Michael > Kublin" <mkub...@redhat.com> > 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" <lp...@redhat.com> > >> To: "Itamar Heim" <ih...@redhat.com>, "Michael Kublin" > >> <mkub...@redhat.com> > >> Cc: "Juan Hernandez" <jhern...@redhat.com>, engine-devel@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@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel