----- Original Message -----
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@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
----- Original Message ----- 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@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