[Engine-devel] java 1.6 compatibility no more?

Allon Mureinik amureini at redhat.com
Mon Jul 23 05:21:36 UTC 2012



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Allon Mureinik" <amureini at redhat.com>
> Sent: Sunday, July 22, 2012 8:34:32 PM
> Subject: Re: [Engine-devel] java 1.6 compatibility no more?
> 
> 
> 
> ----- Original Message -----
> > 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.
> > 
> 
> Instead of enforcing the compilation to be run with a specific jdk we
> can enforce that the code is java 6 compatible with:
> 
> <plugin>
>     <groupId>org.apache.maven.plugins</groupId>
>     <artifactId>maven-compiler-plugin</artifactId>
>     <version>2.0.2</version>
>     <configuration>
>         <source>1.6</source>
>         <target>1.6</target>
>     </configuration>
> </plugin>

No, this is not the issue we're discussing.
The source and target configurations in the maven-compiler-plugin specify the language level compatibility (i.e., syntax) you're using.
This setting only means you won't be able to use Java 7 new syntactic constructs like catching multiple exceptions with the pipe operator and shorthand generics.
This has nothing to do with the JDK.
The JDK is just a collection of jars, like any other jar, which just happen to contain some fundamental classes like Object, String and Long.
Our case here is to force developers not use any methods/classes that aren't present in /JDK 6/.

Just to prove the point - if you take a look at lines 367-368 of the master pom.xml, 
you'll notice we already have these settings, and have had them since oVirt's git repo was created.

> 
> 
> > >
> > > 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
> > >>
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 



More information about the Engine-devel mailing list