[Engine-devel] java 1.6 compatibility no more?

[Itamar Heim]

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.