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

Sounds reasonable, file a jira/patch?

On Thursday, June 28, 2012, 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
>
>

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/

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

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
>

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

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

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

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

Thanks everybody!  Good to get this resolved.

-andy

On Fri, Jun 29, 2012 at 3:53 PM, Alejandro Abdelnur <[EMAIL PROTECTED]>wrote:

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