You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/21 08:48:30 UTC
[classlib] Help wanted!
I was looking at building (and testing) with Eclipse + IBM VME. I think
this is really important since ecj has a much cleaner classpath when it
compiles so it helps us find errors quicker.
The logs come out at over 3MB! There are lots of warnings about less
than ideal type checking - mostly as a result of our adoption of more
generics. For example:
[javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac] (at line 44)
[javac] relations.add(relation);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^
[javac] Type safety: The method add(Object) belongs to the raw type Vector.
References to generic type Vector<E> should be parameterized
[javac] ----------
[javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac] (at line 88)
[javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r
elations.size()]);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^
[javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve
ctor. References to generic type Vector<E> should be parameterized
I think we should try to improve these, but there are rather too many
for me to do on my own! What do others think? I think we could disable
the warnings from Eclipse but I don't think that's really the right
thing to do.
The distribution of warnings is as follows:
4 accessibility
24 archive
90 auth
707 awt
61 beans
7 crypto
128 jndi
206 luni
10 luni-kernel
4 misc
8 nio
7 nio_char
32 prefs
17 regex
260 rmi
568 security
936 swing
26 text
14 x-net
Regards,
Mark.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Help wanted!
Posted by Andrew Zhang <zh...@gmail.com>.
Hello Mark,
How about advocating all code contributers to eliminate such warnings in
their interested module?
It's really a big task for one or two committers. I'm willing to help to
check NIO module.
Thanks!
On 6/21/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> I was looking at building (and testing) with Eclipse + IBM VME. I think
> this is really important since ecj has a much cleaner classpath when it
> compiles so it helps us find errors quicker.
>
> The logs come out at over 3MB! There are lots of warnings about less
> than ideal type checking - mostly as a result of our adoption of more
> generics. For example:
>
> [javac] 1. WARNING in
> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> n/java/javax/accessibility/AccessibleRelationSet.java
> [javac] (at line 44)
> [javac] relations.add(relation);
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
> [javac] Type safety: The method add(Object) belongs to the raw type
> Vector.
> References to generic type Vector<E> should be parameterized
> [javac] ----------
> [javac] 2. WARNING in
> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> n/java/javax/accessibility/AccessibleRelationSet.java
> [javac] (at line 88)
> [javac] (AccessibleRelation[])relations.toArray(new
> AccessibleRelation[r
> elations.size()]);
> [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^
> [javac] Type safety: The method toArray(Object[]) belongs to the raw
> type Ve
> ctor. References to generic type Vector<E> should be parameterized
>
> I think we should try to improve these, but there are rather too many
> for me to do on my own! What do others think? I think we could disable
> the warnings from Eclipse but I don't think that's really the right
> thing to do.
>
> The distribution of warnings is as follows:
>
> 4 accessibility
> 24 archive
> 90 auth
> 707 awt
> 61 beans
> 7 crypto
> 128 jndi
> 206 luni
> 10 luni-kernel
> 4 misc
> 8 nio
> 7 nio_char
> 32 prefs
> 17 regex
> 260 rmi
> 568 security
> 936 swing
> 26 text
> 14 x-net
>
> Regards,
> Mark.
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Help wanted!
Posted by George Harley <ge...@googlemail.com>.
Nathan Beyer wrote:
>> -----Original Message-----
>> From: George Harley [mailto:george.c.harley@googlemail.com]
>>
>> Nathan Beyer wrote:
>>
>>> Yeah, I noticed that. Unfortunately, it can only be used luni for now,
>>>
>> since
>>
>>> the compiler is turning it into an interface class. The sooner we move
>>>
>> to
>>
>>> 1.5 class files the better; I'm tired of the weird 1.5 source to 1.4
>>>
>> class
>>
>>> file behavior that's basically undefined.
>>>
>>>
>>>
>> Hi Nathan,
>>
>> Do you mean that using @SuppressWarnings in types outside of the LUNI
>> module results in compiler problems for you ? If so then I cannot
>> recreate this problem.
>>
>> Best regards,
>> George
>>
>
> That is the problem I'm having. When all source is compiled together using
> ECJ I can use the annotations outside the project they are declared in.
> However, when trying to use the annotations in a project an compiling
> against pre-built class files, then the annotation classes can't be
> resolved. This is why the meta-annotations on Deprecated, SuppressWarnings
> and Override are currently commented out.
>
> The way to recreate this is to open LUNI and another project, such as NIO in
> an Eclipse workspace and then add an annotation to a class in NIO. It should
> compile fine as 'Plug-in Dependencies' will resolve the LUNI reference in
> the workspace. Close the LUNI project and rebuild NIO. The dependencies now
> resolve to the target platform's JARs and the class using the annotation
> will fail to compile.
>
> -Nathan
>
>
Hi Nathan,
OK, I see this too. If I understand correctly, this is a failure that
only occurs inside the Eclipse world and only with the LUNI project
closed. It seems to me that the *temporary* workaround of keeping LUNI
open while working on project X is not particularly prohibitive. So long
as the subsequent changes do not then nobble the build and test cycle
outside Eclipse (i.e. on the modern compiler) then all should be well.
What do you think ?
Best regards,
George
>>
>>>> -----Original Message-----
>>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>>> Sent: Thursday, June 22, 2006 6:04 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib] Help wanted!
>>>>
>>>> Nathan Beyer wrote:
>>>>
>>>>
>>>>> I've been hacking away at those warnings every chance I get. The
>>>>>
>> 'luni'
>>
>>>>> module is going to be filled warnings until we can begin using
>>>>>
>>>>>
>>>> annotations,
>>>>
>>>>
>>>>> specifically the @SuppressWarning, especially the Collections classes.
>>>>>
>>>>>
>>>> Thanks to George [1] you can now use @SuppressWarning.
>>>>
>>>> [1] http://svn.apache.org/viewvc?view=rev&revision=416121
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>>>> There
>>>>> are a number of cases where unchecked type uses are a requirement
>>>>>
>>>>>
>>>> because of
>>>>
>>>>
>>>>> limitations in current APIs, backwards compatability and generic array
>>>>> construction.
>>>>>
>>>>> Here are some of the major pieces that can't be avoided and need
>>>>>
>>>>>
>>>> suppressing
>>>>
>>>>
>>>>> annotations:
>>>>> * Cloning - When you clone a generified object you have no choice but
>>>>>
>> to
>>
>>>> do
>>>>
>>>>
>>>>> an unchecked cast.
>>>>> * Generic Array Construction - The only thing you can do is T[] =
>>>>>
>>>>>
>>>> (T[])new
>>>>
>>>>
>>>>> Object[size]; and suppress the warning.
>>>>>
>>>>> In any case, I'm all for keep this stuff as clean as possible. I have
>>>>>
>> my
>>
>>>>> Eclipse compiler settings cranked to the max in the IDE.
>>>>>
>>>>> -Nathan
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>>>>>> Sent: Wednesday, June 21, 2006 12:49 AM
>>>>>> To: Apache Harmony Dev List
>>>>>> Subject: [classlib] Help wanted!
>>>>>>
>>>>>>
>>>>>> I was looking at building (and testing) with Eclipse + IBM VME. I
>>>>>>
>>>>>>
>>>> think
>>>>
>>>>
>>>>>> this is really important since ecj has a much cleaner classpath when
>>>>>>
>> it
>>
>>>>>> compiles so it helps us find errors quicker.
>>>>>>
>>>>>> The logs come out at over 3MB! There are lots of warnings about less
>>>>>> than ideal type checking - mostly as a result of our adoption of more
>>>>>> generics. For example:
>>>>>>
>>>>>> [javac] 1. WARNING in
>>>>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>>>>>> n/java/javax/accessibility/AccessibleRelationSet.java
>>>>>> [javac] (at line 44)
>>>>>> [javac] relations.add(relation);
>>>>>> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> [javac] Type safety: The method add(Object) belongs to the raw
>>>>>>
>> type
>>
>>>>>> Vector.
>>>>>> References to generic type Vector<E> should be parameterized
>>>>>> [javac] ----------
>>>>>> [javac] 2. WARNING in
>>>>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>>>>>> n/java/javax/accessibility/AccessibleRelationSet.java
>>>>>> [javac] (at line 88)
>>>>>> [javac] (AccessibleRelation[])relations.toArray(new
>>>>>> AccessibleRelation[r
>>>>>> elations.size()]);
>>>>>> [javac]
>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> ^^^^^^^^^^^^^^^^^
>>>>>> [javac] Type safety: The method toArray(Object[]) belongs to the
>>>>>>
>>>>>>
>>>> raw
>>>>
>>>>
>>>>>> type Ve
>>>>>> ctor. References to generic type Vector<E> should be parameterized
>>>>>>
>>>>>> I think we should try to improve these, but there are rather too many
>>>>>> for me to do on my own! What do others think? I think we could
>>>>>>
>>>>>>
>>>> disable
>>>>
>>>>
>>>>>> the warnings from Eclipse but I don't think that's really the right
>>>>>> thing to do.
>>>>>>
>>>>>> The distribution of warnings is as follows:
>>>>>>
>>>>>> 4 accessibility
>>>>>> 24 archive
>>>>>> 90 auth
>>>>>> 707 awt
>>>>>> 61 beans
>>>>>> 7 crypto
>>>>>> 128 jndi
>>>>>> 206 luni
>>>>>> 10 luni-kernel
>>>>>> 4 misc
>>>>>> 8 nio
>>>>>> 7 nio_char
>>>>>> 32 prefs
>>>>>> 17 regex
>>>>>> 260 rmi
>>>>>> 568 security
>>>>>> 936 swing
>>>>>> 26 text
>>>>>> 14 x-net
>>>>>>
>>>>>> Regards,
>>>>>> Mark.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: harmony-dev-
>>>>>>
>> help@incubator.apache.org
>>
>>>>> ---------------------------------------------------------------------
>>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib] Help wanted!
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: George Harley [mailto:george.c.harley@googlemail.com]
>
> Nathan Beyer wrote:
> > Yeah, I noticed that. Unfortunately, it can only be used luni for now,
> since
> > the compiler is turning it into an interface class. The sooner we move
> to
> > 1.5 class files the better; I'm tired of the weird 1.5 source to 1.4
> class
> > file behavior that's basically undefined.
> >
> >
>
> Hi Nathan,
>
> Do you mean that using @SuppressWarnings in types outside of the LUNI
> module results in compiler problems for you ? If so then I cannot
> recreate this problem.
>
> Best regards,
> George
That is the problem I'm having. When all source is compiled together using
ECJ I can use the annotations outside the project they are declared in.
However, when trying to use the annotations in a project an compiling
against pre-built class files, then the annotation classes can't be
resolved. This is why the meta-annotations on Deprecated, SuppressWarnings
and Override are currently commented out.
The way to recreate this is to open LUNI and another project, such as NIO in
an Eclipse workspace and then add an annotation to a class in NIO. It should
compile fine as 'Plug-in Dependencies' will resolve the LUNI reference in
the workspace. Close the LUNI project and rebuild NIO. The dependencies now
resolve to the target platform's JARs and the class using the annotation
will fail to compile.
-Nathan
>
>
> >> -----Original Message-----
> >> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> >> Sent: Thursday, June 22, 2006 6:04 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [classlib] Help wanted!
> >>
> >> Nathan Beyer wrote:
> >>
> >>> I've been hacking away at those warnings every chance I get. The
> 'luni'
> >>> module is going to be filled warnings until we can begin using
> >>>
> >> annotations,
> >>
> >>> specifically the @SuppressWarning, especially the Collections classes.
> >>>
> >> Thanks to George [1] you can now use @SuppressWarning.
> >>
> >> [1] http://svn.apache.org/viewvc?view=rev&revision=416121
> >>
> >> Regards,
> >> Tim
> >>
> >>
> >>> There
> >>> are a number of cases where unchecked type uses are a requirement
> >>>
> >> because of
> >>
> >>> limitations in current APIs, backwards compatability and generic array
> >>> construction.
> >>>
> >>> Here are some of the major pieces that can't be avoided and need
> >>>
> >> suppressing
> >>
> >>> annotations:
> >>> * Cloning - When you clone a generified object you have no choice but
> to
> >>>
> >> do
> >>
> >>> an unchecked cast.
> >>> * Generic Array Construction - The only thing you can do is T[] =
> >>>
> >> (T[])new
> >>
> >>> Object[size]; and suppress the warning.
> >>>
> >>> In any case, I'm all for keep this stuff as clean as possible. I have
> my
> >>> Eclipse compiler settings cranked to the max in the IDE.
> >>>
> >>> -Nathan
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> >>>> Sent: Wednesday, June 21, 2006 12:49 AM
> >>>> To: Apache Harmony Dev List
> >>>> Subject: [classlib] Help wanted!
> >>>>
> >>>>
> >>>> I was looking at building (and testing) with Eclipse + IBM VME. I
> >>>>
> >> think
> >>
> >>>> this is really important since ecj has a much cleaner classpath when
> it
> >>>> compiles so it helps us find errors quicker.
> >>>>
> >>>> The logs come out at over 3MB! There are lots of warnings about less
> >>>> than ideal type checking - mostly as a result of our adoption of more
> >>>> generics. For example:
> >>>>
> >>>> [javac] 1. WARNING in
> >>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> >>>> n/java/javax/accessibility/AccessibleRelationSet.java
> >>>> [javac] (at line 44)
> >>>> [javac] relations.add(relation);
> >>>> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
> >>>> [javac] Type safety: The method add(Object) belongs to the raw
> type
> >>>> Vector.
> >>>> References to generic type Vector<E> should be parameterized
> >>>> [javac] ----------
> >>>> [javac] 2. WARNING in
> >>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> >>>> n/java/javax/accessibility/AccessibleRelationSet.java
> >>>> [javac] (at line 88)
> >>>> [javac] (AccessibleRelation[])relations.toArray(new
> >>>> AccessibleRelation[r
> >>>> elations.size()]);
> >>>> [javac]
> >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>> ^^^^^^^^^^^^^^^^^
> >>>> [javac] Type safety: The method toArray(Object[]) belongs to the
> >>>>
> >> raw
> >>
> >>>> type Ve
> >>>> ctor. References to generic type Vector<E> should be parameterized
> >>>>
> >>>> I think we should try to improve these, but there are rather too many
> >>>> for me to do on my own! What do others think? I think we could
> >>>>
> >> disable
> >>
> >>>> the warnings from Eclipse but I don't think that's really the right
> >>>> thing to do.
> >>>>
> >>>> The distribution of warnings is as follows:
> >>>>
> >>>> 4 accessibility
> >>>> 24 archive
> >>>> 90 auth
> >>>> 707 awt
> >>>> 61 beans
> >>>> 7 crypto
> >>>> 128 jndi
> >>>> 206 luni
> >>>> 10 luni-kernel
> >>>> 4 misc
> >>>> 8 nio
> >>>> 7 nio_char
> >>>> 32 prefs
> >>>> 17 regex
> >>>> 260 rmi
> >>>> 568 security
> >>>> 936 swing
> >>>> 26 text
> >>>> 14 x-net
> >>>>
> >>>> Regards,
> >>>> Mark.
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: harmony-dev-
> help@incubator.apache.org
> >>>>
> >>> ---------------------------------------------------------------------
> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>>
> >>>
> >>>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Help wanted!
Posted by George Harley <ge...@googlemail.com>.
Nathan Beyer wrote:
> Yeah, I noticed that. Unfortunately, it can only be used luni for now, since
> the compiler is turning it into an interface class. The sooner we move to
> 1.5 class files the better; I'm tired of the weird 1.5 source to 1.4 class
> file behavior that's basically undefined.
>
>
Hi Nathan,
Do you mean that using @SuppressWarnings in types outside of the LUNI
module results in compiler problems for you ? If so then I cannot
recreate this problem.
Best regards,
George
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>> Sent: Thursday, June 22, 2006 6:04 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] Help wanted!
>>
>> Nathan Beyer wrote:
>>
>>> I've been hacking away at those warnings every chance I get. The 'luni'
>>> module is going to be filled warnings until we can begin using
>>>
>> annotations,
>>
>>> specifically the @SuppressWarning, especially the Collections classes.
>>>
>> Thanks to George [1] you can now use @SuppressWarning.
>>
>> [1] http://svn.apache.org/viewvc?view=rev&revision=416121
>>
>> Regards,
>> Tim
>>
>>
>>> There
>>> are a number of cases where unchecked type uses are a requirement
>>>
>> because of
>>
>>> limitations in current APIs, backwards compatability and generic array
>>> construction.
>>>
>>> Here are some of the major pieces that can't be avoided and need
>>>
>> suppressing
>>
>>> annotations:
>>> * Cloning - When you clone a generified object you have no choice but to
>>>
>> do
>>
>>> an unchecked cast.
>>> * Generic Array Construction - The only thing you can do is T[] =
>>>
>> (T[])new
>>
>>> Object[size]; and suppress the warning.
>>>
>>> In any case, I'm all for keep this stuff as clean as possible. I have my
>>> Eclipse compiler settings cranked to the max in the IDE.
>>>
>>> -Nathan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>>>> Sent: Wednesday, June 21, 2006 12:49 AM
>>>> To: Apache Harmony Dev List
>>>> Subject: [classlib] Help wanted!
>>>>
>>>>
>>>> I was looking at building (and testing) with Eclipse + IBM VME. I
>>>>
>> think
>>
>>>> this is really important since ecj has a much cleaner classpath when it
>>>> compiles so it helps us find errors quicker.
>>>>
>>>> The logs come out at over 3MB! There are lots of warnings about less
>>>> than ideal type checking - mostly as a result of our adoption of more
>>>> generics. For example:
>>>>
>>>> [javac] 1. WARNING in
>>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>>>> n/java/javax/accessibility/AccessibleRelationSet.java
>>>> [javac] (at line 44)
>>>> [javac] relations.add(relation);
>>>> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
>>>> [javac] Type safety: The method add(Object) belongs to the raw type
>>>> Vector.
>>>> References to generic type Vector<E> should be parameterized
>>>> [javac] ----------
>>>> [javac] 2. WARNING in
>>>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>>>> n/java/javax/accessibility/AccessibleRelationSet.java
>>>> [javac] (at line 88)
>>>> [javac] (AccessibleRelation[])relations.toArray(new
>>>> AccessibleRelation[r
>>>> elations.size()]);
>>>> [javac]
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> ^^^^^^^^^^^^^^^^^
>>>> [javac] Type safety: The method toArray(Object[]) belongs to the
>>>>
>> raw
>>
>>>> type Ve
>>>> ctor. References to generic type Vector<E> should be parameterized
>>>>
>>>> I think we should try to improve these, but there are rather too many
>>>> for me to do on my own! What do others think? I think we could
>>>>
>> disable
>>
>>>> the warnings from Eclipse but I don't think that's really the right
>>>> thing to do.
>>>>
>>>> The distribution of warnings is as follows:
>>>>
>>>> 4 accessibility
>>>> 24 archive
>>>> 90 auth
>>>> 707 awt
>>>> 61 beans
>>>> 7 crypto
>>>> 128 jndi
>>>> 206 luni
>>>> 10 luni-kernel
>>>> 4 misc
>>>> 8 nio
>>>> 7 nio_char
>>>> 32 prefs
>>>> 17 regex
>>>> 260 rmi
>>>> 568 security
>>>> 936 swing
>>>> 26 text
>>>> 14 x-net
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib] Help wanted!
Posted by Nathan Beyer <nb...@kc.rr.com>.
Yeah, I noticed that. Unfortunately, it can only be used luni for now, since
the compiler is turning it into an interface class. The sooner we move to
1.5 class files the better; I'm tired of the weird 1.5 source to 1.4 class
file behavior that's basically undefined.
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Thursday, June 22, 2006 6:04 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] Help wanted!
>
> Nathan Beyer wrote:
> > I've been hacking away at those warnings every chance I get. The 'luni'
> > module is going to be filled warnings until we can begin using
> annotations,
> > specifically the @SuppressWarning, especially the Collections classes.
>
> Thanks to George [1] you can now use @SuppressWarning.
>
> [1] http://svn.apache.org/viewvc?view=rev&revision=416121
>
> Regards,
> Tim
>
> > There
> > are a number of cases where unchecked type uses are a requirement
> because of
> > limitations in current APIs, backwards compatability and generic array
> > construction.
> >
> > Here are some of the major pieces that can't be avoided and need
> suppressing
> > annotations:
> > * Cloning - When you clone a generified object you have no choice but to
> do
> > an unchecked cast.
> > * Generic Array Construction - The only thing you can do is T[] =
> (T[])new
> > Object[size]; and suppress the warning.
> >
> > In any case, I'm all for keep this stuff as clean as possible. I have my
> > Eclipse compiler settings cranked to the max in the IDE.
> >
> > -Nathan
> >
> >> -----Original Message-----
> >> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> >> Sent: Wednesday, June 21, 2006 12:49 AM
> >> To: Apache Harmony Dev List
> >> Subject: [classlib] Help wanted!
> >>
> >>
> >> I was looking at building (and testing) with Eclipse + IBM VME. I
> think
> >> this is really important since ecj has a much cleaner classpath when it
> >> compiles so it helps us find errors quicker.
> >>
> >> The logs come out at over 3MB! There are lots of warnings about less
> >> than ideal type checking - mostly as a result of our adoption of more
> >> generics. For example:
> >>
> >> [javac] 1. WARNING in
> >> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> >> n/java/javax/accessibility/AccessibleRelationSet.java
> >> [javac] (at line 44)
> >> [javac] relations.add(relation);
> >> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
> >> [javac] Type safety: The method add(Object) belongs to the raw type
> >> Vector.
> >> References to generic type Vector<E> should be parameterized
> >> [javac] ----------
> >> [javac] 2. WARNING in
> >> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> >> n/java/javax/accessibility/AccessibleRelationSet.java
> >> [javac] (at line 88)
> >> [javac] (AccessibleRelation[])relations.toArray(new
> >> AccessibleRelation[r
> >> elations.size()]);
> >> [javac]
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> ^^^^^^^^^^^^^^^^^
> >> [javac] Type safety: The method toArray(Object[]) belongs to the
> raw
> >> type Ve
> >> ctor. References to generic type Vector<E> should be parameterized
> >>
> >> I think we should try to improve these, but there are rather too many
> >> for me to do on my own! What do others think? I think we could
> disable
> >> the warnings from Eclipse but I don't think that's really the right
> >> thing to do.
> >>
> >> The distribution of warnings is as follows:
> >>
> >> 4 accessibility
> >> 24 archive
> >> 90 auth
> >> 707 awt
> >> 61 beans
> >> 7 crypto
> >> 128 jndi
> >> 206 luni
> >> 10 luni-kernel
> >> 4 misc
> >> 8 nio
> >> 7 nio_char
> >> 32 prefs
> >> 17 regex
> >> 260 rmi
> >> 568 security
> >> 936 swing
> >> 26 text
> >> 14 x-net
> >>
> >> Regards,
> >> Mark.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Help wanted!
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> I've been hacking away at those warnings every chance I get. The 'luni'
> module is going to be filled warnings until we can begin using annotations,
> specifically the @SuppressWarning, especially the Collections classes.
Thanks to George [1] you can now use @SuppressWarning.
[1] http://svn.apache.org/viewvc?view=rev&revision=416121
Regards,
Tim
> There
> are a number of cases where unchecked type uses are a requirement because of
> limitations in current APIs, backwards compatability and generic array
> construction.
>
> Here are some of the major pieces that can't be avoided and need suppressing
> annotations:
> * Cloning - When you clone a generified object you have no choice but to do
> an unchecked cast.
> * Generic Array Construction - The only thing you can do is T[] = (T[])new
> Object[size]; and suppress the warning.
>
> In any case, I'm all for keep this stuff as clean as possible. I have my
> Eclipse compiler settings cranked to the max in the IDE.
>
> -Nathan
>
>> -----Original Message-----
>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>> Sent: Wednesday, June 21, 2006 12:49 AM
>> To: Apache Harmony Dev List
>> Subject: [classlib] Help wanted!
>>
>>
>> I was looking at building (and testing) with Eclipse + IBM VME. I think
>> this is really important since ecj has a much cleaner classpath when it
>> compiles so it helps us find errors quicker.
>>
>> The logs come out at over 3MB! There are lots of warnings about less
>> than ideal type checking - mostly as a result of our adoption of more
>> generics. For example:
>>
>> [javac] 1. WARNING in
>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>> n/java/javax/accessibility/AccessibleRelationSet.java
>> [javac] (at line 44)
>> [javac] relations.add(relation);
>> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
>> [javac] Type safety: The method add(Object) belongs to the raw type
>> Vector.
>> References to generic type Vector<E> should be parameterized
>> [javac] ----------
>> [javac] 2. WARNING in
>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>> n/java/javax/accessibility/AccessibleRelationSet.java
>> [javac] (at line 88)
>> [javac] (AccessibleRelation[])relations.toArray(new
>> AccessibleRelation[r
>> elations.size()]);
>> [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ^^^^^^^^^^^^^^^^^
>> [javac] Type safety: The method toArray(Object[]) belongs to the raw
>> type Ve
>> ctor. References to generic type Vector<E> should be parameterized
>>
>> I think we should try to improve these, but there are rather too many
>> for me to do on my own! What do others think? I think we could disable
>> the warnings from Eclipse but I don't think that's really the right
>> thing to do.
>>
>> The distribution of warnings is as follows:
>>
>> 4 accessibility
>> 24 archive
>> 90 auth
>> 707 awt
>> 61 beans
>> 7 crypto
>> 128 jndi
>> 206 luni
>> 10 luni-kernel
>> 4 misc
>> 8 nio
>> 7 nio_char
>> 32 prefs
>> 17 regex
>> 260 rmi
>> 568 security
>> 936 swing
>> 26 text
>> 14 x-net
>>
>> Regards,
>> Mark.
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Help wanted!
Posted by Paulex Yang <pa...@gmail.com>.
Nathan Beyer wrote:
> I've been hacking away at those warnings every chance I get. The 'luni'
> module is going to be filled warnings until we can begin using annotations,
> specifically the @SuppressWarning, especially the Collections classes. There
> are a number of cases where unchecked type uses are a requirement because of
> limitations in current APIs, backwards compatability and generic array
> construction.
>
> Here are some of the major pieces that can't be avoided and need suppressing
> annotations:
> * Cloning - When you clone a generified object you have no choice but to do
> an unchecked cast.
> * Generic Array Construction - The only thing you can do is T[] = (T[])new
> Object[size]; and suppress the warning.
>
I agree, do we need a list on these unavoidable cases?
here goes some other samples come form PriorityQueue
1. Deserialization to generic array or collections: elements[i] =
(E)in.readObject()
2. Comparator<T>.compare(), for the given Object, you must cast it to T
3. Accept a Comparator from another collection, the collection's
generic type is probably <? extends E>, but the Comparator's is
generally <? super E>, so codes like this cannot be avoidable:
void getFromSortedSet(SortedSet<? extends E> c) {
comparator = (Comparator<? super E>) c.comparator();
...
}
> In any case, I'm all for keep this stuff as clean as possible. I have my
> Eclipse compiler settings cranked to the max in the IDE.
>
> -Nathan
>
>
>> -----Original Message-----
>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>> Sent: Wednesday, June 21, 2006 12:49 AM
>> To: Apache Harmony Dev List
>> Subject: [classlib] Help wanted!
>>
>>
>> I was looking at building (and testing) with Eclipse + IBM VME. I think
>> this is really important since ecj has a much cleaner classpath when it
>> compiles so it helps us find errors quicker.
>>
>> The logs come out at over 3MB! There are lots of warnings about less
>> than ideal type checking - mostly as a result of our adoption of more
>> generics. For example:
>>
>> [javac] 1. WARNING in
>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>> n/java/javax/accessibility/AccessibleRelationSet.java
>> [javac] (at line 44)
>> [javac] relations.add(relation);
>> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
>> [javac] Type safety: The method add(Object) belongs to the raw type
>> Vector.
>> References to generic type Vector<E> should be parameterized
>> [javac] ----------
>> [javac] 2. WARNING in
>> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>> n/java/javax/accessibility/AccessibleRelationSet.java
>> [javac] (at line 88)
>> [javac] (AccessibleRelation[])relations.toArray(new
>> AccessibleRelation[r
>> elations.size()]);
>> [javac]
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ^^^^^^^^^^^^^^^^^
>> [javac] Type safety: The method toArray(Object[]) belongs to the raw
>> type Ve
>> ctor. References to generic type Vector<E> should be parameterized
>>
>> I think we should try to improve these, but there are rather too many
>> for me to do on my own! What do others think? I think we could disable
>> the warnings from Eclipse but I don't think that's really the right
>> thing to do.
>>
>> The distribution of warnings is as follows:
>>
>> 4 accessibility
>> 24 archive
>> 90 auth
>> 707 awt
>> 61 beans
>> 7 crypto
>> 128 jndi
>> 206 luni
>> 10 luni-kernel
>> 4 misc
>> 8 nio
>> 7 nio_char
>> 32 prefs
>> 17 regex
>> 260 rmi
>> 568 security
>> 936 swing
>> 26 text
>> 14 x-net
>>
>> Regards,
>> Mark.
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
RE: [classlib] Help wanted!
Posted by Nathan Beyer <nb...@kc.rr.com>.
I've been hacking away at those warnings every chance I get. The 'luni'
module is going to be filled warnings until we can begin using annotations,
specifically the @SuppressWarning, especially the Collections classes. There
are a number of cases where unchecked type uses are a requirement because of
limitations in current APIs, backwards compatability and generic array
construction.
Here are some of the major pieces that can't be avoided and need suppressing
annotations:
* Cloning - When you clone a generified object you have no choice but to do
an unchecked cast.
* Generic Array Construction - The only thing you can do is T[] = (T[])new
Object[size]; and suppress the warning.
In any case, I'm all for keep this stuff as clean as possible. I have my
Eclipse compiler settings cranked to the max in the IDE.
-Nathan
> -----Original Message-----
> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> Sent: Wednesday, June 21, 2006 12:49 AM
> To: Apache Harmony Dev List
> Subject: [classlib] Help wanted!
>
>
> I was looking at building (and testing) with Eclipse + IBM VME. I think
> this is really important since ecj has a much cleaner classpath when it
> compiles so it helps us find errors quicker.
>
> The logs come out at over 3MB! There are lots of warnings about less
> than ideal type checking - mostly as a result of our adoption of more
> generics. For example:
>
> [javac] 1. WARNING in
> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> n/java/javax/accessibility/AccessibleRelationSet.java
> [javac] (at line 44)
> [javac] relations.add(relation);
> [javac] ^^^^^^^^^^^^^^^^^^^^^^^
> [javac] Type safety: The method add(Object) belongs to the raw type
> Vector.
> References to generic type Vector<E> should be parameterized
> [javac] ----------
> [javac] 2. WARNING in
> /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
> n/java/javax/accessibility/AccessibleRelationSet.java
> [javac] (at line 88)
> [javac] (AccessibleRelation[])relations.toArray(new
> AccessibleRelation[r
> elations.size()]);
> [javac]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^
> [javac] Type safety: The method toArray(Object[]) belongs to the raw
> type Ve
> ctor. References to generic type Vector<E> should be parameterized
>
> I think we should try to improve these, but there are rather too many
> for me to do on my own! What do others think? I think we could disable
> the warnings from Eclipse but I don't think that's really the right
> thing to do.
>
> The distribution of warnings is as follows:
>
> 4 accessibility
> 24 archive
> 90 auth
> 707 awt
> 61 beans
> 7 crypto
> 128 jndi
> 206 luni
> 10 luni-kernel
> 4 misc
> 8 nio
> 7 nio_char
> 32 prefs
> 17 regex
> 260 rmi
> 568 security
> 936 swing
> 26 text
> 14 x-net
>
> Regards,
> Mark.
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org