----- 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: Monday, July 23, 2012 8:43:02 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/23/2012 08:29 AM, Allon Mureinik wrote: > > > > > > ----- 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. > > > > its preserving jdk 6 compatibility for a few more months, not > enforcing > to use jdk 6 compiler. Fair enough.
> > > /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. > > jenkins breaks should be visible at patch level prior to commit, > something we are trying to resolve by adding more hardware to allow > running the various tests at patch level rather than post commit > only. I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540 Again, comments welcome. > > > > >> > >>> > >>> 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