You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2008/10/05 16:27:10 UTC
[compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?
Hey there
> Out of curiosity why must reflection be used for the create*Stream()
> methods in the ArchiveStreamFactory and CompressorStreamFactory?
> There is a cast at the end of each method to a corresponding
> interface anyway (ex ArchiveInputStream, ArchiveOutputStream, etc)
> so why cant we use this knowledge ahead of time and execute on the
> interface?
I think the idea that it makes "dropping in" a new implementation
easier. But I agree with you.
As the registerArchive*Stream methods need to be called to register
the implementation this becomes a moo point.
I would change the factory to
public ArchiveInputStream createArchiveInputStream( final String
archiverName, final InputStream stream ) throws ArchiveException {
if ("ar".equals(archiverName)) {
return new ArAchiveInputStream(stream)
}
..
return null;
}
and then instead of registering a new implementation you just extend
the factory and overload the create*Stream methods to add your custom
impl ...and of course delegate to the super class.
> The current implementation makes it next to impossible to capture
> errors being thrown by the constructors of new implementations since
> the reflective methods discard any Exceptions and simply return null.
Hm ... I thought that would be indeed possible:
http://java.sun.com/docs/books/tutorial/reflect/member/ctorTrouble.html
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?
Posted by Torsten Curdt <tc...@apache.org>.
Applied! (Only modified slightly) Thanks!
On Wed, Jan 7, 2009 at 07:31, Christian Grobmeier <gr...@gmail.com> wrote:
> Hi,
> sorry for beeing late :-)
>
>> I guess we could also just get rid of the reflection. What do you think?
>
> I think this is good. I have attached a patch to:
> https://issues.apache.org/jira/browse/SANDBOX-262
> which eliminates the reflection usage in both factories.
>
> Can sombody (Torsten? :-)) please review the patch and apply it, if it is ok?
>
> Thanks,
> Christian
>
> ---------------------------------------------------------------------
> 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: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?
Posted by Christian Grobmeier <gr...@gmail.com>.
Hi,
sorry for beeing late :-)
> I guess we could also just get rid of the reflection. What do you think?
I think this is good. I have attached a patch to:
https://issues.apache.org/jira/browse/SANDBOX-262
which eliminates the reflection usage in both factories.
Can sombody (Torsten? :-)) please review the patch and apply it, if it is ok?
Thanks,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?
Posted by Torsten Curdt <tc...@vafer.org>.
> I will fix it up and suggest a patch to bring it to a workable state.
I guess we could also just get rid of the reflection. What do you think?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] What is the purpose of the reflection usage in ArchiveStreamFactory and CompressorStreamFactory?
Posted by Timothy James Pinet <tp...@zenasus.com>.
Reflection does handle checked exceptions for Constructor.newInstance() and
this is handled appropriately for:
public ArchiveInputStream createArchiveInputStream( final String
archiverName, final InputStream out ) throws ArchiveException {...}
However, the other method:
public ArchiveInputStream createArchiveInputStream( final InputStream
input ) throws IOException {...}
is not implemented to handle checked constructor exceptions since all
Exception catches are not handled. It looks as though this method was not
completed. I will fix it up and suggest a patch to bring it to a workable
state.
Thanks,
Tim
--------------------------------------------------
From: "Torsten Curdt" <tc...@apache.org>
Sent: Sunday, October 05, 2008 10:27 AM
To: "Commons Developers List" <de...@commons.apache.org>
Subject: [compress] What is the purpose of the reflection usage in
ArchiveStreamFactory and CompressorStreamFactory?
> Hey there
>
>> Out of curiosity why must reflection be used for the create*Stream()
>> methods in the ArchiveStreamFactory and CompressorStreamFactory? There
>> is a cast at the end of each method to a corresponding interface anyway
>> (ex ArchiveInputStream, ArchiveOutputStream, etc) so why cant we use
>> this knowledge ahead of time and execute on the interface?
>
> I think the idea that it makes "dropping in" a new implementation easier.
> But I agree with you.
>
> As the registerArchive*Stream methods need to be called to register the
> implementation this becomes a moo point.
>
> I would change the factory to
>
> public ArchiveInputStream createArchiveInputStream( final String
> archiverName, final InputStream stream ) throws ArchiveException {
>
> if ("ar".equals(archiverName)) {
> return new ArAchiveInputStream(stream)
> }
>
> ..
>
> return null;
> }
>
> and then instead of registering a new implementation you just extend the
> factory and overload the create*Stream methods to add your custom impl
> ...and of course delegate to the super class.
>
>> The current implementation makes it next to impossible to capture errors
>> being thrown by the constructors of new implementations since the
>> reflective methods discard any Exceptions and simply return null.
>
> Hm ... I thought that would be indeed possible:
>
> http://java.sun.com/docs/books/tutorial/reflect/member/ctorTrouble.html
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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