Re: [Engine-devel] java 1.6 compatibility no more?

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?).

There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both. Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it. Livnat > >>> ----- Original Message ----- >>> From: "Juan Hernandez" <jhernand(a)redhat.com&gt; >>> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>> Cc: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, engine-devel(a)ovirt.org >>> Sent: Thursday, July 19, 2012 11:01:00 AM >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>> >>> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >>>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>>> DNS ,and made one of my patches at gerrit redundant. >>>>> Why not enjoy the bug fixes? >>>> >>>> I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? >>>> >>>> If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. >>>> >>>> Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. >>> >>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >>> >>>> ----- Original Message ----- >>>> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; >>>> To: engine-devel(a)ovirt.org >>>> Sent: Thursday, July 19, 2012 7:59:45 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: >>>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>>>>> In fact, for both backend and frontend, Maven effective POM contains: >>>>>> >>>>>> <artifactId>maven-compiler-plugin</artifactId> >>>>>> <configuration> >>>>>> <source>1.6</source> >>>>>> <target>1.6</target> >>>>>> </configuration> >>>>>> >>>>>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >>>>> >>>>> These maven settings just tell the java compiler to accept Java 6 syntax >>>>> only and to generate a Java 6 compatible .class file format, but they >>>>> don't restrict the set of APIs that can be used. >>>>> >>>>>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>>>>> >>>>>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>>>>> >>>>>> Vojtech >>>> >>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>> DNS ,and made one of my patches at gerrit redundant. >>>> Why not enjoy the bug fixes? >>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Laszlo Hornyak" <lhornyak(a)redhat.com&gt; >>>>>> To: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>> Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt; >>>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>>>>> Subject: java 1.6 compatibility no more? >>>>>> >>>>>> Hi, >>>>>> >>>>>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>>>>> Is this intentional? >>>>>> >>>>>> Laszlo > > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel