harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: [classlib] Help wanted!
Date Mon, 26 Jun 2006 09:04:25 GMT
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


Mime
View raw message