You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jörg Schaible <jo...@scalaris.com> on 2011/03/01 09:00:02 UTC
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Hi Simone,
Simone Tripodi wrote:
[snip]
> @SuppressWarnings("unchecked")
> public <T> T parse(InputSource input, Class<T> returnedType) throws
> IOException, SAXException {
> .
> .
> .
> return returnedType.cast(this.root);
> }
It would be nice, if we can start to avoid such method global suppressions,
because it hides possibly unwanted stuff. You can always assign the
annotation directly to a variable instead:
@SuppressWarnings("unchecked")
T t = returnedType.cast(this.root);
return t;
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Simone Tripodi <si...@apache.org>.
Hi Seb,
I think you provided an excellent feedback, I can follow the path you
just showed me and
* add the warning in the parse() method;
* provide an aux method, something like checkedParse() that takes the
Class in input and performs the check once document has been parsed.
On a side note, I'd like to collect feedbacks on what all you think
about promoting the sandbox on proper
Many thanks in advance, have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 1, 2011 at 5:22 PM, sebb <se...@gmail.com> wrote:
> On 1 March 2011 15:55, Simone Tripodi <si...@apache.org> wrote:
>> Hi Seb!
>> thanks a lot for your hints too, very appreciated!
>>
>> Something suggests me to remove the @SuppressWarnings because
>> ClassCastException are admitted, let's suppose I have the given XML:
>>
>> <a>
>> <prop>text</prop>
>> </a>
>>
>> that can be mapped to
>>
>> class A {
>> String prop;
>> }
>>
>> if a user tries to map to a different type
>>
>> B b = digester.parse("<a><prop>text</prop></a>");
>>
>> An exception has to be thrown.
>
> It will be thrown with the generic fix, because the compiler adds a
> cast to the parse return.
>
> However, there is no obvious casting in the above code, so the user
> may be puzzled by the ClassCastException.
>
>> What's the best way to handle that situation?
>
> I think the problem is that parse is not really a generic method, and
> Java does not make the target class available to the method.
> If you changed the API to add a Class parameter then you could do the
> check in the parse method.
> But that might be just as awkward to use.
>
> It is obviously nicer to read if the compiler inserts the casts
> automatically, but the downside is that CCEs can occur when you least
> expect them.
>
> In the sample code, it will happen immediately, but the instance could
> be stored in a collection and then the CCE might not occur until much
> later.
>
> Maybe one solution would be to allow the autocasting, but provide a
> big warning in the Javadoc that it may result in CCEs at any time.
> For those who don't want to take this risk, there would need to be
> another version which guaranteed the correct class - or an Exception
> if that's not possible.
>
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Mar 1, 2011 at 4:04 PM, sebb <se...@gmail.com> wrote:
>>> On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
>>>> Hi Simone,
>>>>
>>>> Simone Tripodi wrote:
>>>>
>>>> [snip]
>>>>
>>>>
>>>>> @SuppressWarnings("unchecked")
>>>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>>>> IOException, SAXException {
>>>>> .
>>>>> .
>>>>> .
>>>>> return returnedType.cast(this.root);
>>>>> }
>>>>
>>>> It would be nice, if we can start to avoid such method global suppressions,
>>>> because it hides possibly unwanted stuff. You can always assign the
>>>> annotation directly to a variable instead:
>>>>
>>>> @SuppressWarnings("unchecked")
>>>> T t = returnedType.cast(this.root);
>>>> return t;
>>>
>>> I would go a bit further and say that @SuppressWarnings should not be
>>> used unless you can prove that the cast is always valid (as may well
>>> be the case here - I've not checked), and that this should be
>>> documented in a // comment on the annotation, e.g.
>>>
>>> @SuppressWarnings("unchecked") // OK because etc.
>>>
>>> Otherwise, the annotation effectively gives the compiler permission to
>>> cause a ClassCastException somewhere else at some point in the future.
>>>
>>> As with many forms of suppression, the risk is that there will be a
>>> bad reaction later ...
>>>
>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Simone Tripodi <si...@apache.org>.
Thanks again for your feedbacks Matt, much more than appreciated! :)
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 1, 2011 at 7:02 PM, Matt Benson <gu...@gmail.com> wrote:
>
> On Mar 1, 2011, at 10:22 AM, sebb wrote:
>
>> On 1 March 2011 15:55, Simone Tripodi <si...@apache.org> wrote:
>>> Hi Seb!
>>> thanks a lot for your hints too, very appreciated!
>>>
>>> Something suggests me to remove the @SuppressWarnings because
>>> ClassCastException are admitted, let's suppose I have the given XML:
>>>
>>> <a>
>>> <prop>text</prop>
>>> </a>
>>>
>>> that can be mapped to
>>>
>>> class A {
>>> String prop;
>>> }
>>>
>>> if a user tries to map to a different type
>>>
>>> B b = digester.parse("<a><prop>text</prop></a>");
>>>
>>> An exception has to be thrown.
>>
>> It will be thrown with the generic fix, because the compiler adds a
>> cast to the parse return.
>>
>> However, there is no obvious casting in the above code, so the user
>> may be puzzled by the ClassCastException.
>>
>>> What's the best way to handle that situation?
>>
>> I think the problem is that parse is not really a generic method, and
>> Java does not make the target class available to the method.
>> If you changed the API to add a Class parameter then you could do the
>> check in the parse method.
>> But that might be just as awkward to use.
>>
>> It is obviously nicer to read if the compiler inserts the casts
>> automatically, but the downside is that CCEs can occur when you least
>> expect them.
>>
>> In the sample code, it will happen immediately, but the instance could
>> be stored in a collection and then the CCE might not occur until much
>> later.
>>
>
> This particular "trick" really only applies to such Object foo(...) methods where there are two options for non-generic versions of the code:
>
> 1. Client calls Object foo = foo(...); if (foo instanceof Foo)...
> 2. Client calls Foo foo = (Foo) foo(...); potential CCE
>
> My position is that the generic parameter RT casting trick has no effect other than to remove the cast from option 2 above. If a CCE were going to be raised, it would be raised regardless. The option 1 idiom is still perfectly valid.
>
> Matt
>
>> Maybe one solution would be to allow the autocasting, but provide a
>> big warning in the Javadoc that it may result in CCEs at any time.
>> For those who don't want to take this risk, there would need to be
>> another version which guaranteed the correct class - or an Exception
>> if that's not possible.
>>
>>> Many thanks in advance, have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, Mar 1, 2011 at 4:04 PM, sebb <se...@gmail.com> wrote:
>>>> On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
>>>>> Hi Simone,
>>>>>
>>>>> Simone Tripodi wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>
>>>>>> @SuppressWarnings("unchecked")
>>>>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>>>>> IOException, SAXException {
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> return returnedType.cast(this.root);
>>>>>> }
>>>>>
>>>>> It would be nice, if we can start to avoid such method global suppressions,
>>>>> because it hides possibly unwanted stuff. You can always assign the
>>>>> annotation directly to a variable instead:
>>>>>
>>>>> @SuppressWarnings("unchecked")
>>>>> T t = returnedType.cast(this.root);
>>>>> return t;
>>>>
>>>> I would go a bit further and say that @SuppressWarnings should not be
>>>> used unless you can prove that the cast is always valid (as may well
>>>> be the case here - I've not checked), and that this should be
>>>> documented in a // comment on the annotation, e.g.
>>>>
>>>> @SuppressWarnings("unchecked") // OK because etc.
>>>>
>>>> Otherwise, the annotation effectively gives the compiler permission to
>>>> cause a ClassCastException somewhere else at some point in the future.
>>>>
>>>> As with many forms of suppression, the risk is that there will be a
>>>> bad reaction later ...
>>>>
>>>>
>>>>> - Jörg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Matt Benson <gu...@gmail.com>.
On Mar 1, 2011, at 10:22 AM, sebb wrote:
> On 1 March 2011 15:55, Simone Tripodi <si...@apache.org> wrote:
>> Hi Seb!
>> thanks a lot for your hints too, very appreciated!
>>
>> Something suggests me to remove the @SuppressWarnings because
>> ClassCastException are admitted, let's suppose I have the given XML:
>>
>> <a>
>> <prop>text</prop>
>> </a>
>>
>> that can be mapped to
>>
>> class A {
>> String prop;
>> }
>>
>> if a user tries to map to a different type
>>
>> B b = digester.parse("<a><prop>text</prop></a>");
>>
>> An exception has to be thrown.
>
> It will be thrown with the generic fix, because the compiler adds a
> cast to the parse return.
>
> However, there is no obvious casting in the above code, so the user
> may be puzzled by the ClassCastException.
>
>> What's the best way to handle that situation?
>
> I think the problem is that parse is not really a generic method, and
> Java does not make the target class available to the method.
> If you changed the API to add a Class parameter then you could do the
> check in the parse method.
> But that might be just as awkward to use.
>
> It is obviously nicer to read if the compiler inserts the casts
> automatically, but the downside is that CCEs can occur when you least
> expect them.
>
> In the sample code, it will happen immediately, but the instance could
> be stored in a collection and then the CCE might not occur until much
> later.
>
This particular "trick" really only applies to such Object foo(...) methods where there are two options for non-generic versions of the code:
1. Client calls Object foo = foo(...); if (foo instanceof Foo)...
2. Client calls Foo foo = (Foo) foo(...); potential CCE
My position is that the generic parameter RT casting trick has no effect other than to remove the cast from option 2 above. If a CCE were going to be raised, it would be raised regardless. The option 1 idiom is still perfectly valid.
Matt
> Maybe one solution would be to allow the autocasting, but provide a
> big warning in the Javadoc that it may result in CCEs at any time.
> For those who don't want to take this risk, there would need to be
> another version which guaranteed the correct class - or an Exception
> if that's not possible.
>
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Mar 1, 2011 at 4:04 PM, sebb <se...@gmail.com> wrote:
>>> On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
>>>> Hi Simone,
>>>>
>>>> Simone Tripodi wrote:
>>>>
>>>> [snip]
>>>>
>>>>
>>>>> @SuppressWarnings("unchecked")
>>>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>>>> IOException, SAXException {
>>>>> .
>>>>> .
>>>>> .
>>>>> return returnedType.cast(this.root);
>>>>> }
>>>>
>>>> It would be nice, if we can start to avoid such method global suppressions,
>>>> because it hides possibly unwanted stuff. You can always assign the
>>>> annotation directly to a variable instead:
>>>>
>>>> @SuppressWarnings("unchecked")
>>>> T t = returnedType.cast(this.root);
>>>> return t;
>>>
>>> I would go a bit further and say that @SuppressWarnings should not be
>>> used unless you can prove that the cast is always valid (as may well
>>> be the case here - I've not checked), and that this should be
>>> documented in a // comment on the annotation, e.g.
>>>
>>> @SuppressWarnings("unchecked") // OK because etc.
>>>
>>> Otherwise, the annotation effectively gives the compiler permission to
>>> cause a ClassCastException somewhere else at some point in the future.
>>>
>>> As with many forms of suppression, the risk is that there will be a
>>> bad reaction later ...
>>>
>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by sebb <se...@gmail.com>.
On 1 March 2011 15:55, Simone Tripodi <si...@apache.org> wrote:
> Hi Seb!
> thanks a lot for your hints too, very appreciated!
>
> Something suggests me to remove the @SuppressWarnings because
> ClassCastException are admitted, let's suppose I have the given XML:
>
> <a>
> <prop>text</prop>
> </a>
>
> that can be mapped to
>
> class A {
> String prop;
> }
>
> if a user tries to map to a different type
>
> B b = digester.parse("<a><prop>text</prop></a>");
>
> An exception has to be thrown.
It will be thrown with the generic fix, because the compiler adds a
cast to the parse return.
However, there is no obvious casting in the above code, so the user
may be puzzled by the ClassCastException.
> What's the best way to handle that situation?
I think the problem is that parse is not really a generic method, and
Java does not make the target class available to the method.
If you changed the API to add a Class parameter then you could do the
check in the parse method.
But that might be just as awkward to use.
It is obviously nicer to read if the compiler inserts the casts
automatically, but the downside is that CCEs can occur when you least
expect them.
In the sample code, it will happen immediately, but the instance could
be stored in a collection and then the CCE might not occur until much
later.
Maybe one solution would be to allow the autocasting, but provide a
big warning in the Javadoc that it may result in CCEs at any time.
For those who don't want to take this risk, there would need to be
another version which guaranteed the correct class - or an Exception
if that's not possible.
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 4:04 PM, sebb <se...@gmail.com> wrote:
>> On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
>>> Hi Simone,
>>>
>>> Simone Tripodi wrote:
>>>
>>> [snip]
>>>
>>>
>>>> @SuppressWarnings("unchecked")
>>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>>> IOException, SAXException {
>>>> .
>>>> .
>>>> .
>>>> return returnedType.cast(this.root);
>>>> }
>>>
>>> It would be nice, if we can start to avoid such method global suppressions,
>>> because it hides possibly unwanted stuff. You can always assign the
>>> annotation directly to a variable instead:
>>>
>>> @SuppressWarnings("unchecked")
>>> T t = returnedType.cast(this.root);
>>> return t;
>>
>> I would go a bit further and say that @SuppressWarnings should not be
>> used unless you can prove that the cast is always valid (as may well
>> be the case here - I've not checked), and that this should be
>> documented in a // comment on the annotation, e.g.
>>
>> @SuppressWarnings("unchecked") // OK because etc.
>>
>> Otherwise, the annotation effectively gives the compiler permission to
>> cause a ClassCastException somewhere else at some point in the future.
>>
>> As with many forms of suppression, the risk is that there will be a
>> bad reaction later ...
>>
>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Simone Tripodi <si...@apache.org>.
Hi Seb!
thanks a lot for your hints too, very appreciated!
Something suggests me to remove the @SuppressWarnings because
ClassCastException are admitted, let's suppose I have the given XML:
<a>
<prop>text</prop>
</a>
that can be mapped to
class A {
String prop;
}
if a user tries to map to a different type
B b = digester.parse("<a><prop>text</prop></a>");
An exception has to be thrown.
What's the best way to handle that situation?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 1, 2011 at 4:04 PM, sebb <se...@gmail.com> wrote:
> On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
>> Hi Simone,
>>
>> Simone Tripodi wrote:
>>
>> [snip]
>>
>>
>>> @SuppressWarnings("unchecked")
>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>> IOException, SAXException {
>>> .
>>> .
>>> .
>>> return returnedType.cast(this.root);
>>> }
>>
>> It would be nice, if we can start to avoid such method global suppressions,
>> because it hides possibly unwanted stuff. You can always assign the
>> annotation directly to a variable instead:
>>
>> @SuppressWarnings("unchecked")
>> T t = returnedType.cast(this.root);
>> return t;
>
> I would go a bit further and say that @SuppressWarnings should not be
> used unless you can prove that the cast is always valid (as may well
> be the case here - I've not checked), and that this should be
> documented in a // comment on the annotation, e.g.
>
> @SuppressWarnings("unchecked") // OK because etc.
>
> Otherwise, the annotation effectively gives the compiler permission to
> cause a ClassCastException somewhere else at some point in the future.
>
> As with many forms of suppression, the risk is that there will be a
> bad reaction later ...
>
>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by sebb <se...@gmail.com>.
On 1 March 2011 08:00, Jörg Schaible <jo...@scalaris.com> wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
> [snip]
>
>
>> @SuppressWarnings("unchecked")
>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>> IOException, SAXException {
>> .
>> .
>> .
>> return returnedType.cast(this.root);
>> }
>
> It would be nice, if we can start to avoid such method global suppressions,
> because it hides possibly unwanted stuff. You can always assign the
> annotation directly to a variable instead:
>
> @SuppressWarnings("unchecked")
> T t = returnedType.cast(this.root);
> return t;
I would go a bit further and say that @SuppressWarnings should not be
used unless you can prove that the cast is always valid (as may well
be the case here - I've not checked), and that this should be
documented in a // comment on the annotation, e.g.
@SuppressWarnings("unchecked") // OK because etc.
Otherwise, the annotation effectively gives the compiler permission to
cause a ClassCastException somewhere else at some point in the future.
As with many forms of suppression, the risk is that there will be a
bad reaction later ...
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Matt Benson <gu...@gmail.com>.
On Tue, Mar 1, 2011 at 2:30 AM, Simone Tripodi <si...@apache.org> wrote:
> Hello Jorg,
> absolutely, thanks a lot for your feedback too, very appreciated!
Point taken, +1.
Matt
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 9:00 AM, Jörg Schaible
> <jo...@scalaris.com> wrote:
>> Hi Simone,
>>
>> Simone Tripodi wrote:
>>
>> [snip]
>>
>>
>>> @SuppressWarnings("unchecked")
>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>> IOException, SAXException {
>>> .
>>> .
>>> .
>>> return returnedType.cast(this.root);
>>> }
>>
>> It would be nice, if we can start to avoid such method global suppressions,
>> because it hides possibly unwanted stuff. You can always assign the
>> annotation directly to a variable instead:
>>
>> @SuppressWarnings("unchecked")
>> T t = returnedType.cast(this.root);
>> return t;
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Posted by Simone Tripodi <si...@apache.org>.
Hello Jorg,
absolutely, thanks a lot for your feedback too, very appreciated!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Mar 1, 2011 at 9:00 AM, Jörg Schaible
<jo...@scalaris.com> wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
> [snip]
>
>
>> @SuppressWarnings("unchecked")
>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>> IOException, SAXException {
>> .
>> .
>> .
>> return returnedType.cast(this.root);
>> }
>
> It would be nice, if we can start to avoid such method global suppressions,
> because it hides possibly unwanted stuff. You can always assign the
> annotation directly to a variable instead:
>
> @SuppressWarnings("unchecked")
> T t = returnedType.cast(this.root);
> return t;
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org