[Engine-devel] java 1.6 compatibility no more?

[Ayal Baron]

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


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