[Engine-devel] java 1.6 compatibility no more?

[Itamar Heim]

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.

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