----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Allon Mureinik" <amureini(a)redhat.com>
Cc: "Livnat Peer" <lpeer(a)redhat.com>, "Juan Hernandez"
<jhernand(a)redhat.com>, engine-devel(a)ovirt.org, "Michael
Kublin" <mkublin(a)redhat.com>
Sent: Monday, July 23, 2012 8:43:02 AM
Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Allon Mureinik" <amureini(a)redhat.com>
>> Cc: "Livnat Peer" <lpeer(a)redhat.com>, "Juan
Hernandez"
>> <jhernand(a)redhat.com>, engine-devel(a)ovirt.org, "Michael
>> Kublin" <mkublin(a)redhat.com>
>> Sent: Sunday, July 22, 2012 7:41:00 PM
>> Subject: Re: [Engine-devel] java 1.6 compatibility no more?
>>
>> 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.
>
> I don't understand this suggestion.
> What you're saying is that you can compile with whatever JDK you
> want, but:
> - it won't compile with JDKs prior to 6, since we're using 6's
> features.
> - you aren't allowed to use JDK 7 features, and if you do, you'll
> get an email from jenkins that you broke something and must fix
> it.
>
> To me, this sounds a lot like enforcing JDK 6 compatibility.
>
its preserving jdk 6 compatibility for a few more months, not
enforcing
to use jdk 6 compiler.
Fair enough.
> /today/ if have way too many (i.e., >0) jenkins breaks, a lot of
> which could be avoided by not running with -DskipTetst or making
> sure to run with -Penable-dao-tests.
> I fear this suggestion will just add to this "noise", and could
> easily be avoided.
jenkins breaks should be visible at patch level prior to commit,
something we are trying to resolve by adding more hardware to allow
running the various tests at patch level rather than post commit
only.
I agree that this is an excellent goal, but I maintain that this is an
uncomfortable way to work.
I would still like a way to check, on my own machine, as part of my compilation process,
that I'm not doing anything I shouldn't.
Here's my second take on the issue, using Animal Sniffer
(
http://mojo.codehaus.org/animal-sniffer/):
http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
>
>>
>>>
>>> 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
>>>>
>>
>>
>>