12:21 a.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "Juan Hernandez" <jhernand(a)redhat.com>, engine-devel(a)ovirt.org,
"Allon Mureinik" <amureini(a)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(a)redhat.com>
> >> To: "Itamar Heim" <iheim(a)redhat.com>, "Michael
Kublin"
> >> <mkublin(a)redhat.com>
> >> Cc: "Juan Hernandez" <jhernand(a)redhat.com>,
> >> engine-devel(a)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(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>