Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS, mail # dev - Hadoop-2 generics compilation error


Copy link to this message
-
Re: Hadoop-2 generics compilation error
Alejandro Abdelnur 2012-06-29, 22:53
yep, just tested with sunjdk, and it works. We still have the
unboxing, but is done when the variable is used as parameter in method
that is expecting a primitive type.

On Fri, Jun 29, 2012 at 3:49 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> SunJDK will correctly infer the reference types, correct?
> If so, changing this to reference types should make both JDKs happy.
>
> -- Lars
>
> ________________________________
> From: Alejandro Abdelnur <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Friday, June 29, 2012 3:26 PM
> Subject: Re: Hadoop-2 generics compilation error
>
> Andy,
>
> It looks like OpenJDK javac does not handle type unboxing with a
> generic method where the parameter that resolves the generic infers
> the type to do the un-boxing on. While SunJDK does handle it.
>
> Now, to the question which one is correct? I'm not sure but SunJDK
> does a valid inference.
>
> thx
>
> On Fri, Jun 29, 2012 at 2:43 PM, Andy Isaacson <[EMAIL PROTECTED]> wrote:
>> I've filed https://issues.apache.org/jira/browse/HDFS-3580 and attached the
>> patch.
>>
>> I'd really appreciate it if someone could explain what the problem is, why
>> the patch fixes it, and whether this is a bug in OpenJDK (that it does not
>> accept a valid program) or a bug in Sun JDK (that it does accept an
>> incorrect program).
>>
>> -andy
>>
>> On Fri, Jun 29, 2012 at 12:01 PM, Andy Isaacson <[EMAIL PROTECTED]> wrote:
>>
>>> I ran into this as well, and am prepping a patch. Lars, if you could file
>>> the Jira explaining why s/boolean/Boolean/ is the right fix, I'll test and
>>> submit the patch.
>>>
>>> -andy
>>>
>>>
>>> On Fri, Jun 29, 2012 at 11:08 AM, Alejandro Abdelnur <[EMAIL PROTECTED]>wrote:
>>>
>>>> This change is from HDFS-3481, the wrong JIRA number is because I made
>>>> a mistake in the commit message.
>>>>
>>>> I can put a patch to fix this, but don't have OpenJDK to test it. It
>>>> would be better if somebody with OpenJDK takes care of it and I'll
>>>> review it.
>>>>
>>>> Thx
>>>>
>>>> On Fri, Jun 29, 2012 at 11:01 AM, Arun C Murthy <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > HDFS-3113 is committed? Or, are you running with the patch yourself?
>>>> >
>>>> > It's still PA and I see Daryn reviewing it yet...
>>>> >
>>>> > Arun
>>>> >
>>>> > On Jun 28, 2012, at 10:27 PM, lars hofhansl wrote:
>>>> >
>>>> >> Since HDFS-3113 was integrated into Hadoop-2 I get the compilation
>>>> errors of the following type:
>>>> >>
>>>> >> [ERROR]
>>>> /home/lars/dev/hadoop-2/hadoop-hdfs-project/hadoop-hdfs-httpfs/src/main/java/org/apache/hadoop/fs/http/server/HttpFSServer.java:[407,36]
>>>> incompatible types; no instance(s) of type variable(s) V exist so that V
>>>> conforms to boolean
>>>> >>
>>>> >>
>>>> >> Indeed at line 407 I see:
>>>> >>
>>>> >>         boolean hasData = params.get(DataParam.NAME, DataParam.class);
>>>> >>
>>>> >>
>>>> >> When I change that to
>>>> >>         Boolean hasData = params.get(DataParam.NAME, DataParam.class);
>>>> >>
>>>> >>
>>>> >> instead (along with long to Long, short to Short, etc, later in that
>>>> file), everything compiles fine.
>>>> >>
>>>> >> $ javac -version
>>>> >> javac 1.6.0_24
>>>> >>
>>>> >>
>>>> >> $ java -version
>>>> >> java version "1.6.0_24"
>>>> >> OpenJDK Runtime Environment (IcedTea6 1.11.3)
>>>> (fedora-67.1.11.3.fc16-x86_64)
>>>> >> OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
>>>> >>
>>>> >> Apparently OpenJDK gets mixed up on the type inference here. Can we
>>>> change this in the way I suggest so that Hadoop-2 (and presumably trunk)
>>>> can be
>>>> >> compiled with OpenJDK?
>>>> >> I'm happy to create a jira and (trivial) patch.
>>>> >>
>>>> >>
>>>> >> Thanks.
>>>> >>
>>>> >> -- Lars
>>>> >>
>>>> >
>>>> > --
>>>> > Arun C. Murthy
>>>> > Hortonworks Inc.
>>>> > http://hortonworks.com/
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Alejandro
>>>>
>>>
>>>
>
>
>
> --
> Alejandro

--
Alejandro