[Engine-devel] java 1.6 compatibility no more?

Mon Jul 23 09:46:30 UTC 2012

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: "Livnat Peer" <lpeer at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Michael
> Kublin" <mkublin at 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" <iheim at redhat.com>
> >> To: "Allon Mureinik" <amureini at redhat.com>
> >> Cc: "Livnat Peer" <lpeer at redhat.com>, "Juan Hernandez"
> >> <jhernand at redhat.com>, engine-devel at ovirt.org, "Michael
> >> Kublin" <mkublin at 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" <lpeer at redhat.com>
> >>>> To: "Itamar Heim" <iheim at redhat.com>, "Michael Kublin"
> >>>> <mkublin at redhat.com>
> >>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
> >>>> engine-devel at 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 at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> >>
> >>
> 
> 
> 