You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/11/23 09:37:54 UTC
[classlib] Getting more real JAPI results
There is a simple way to make japi happy and show those nice 100% green
bars: write a stub method and throw a runtime exception when invoked.
Unfortunately, it's not going to fool the TCK or, worse, it's not going
to please our users when they get RuntimeException telling them that
their app won't run because the method is not implemented.
I've written a script that uses brute force across the entire classlib
to figure out if a method was not implemented, the result can be found at:
http://67.86.14.213:10000/results/latest/notimplemented.html
as of today, there are 615 methods (mostly in swing, awt, imageio and
sound) that are not implemented, in 64 different classes.
There is a wide range of ways that we use to throw the fact that the
method is not implemented, namely:
throw new Error("ComponentUI.createUI not implemented");
throw new Error("getHelpMenu() hasn't been implemented yet");
throw new Error("not yet implemented");
throw new Error("Not yet implemented");
throw new Error("setHelpMenu() hasn't been implemented yet");
throw new IllegalArgumentException("method is not implemented");
throw new LoginException();//FIXME not yet implemented
throw new RuntimeException();//FIXME not implemented yet
throw new RuntimeException("Is not implemented yet"); //FIXME
throw new RuntimeException("KerberosErrorMessage encoder is not
implemented");
throw new RuntimeException("Method is not implemented");
throw new RuntimeException("Not implemented");
throw new SocketException("Unbound server socket: not implemented");
throw new SocketException("Unbound socket: not implemented");
throw new UnsupportedOperationException("not implemented");
throw new UnsupportedOperationException("Not implemented");
throw new UnsupportedOperationException("Not implemented tag: " + tag);
throw new UnsupportedOperationException("not implemented yet");
throw new UnsupportedOperationException("Not implemented yet");
throw new UnsupportedOperationException("Not yet implemented");
JAPI is designed to support looking into methods that throw an exception
that ends with .NotImplementedException. Such an exception actually
exists in our classlib
modules/luni/src/main/java/org/apache/harmony/luni/util/NotImplementedException.java
but the only class that uses it, it's a test that tests the exception
itself. Not that useful.
It doesn't help us if we cheat on JAPI results, sooner or later we'll
have to work on those methods anyway, so it's better to keep them
visible in our API coverage reports so that it's easier for volunteers
to know where to donate their work.
I propose that we change all those exception into
o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
show us real results and we do it sooner rather than later.
Thoughts?
--
Stefano.
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
I'll take AWT.
2006/11/23, Alexey Petrenko <al...@gmail.com>:
> Let's do that!
> Volunteers?
>
> SY, Alexey
>
> 2006/11/23, Stefano Mazzocchi <st...@apache.org>:
> > There is a simple way to make japi happy and show those nice 100% green
> > bars: write a stub method and throw a runtime exception when invoked.
> >
> > Unfortunately, it's not going to fool the TCK or, worse, it's not going
> > to please our users when they get RuntimeException telling them that
> > their app won't run because the method is not implemented.
> >
> > I've written a script that uses brute force across the entire classlib
> > to figure out if a method was not implemented, the result can be found at:
> >
> > http://67.86.14.213:10000/results/latest/notimplemented.html
> >
> > as of today, there are 615 methods (mostly in swing, awt, imageio and
> > sound) that are not implemented, in 64 different classes.
> >
> > There is a wide range of ways that we use to throw the fact that the
> > method is not implemented, namely:
> >
> > throw new Error("ComponentUI.createUI not implemented");
> > throw new Error("getHelpMenu() hasn't been implemented yet");
> > throw new Error("not yet implemented");
> > throw new Error("Not yet implemented");
> > throw new Error("setHelpMenu() hasn't been implemented yet");
> > throw new IllegalArgumentException("method is not implemented");
> > throw new LoginException();//FIXME not yet implemented
> > throw new RuntimeException();//FIXME not implemented yet
> > throw new RuntimeException("Is not implemented yet"); //FIXME
> > throw new RuntimeException("KerberosErrorMessage encoder is not
> > implemented");
> > throw new RuntimeException("Method is not implemented");
> > throw new RuntimeException("Not implemented");
> > throw new SocketException("Unbound server socket: not implemented");
> > throw new SocketException("Unbound socket: not implemented");
> > throw new UnsupportedOperationException("not implemented");
> > throw new UnsupportedOperationException("Not implemented");
> > throw new UnsupportedOperationException("Not implemented tag: " + tag);
> > throw new UnsupportedOperationException("not implemented yet");
> > throw new UnsupportedOperationException("Not implemented yet");
> > throw new UnsupportedOperationException("Not yet implemented");
> >
> > JAPI is designed to support looking into methods that throw an exception
> > that ends with .NotImplementedException. Such an exception actually
> > exists in our classlib
> >
> > modules/luni/src/main/java/org/apache/harmony/luni/util/NotImplementedException.java
> >
> > but the only class that uses it, it's a test that tests the exception
> > itself. Not that useful.
> >
> > It doesn't help us if we cheat on JAPI results, sooner or later we'll
> > have to work on those methods anyway, so it's better to keep them
> > visible in our API coverage reports so that it's easier for volunteers
> > to know where to donate their work.
> >
> > I propose that we change all those exception into
> > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > show us real results and we do it sooner rather than later.
> >
> > Thoughts?
> >
> > --
> > Stefano.
> >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
Let's do that!
Volunteers?
SY, Alexey
2006/11/23, Stefano Mazzocchi <st...@apache.org>:
> There is a simple way to make japi happy and show those nice 100% green
> bars: write a stub method and throw a runtime exception when invoked.
>
> Unfortunately, it's not going to fool the TCK or, worse, it's not going
> to please our users when they get RuntimeException telling them that
> their app won't run because the method is not implemented.
>
> I've written a script that uses brute force across the entire classlib
> to figure out if a method was not implemented, the result can be found at:
>
> http://67.86.14.213:10000/results/latest/notimplemented.html
>
> as of today, there are 615 methods (mostly in swing, awt, imageio and
> sound) that are not implemented, in 64 different classes.
>
> There is a wide range of ways that we use to throw the fact that the
> method is not implemented, namely:
>
> throw new Error("ComponentUI.createUI not implemented");
> throw new Error("getHelpMenu() hasn't been implemented yet");
> throw new Error("not yet implemented");
> throw new Error("Not yet implemented");
> throw new Error("setHelpMenu() hasn't been implemented yet");
> throw new IllegalArgumentException("method is not implemented");
> throw new LoginException();//FIXME not yet implemented
> throw new RuntimeException();//FIXME not implemented yet
> throw new RuntimeException("Is not implemented yet"); //FIXME
> throw new RuntimeException("KerberosErrorMessage encoder is not
> implemented");
> throw new RuntimeException("Method is not implemented");
> throw new RuntimeException("Not implemented");
> throw new SocketException("Unbound server socket: not implemented");
> throw new SocketException("Unbound socket: not implemented");
> throw new UnsupportedOperationException("not implemented");
> throw new UnsupportedOperationException("Not implemented");
> throw new UnsupportedOperationException("Not implemented tag: " + tag);
> throw new UnsupportedOperationException("not implemented yet");
> throw new UnsupportedOperationException("Not implemented yet");
> throw new UnsupportedOperationException("Not yet implemented");
>
> JAPI is designed to support looking into methods that throw an exception
> that ends with .NotImplementedException. Such an exception actually
> exists in our classlib
>
> modules/luni/src/main/java/org/apache/harmony/luni/util/NotImplementedException.java
>
> but the only class that uses it, it's a test that tests the exception
> itself. Not that useful.
>
> It doesn't help us if we cheat on JAPI results, sooner or later we'll
> have to work on those methods anyway, so it's better to keep them
> visible in our API coverage reports so that it's easier for volunteers
> to know where to donate their work.
>
> I propose that we change all those exception into
> o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> show us real results and we do it sooner rather than later.
>
> Thoughts?
>
> --
> Stefano.
>
>
Re: [classlib] Getting more real JAPI results
Posted by Tim Ellison <t....@gmail.com>.
Chris Gray wrote:
> On Friday 24 November 2006 09:05, Alexey Petrenko wrote:
>> So they are implemented :)
>> And that specific messages are "not implemented"?
>>
>> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
>>> I'll try to answer according to my understanding of your question :)
>>>
>>> these are abstract classes that have some non-abstract methods. These
>>> methods throw specific exception with specific messages on RI. We do
>>> the same
>
> I think this pattern turns up in several places; a method is "intended" to be
> overridden, and the spec specifically says that the default implementation is
> an exception-throwing stub. If a team of volunteers is going to walk the
> whole source tree looking for stub methods, they should probably put a
> standard comment line (e.g. "stub as per spec") on every method which is
> examined and found not to need NotImplementedException. Just to prevent this
> discussion from being repeated ...
lol - now you know why I don't like stubs :-)
I agree, best to leave a marker in both cases now.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] Getting more real JAPI results
Posted by Chris Gray <ch...@kiffer.be>.
On Friday 24 November 2006 09:05, Alexey Petrenko wrote:
> So they are implemented :)
> And that specific messages are "not implemented"?
>
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > I'll try to answer according to my understanding of your question :)
> >
> > these are abstract classes that have some non-abstract methods. These
> > methods throw specific exception with specific messages on RI. We do
> > the same
I think this pattern turns up in several places; a method is "intended" to be
overridden, and the spec specifically says that the default implementation is
an exception-throwing stub. If a team of volunteers is going to walk the
whole source tree looking for stub methods, they should probably put a
standard comment line (e.g. "stub as per spec") on every method which is
examined and found not to need NotImplementedException. Just to prevent this
discussion from being repeated ...
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
Note: our official registered address has changed from
Paleisstraat 119 to Koningstraat 21, 2000 Antwerpen. The
operational address Bredestraat 4 remains valid, as do
all telephone and fax numbers (and the VAT reg. number).
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
it's not by spec, it's by actual RI behavior. I've put a comment there
2006/11/24, Alexey Petrenko <al...@gmail.com>:
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > So they are implemented :)
> > > And that specific messages are "not implemented"?
> > exactly :)
> Great! :)
> So please mark them as "not implemented by spec" :)
>
> > >
> > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > I'll try to answer according to my understanding of your question :)
> > > >
> > > > these are abstract classes that have some non-abstract methods. These
> > > > methods throw specific exception with specific messages on RI. We do
> > > > the same
> > > >
> > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > I'm sorry but I completely don't understand what you mean
> > > > >
> > > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > why not what?
> > > > > > > current behavior should be preserved because it corresponds to RI
> > > > > > Some methods there are not implemented too?
> > > > > >
> > > > > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > > > > > it throws just what RI throws
> > > > > > > > Why not?
> > > > > > > >
> > > > > > > > > I'll take a look at sound
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Mikhail
> > > > > > > > >
> > > > > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > > > > > affect JAPI reports.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > > > > > >
> > > > > > > > > > IvParameterSpec initCipherState;
> > > > > > > > > > switch (etype) {
> > > > > > > > > > case DES_CBC_CRC:
> > > > > > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > > > > > // copy of original key
> > > > > > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > > > > > break;
> > > > > > > > > > case DES_CBC_MD4:
> > > > > > > > > > case DES_CBC_MD5:
> > > > > > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > > > > > // all-zero
> > > > > > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > > > > > break;
> > > > > > > > > > default:
> > > > > > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Mikhail
> > > > > > > > > >
> > > > > > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > > > > > I propose that we change all those exception into
> > > > > > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > > > > > >
> > > > > > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > > > > > back and fill them in.
> > > > > > > > > > >
> > > > > > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Tim
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > >
> > > > > > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > > > > > IBM Java technology centre, UK.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Stefano Mazzocchi <st...@apache.org>.
Alexey Petrenko wrote:
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
>> 2006/11/24, Alexey Petrenko <al...@gmail.com>:
>> > So they are implemented :)
>> > And that specific messages are "not implemented"?
>> exactly :)
> Great! :)
> So please mark them as "not implemented by spec" :)
"not supported", we should keep "implemented" as a flag for API
signature and "supported" for the rest... so it's easier for me to write
the scripts that check all this :-)
--
Stefano.
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > So they are implemented :)
> > And that specific messages are "not implemented"?
> exactly :)
Great! :)
So please mark them as "not implemented by spec" :)
> >
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > I'll try to answer according to my understanding of your question :)
> > >
> > > these are abstract classes that have some non-abstract methods. These
> > > methods throw specific exception with specific messages on RI. We do
> > > the same
> > >
> > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > I'm sorry but I completely don't understand what you mean
> > > >
> > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > why not what?
> > > > > > current behavior should be preserved because it corresponds to RI
> > > > > Some methods there are not implemented too?
> > > > >
> > > > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > > > > it throws just what RI throws
> > > > > > > Why not?
> > > > > > >
> > > > > > > > I'll take a look at sound
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Mikhail
> > > > > > > >
> > > > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > > > > affect JAPI reports.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > > > > >
> > > > > > > > > IvParameterSpec initCipherState;
> > > > > > > > > switch (etype) {
> > > > > > > > > case DES_CBC_CRC:
> > > > > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > > > > // copy of original key
> > > > > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > > > > break;
> > > > > > > > > case DES_CBC_MD4:
> > > > > > > > > case DES_CBC_MD5:
> > > > > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > > > > // all-zero
> > > > > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > > > > break;
> > > > > > > > > default:
> > > > > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Mikhail
> > > > > > > > >
> > > > > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > > > > I propose that we change all those exception into
> > > > > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > > > > >
> > > > > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > > > > back and fill them in.
> > > > > > > > > >
> > > > > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Tim
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > > > > IBM Java technology centre, UK.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/11/24, Alexey Petrenko <al...@gmail.com>:
> So they are implemented :)
> And that specific messages are "not implemented"?
exactly :)
>
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > I'll try to answer according to my understanding of your question :)
> >
> > these are abstract classes that have some non-abstract methods. These
> > methods throw specific exception with specific messages on RI. We do
> > the same
> >
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > I'm sorry but I completely don't understand what you mean
> > >
> > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > why not what?
> > > > > current behavior should be preserved because it corresponds to RI
> > > > Some methods there are not implemented too?
> > > >
> > > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > > > it throws just what RI throws
> > > > > > Why not?
> > > > > >
> > > > > > > I'll take a look at sound
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mikhail
> > > > > > >
> > > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > > > affect JAPI reports.
> > > > > > > >
> > > > > > > >
> > > > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > > > >
> > > > > > > > IvParameterSpec initCipherState;
> > > > > > > > switch (etype) {
> > > > > > > > case DES_CBC_CRC:
> > > > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > > > // copy of original key
> > > > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > > > break;
> > > > > > > > case DES_CBC_MD4:
> > > > > > > > case DES_CBC_MD5:
> > > > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > > > // all-zero
> > > > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > > > break;
> > > > > > > > default:
> > > > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Mikhail
> > > > > > > >
> > > > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > > > I propose that we change all those exception into
> > > > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > > > >
> > > > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > > > back and fill them in.
> > > > > > > > >
> > > > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Tim
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > > > IBM Java technology centre, UK.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
So they are implemented :)
And that specific messages are "not implemented"?
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> I'll try to answer according to my understanding of your question :)
>
> these are abstract classes that have some non-abstract methods. These
> methods throw specific exception with specific messages on RI. We do
> the same
>
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > I'm sorry but I completely don't understand what you mean
> >
> > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > why not what?
> > > > current behavior should be preserved because it corresponds to RI
> > > Some methods there are not implemented too?
> > >
> > > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > > it throws just what RI throws
> > > > > Why not?
> > > > >
> > > > > > I'll take a look at sound
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > > affect JAPI reports.
> > > > > > >
> > > > > > >
> > > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > > >
> > > > > > > IvParameterSpec initCipherState;
> > > > > > > switch (etype) {
> > > > > > > case DES_CBC_CRC:
> > > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > > // copy of original key
> > > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > > break;
> > > > > > > case DES_CBC_MD4:
> > > > > > > case DES_CBC_MD5:
> > > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > > // all-zero
> > > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > > break;
> > > > > > > default:
> > > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mikhail
> > > > > > >
> > > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > > I propose that we change all those exception into
> > > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > > >
> > > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > > back and fill them in.
> > > > > > > >
> > > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Tim
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > > IBM Java technology centre, UK.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
I'll try to answer according to my understanding of your question :)
these are abstract classes that have some non-abstract methods. These
methods throw specific exception with specific messages on RI. We do
the same
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> I'm sorry but I completely don't understand what you mean
>
> 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > why not what?
> > > current behavior should be preserved because it corresponds to RI
> > Some methods there are not implemented too?
> >
> > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > it throws just what RI throws
> > > > Why not?
> > > >
> > > > > I'll take a look at sound
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > affect JAPI reports.
> > > > > >
> > > > > >
> > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > >
> > > > > > IvParameterSpec initCipherState;
> > > > > > switch (etype) {
> > > > > > case DES_CBC_CRC:
> > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > // copy of original key
> > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > break;
> > > > > > case DES_CBC_MD4:
> > > > > > case DES_CBC_MD5:
> > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > // all-zero
> > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > break;
> > > > > > default:
> > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > I propose that we change all those exception into
> > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > >
> > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > back and fill them in.
> > > > > > >
> > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > >
> > > > > > > Regards,
> > > > > > > Tim
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > IBM Java technology centre, UK.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
We are talking about marking not implemented methods with
NotImplementedException. Right?
You said:
> x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> it throws just what RI throws
And I asked: "Why not to mark unimplemented methods in x-net?"
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> I'm sorry but I completely don't understand what you mean
>
> 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > why not what?
> > > current behavior should be preserved because it corresponds to RI
> > Some methods there are not implemented too?
> >
> > > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > > it throws just what RI throws
> > > > Why not?
> > > >
> > > > > I'll take a look at sound
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > > affect JAPI reports.
> > > > > >
> > > > > >
> > > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > > >
> > > > > > IvParameterSpec initCipherState;
> > > > > > switch (etype) {
> > > > > > case DES_CBC_CRC:
> > > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > > // copy of original key
> > > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > > break;
> > > > > > case DES_CBC_MD4:
> > > > > > case DES_CBC_MD5:
> > > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > > // all-zero
> > > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > > break;
> > > > > > default:
> > > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > > Stefano Mazzocchi wrote:
> > > > > > > > I propose that we change all those exception into
> > > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > > show us real results and we do it sooner rather than later.
> > > > > > >
> > > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > > back and fill them in.
> > > > > > >
> > > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > > >
> > > > > > > Regards,
> > > > > > > Tim
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > > IBM Java technology centre, UK.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
I'm sorry but I completely don't understand what you mean
2006/11/24, Alexey Petrenko <al...@gmail.com>:
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > why not what?
> > current behavior should be preserved because it corresponds to RI
> Some methods there are not implemented too?
>
> > 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > > it throws just what RI throws
> > > Why not?
> > >
> > > > I'll take a look at sound
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > > affect JAPI reports.
> > > > >
> > > > >
> > > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > > >
> > > > > IvParameterSpec initCipherState;
> > > > > switch (etype) {
> > > > > case DES_CBC_CRC:
> > > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > > // copy of original key
> > > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > > break;
> > > > > case DES_CBC_MD4:
> > > > > case DES_CBC_MD5:
> > > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > > // all-zero
> > > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > > break;
> > > > > default:
> > > > > throw new RuntimeException();//FIXME not implemented yet
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > > Stefano Mazzocchi wrote:
> > > > > > > I propose that we change all those exception into
> > > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > > show us real results and we do it sooner rather than later.
> > > > > >
> > > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > > back and fill them in.
> > > > > >
> > > > > > I agree that we should mark them as throwing the runtime exception
> > > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > > >
> > > > > > Regards,
> > > > > > Tim
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > > IBM Java technology centre, UK.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> why not what?
> current behavior should be preserved because it corresponds to RI
Some methods there are not implemented too?
> 2006/11/24, Alexey Petrenko <al...@gmail.com>:
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > > it throws just what RI throws
> > Why not?
> >
> > > I'll take a look at sound
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > > Shoud we change that in org.apache.harmony namespace? These don't
> > > > affect JAPI reports.
> > > >
> > > >
> > > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > > >
> > > > IvParameterSpec initCipherState;
> > > > switch (etype) {
> > > > case DES_CBC_CRC:
> > > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > > // copy of original key
> > > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > > break;
> > > > case DES_CBC_MD4:
> > > > case DES_CBC_MD5:
> > > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > > // all-zero
> > > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > > 0, 0, 0, 0, 0, 0, 0, });
> > > > break;
> > > > default:
> > > > throw new RuntimeException();//FIXME not implemented yet
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > > Stefano Mazzocchi wrote:
> > > > > > I propose that we change all those exception into
> > > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > > show us real results and we do it sooner rather than later.
> > > > >
> > > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > > but I recognize that some people prefer to define all the stubs then go
> > > > > back and fill them in.
> > > > >
> > > > > I agree that we should mark them as throwing the runtime exception
> > > > > org.apache.harmony.luni.util.NotImplementedException
> > > > >
> > > > > Regards,
> > > > > Tim
> > > > >
> > > > > --
> > > > >
> > > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > > IBM Java technology centre, UK.
> > > > >
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
why not what?
current behavior should be preserved because it corresponds to RI
Thanks,
Mikhail
2006/11/24, Alexey Petrenko <al...@gmail.com>:
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> > it throws just what RI throws
> Why not?
>
> > I'll take a look at sound
> >
> > Thanks,
> > Mikhail
> >
> > 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > > Shoud we change that in org.apache.harmony namespace? These don't
> > > affect JAPI reports.
> > >
> > >
> > > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> > >
> > > IvParameterSpec initCipherState;
> > > switch (etype) {
> > > case DES_CBC_CRC:
> > > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > > // copy of original key
> > > initCipherState = new IvParameterSpec(key.getEncoded());
> > > break;
> > > case DES_CBC_MD4:
> > > case DES_CBC_MD5:
> > > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > > // all-zero
> > > initCipherState = new IvParameterSpec(new byte[] { 0,
> > > 0, 0, 0, 0, 0, 0, 0, });
> > > break;
> > > default:
> > > throw new RuntimeException();//FIXME not implemented yet
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > > Stefano Mazzocchi wrote:
> > > > > I propose that we change all those exception into
> > > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > > show us real results and we do it sooner rather than later.
> > > >
> > > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > > but I recognize that some people prefer to define all the stubs then go
> > > > back and fill them in.
> > > >
> > > > I agree that we should mark them as throwing the runtime exception
> > > > org.apache.harmony.luni.util.NotImplementedException
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
> it throws just what RI throws
Why not?
> I'll take a look at sound
>
> Thanks,
> Mikhail
>
> 2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> > Shoud we change that in org.apache.harmony namespace? These don't
> > affect JAPI reports.
> >
> >
> > org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
> >
> > IvParameterSpec initCipherState;
> > switch (etype) {
> > case DES_CBC_CRC:
> > offset = 12;// confounder(8)+CRC-32 checksum(4)
> > // copy of original key
> > initCipherState = new IvParameterSpec(key.getEncoded());
> > break;
> > case DES_CBC_MD4:
> > case DES_CBC_MD5:
> > offset = 24;// confounder(8)+ MD4/5 checksum(16)
> > // all-zero
> > initCipherState = new IvParameterSpec(new byte[] { 0,
> > 0, 0, 0, 0, 0, 0, 0, });
> > break;
> > default:
> > throw new RuntimeException();//FIXME not implemented yet
> >
> > Thanks,
> > Mikhail
> >
> > 2006/11/23, Tim Ellison <t....@gmail.com>:
> > > Stefano Mazzocchi wrote:
> > > > I propose that we change all those exception into
> > > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > > show us real results and we do it sooner rather than later.
> > >
> > > Agreed. I don't like stubs (unless required for compiling other stuff),
> > > but I recognize that some people prefer to define all the stubs then go
> > > back and fill them in.
> > >
> > > I agree that we should mark them as throwing the runtime exception
> > > org.apache.harmony.luni.util.NotImplementedException
> > >
> > > Regards,
> > > Tim
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
x-net should also not be replaced with o.a.h.luni.util.NotImplementeException:
it throws just what RI throws
I'll take a look at sound
Thanks,
Mikhail
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> Shoud we change that in org.apache.harmony namespace? These don't
> affect JAPI reports.
>
>
> org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
>
> IvParameterSpec initCipherState;
> switch (etype) {
> case DES_CBC_CRC:
> offset = 12;// confounder(8)+CRC-32 checksum(4)
> // copy of original key
> initCipherState = new IvParameterSpec(key.getEncoded());
> break;
> case DES_CBC_MD4:
> case DES_CBC_MD5:
> offset = 24;// confounder(8)+ MD4/5 checksum(16)
> // all-zero
> initCipherState = new IvParameterSpec(new byte[] { 0,
> 0, 0, 0, 0, 0, 0, 0, });
> break;
> default:
> throw new RuntimeException();//FIXME not implemented yet
>
> Thanks,
> Mikhail
>
> 2006/11/23, Tim Ellison <t....@gmail.com>:
> > Stefano Mazzocchi wrote:
> > > I propose that we change all those exception into
> > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > show us real results and we do it sooner rather than later.
> >
> > Agreed. I don't like stubs (unless required for compiling other stuff),
> > but I recognize that some people prefer to define all the stubs then go
> > back and fill them in.
> >
> > I agree that we should mark them as throwing the runtime exception
> > org.apache.harmony.luni.util.NotImplementedException
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Alexey Petrenko <al...@gmail.com>.
2006/11/24, Mikhail Loenko <ml...@gmail.com>:
> Shoud we change that in org.apache.harmony namespace? These don't
> affect JAPI reports.
I do not see any reason for this.
And did not change org.apache classes in awt module.
SY, Alexey
> org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
>
> IvParameterSpec initCipherState;
> switch (etype) {
> case DES_CBC_CRC:
> offset = 12;// confounder(8)+CRC-32 checksum(4)
> // copy of original key
> initCipherState = new IvParameterSpec(key.getEncoded());
> break;
> case DES_CBC_MD4:
> case DES_CBC_MD5:
> offset = 24;// confounder(8)+ MD4/5 checksum(16)
> // all-zero
> initCipherState = new IvParameterSpec(new byte[] { 0,
> 0, 0, 0, 0, 0, 0, 0, });
> break;
> default:
> throw new RuntimeException();//FIXME not implemented yet
>
> Thanks,
> Mikhail
>
> 2006/11/23, Tim Ellison <t....@gmail.com>:
> > Stefano Mazzocchi wrote:
> > > I propose that we change all those exception into
> > > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > > show us real results and we do it sooner rather than later.
> >
> > Agreed. I don't like stubs (unless required for compiling other stuff),
> > but I recognize that some people prefer to define all the stubs then go
> > back and fill them in.
> >
> > I agree that we should mark them as throwing the runtime exception
> > org.apache.harmony.luni.util.NotImplementedException
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
>
Re: [classlib] Getting more real JAPI results
Posted by Stefano Mazzocchi <st...@apache.org>.
Mikhail Loenko wrote:
> Shoud we change that in org.apache.harmony namespace? These don't
> affect JAPI reports.
>
>
> org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
>
> IvParameterSpec initCipherState;
> switch (etype) {
> case DES_CBC_CRC:
> offset = 12;// confounder(8)+CRC-32 checksum(4)
> // copy of original key
> initCipherState = new IvParameterSpec(key.getEncoded());
> break;
> case DES_CBC_MD4:
> case DES_CBC_MD5:
> offset = 24;// confounder(8)+ MD4/5 checksum(16)
> // all-zero
> initCipherState = new IvParameterSpec(new byte[] { 0,
> 0, 0, 0, 0, 0, 0, 0, });
> break;
> default:
> throw new RuntimeException();//FIXME not implemented yet
I suggest we change this last line into
throw new RuntimeException("Cypher type '" + etype + "' currently not
supported."); // FIXME: support more cypher types
"implemented" should be used for stuff that influences our API
signature, "support" for what it influences other optional or non-TCK
related things.
--
Stefano.
Re: [classlib] Getting more real JAPI results
Posted by Mikhail Loenko <ml...@gmail.com>.
Shoud we change that in org.apache.harmony namespace? These don't
affect JAPI reports.
org/apache/harmony/auth/internal/kerberos/v5/EncryptedData.java:
IvParameterSpec initCipherState;
switch (etype) {
case DES_CBC_CRC:
offset = 12;// confounder(8)+CRC-32 checksum(4)
// copy of original key
initCipherState = new IvParameterSpec(key.getEncoded());
break;
case DES_CBC_MD4:
case DES_CBC_MD5:
offset = 24;// confounder(8)+ MD4/5 checksum(16)
// all-zero
initCipherState = new IvParameterSpec(new byte[] { 0,
0, 0, 0, 0, 0, 0, 0, });
break;
default:
throw new RuntimeException();//FIXME not implemented yet
Thanks,
Mikhail
2006/11/23, Tim Ellison <t....@gmail.com>:
> Stefano Mazzocchi wrote:
> > I propose that we change all those exception into
> > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > show us real results and we do it sooner rather than later.
>
> Agreed. I don't like stubs (unless required for compiling other stuff),
> but I recognize that some people prefer to define all the stubs then go
> back and fill them in.
>
> I agree that we should mark them as throwing the runtime exception
> org.apache.harmony.luni.util.NotImplementedException
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib] Getting more real JAPI results
Posted by Nathan Beyer <nb...@gmail.com>.
I concur. Lets mark them with the NIE.
On 11/23/06, Tim Ellison <t....@gmail.com> wrote:
> Stefano Mazzocchi wrote:
> > I propose that we change all those exception into
> > o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> > show us real results and we do it sooner rather than later.
>
> Agreed. I don't like stubs (unless required for compiling other stuff),
> but I recognize that some people prefer to define all the stubs then go
> back and fill them in.
>
> I agree that we should mark them as throwing the runtime exception
> org.apache.harmony.luni.util.NotImplementedException
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib] Getting more real JAPI results
Posted by Tim Ellison <t....@gmail.com>.
Stefano Mazzocchi wrote:
> I propose that we change all those exception into
> o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> show us real results and we do it sooner rather than later.
Agreed. I don't like stubs (unless required for compiling other stuff),
but I recognize that some people prefer to define all the stubs then go
back and fill them in.
I agree that we should mark them as throwing the runtime exception
org.apache.harmony.luni.util.NotImplementedException
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] Getting more real JAPI results
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Stefano Mazzocchi wrote:
>> There is a simple way to make japi happy and show those nice 100% green
>> bars: write a stub method and throw a runtime exception when invoked.
>>
>> Unfortunately, it's not going to fool the TCK or, worse, it's not going
>> to please our users when they get RuntimeException telling them that
>> their app won't run because the method is not implemented.
>
> Why would you want to do this? Having JAPI tell us what's not done is
> the point of JAPI, right?
>
> (Although I'm a compassionate and caring person, I'll admit I'm not
> worried about making JAPI happy...)
I read Stefano's post as "although we /can/ fool JAPI ny creating stubs
we /should not/ do so"
>> I've written a script that uses brute force across the entire classlib
>> to figure out if a method was not implemented, the result can be found
>> at:
>>
>> http://67.86.14.213:10000/results/latest/notimplemented.html
>>
>> as of today, there are 615 methods (mostly in swing, awt, imageio and
>> sound) that are not implemented, in 64 different classes
>
> Cool! But I'm misunderstanding something - why are we fooling JAPI?
Today we are fooling it because there are some stubs in Harmony classlib
code. We need to remove them / flag them to make the JAPI results more
'honest'.
<snip>
>> I propose that we change all those exception into
>> o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
>> show us real results and we do it sooner rather than later.
>>
>> Thoughts?
>
> I don't understand why we're fooling JAPI. I'll read the rest of this
> thread (was offline yesterday for thanksgiving holiday here in the US...)
Hopefully you can see how we are now, and that we don't want to continue
doing so.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] Getting more real JAPI results
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> There is a simple way to make japi happy and show those nice 100% green
> bars: write a stub method and throw a runtime exception when invoked.
>
> Unfortunately, it's not going to fool the TCK or, worse, it's not going
> to please our users when they get RuntimeException telling them that
> their app won't run because the method is not implemented.
Why would you want to do this? Having JAPI tell us what's not done is
the point of JAPI, right?
(Although I'm a compassionate and caring person, I'll admit I'm not
worried about making JAPI happy...)
>
> I've written a script that uses brute force across the entire classlib
> to figure out if a method was not implemented, the result can be found at:
>
> http://67.86.14.213:10000/results/latest/notimplemented.html
>
> as of today, there are 615 methods (mostly in swing, awt, imageio and
> sound) that are not implemented, in 64 different classes
Cool! But I'm misunderstanding something - why are we fooling JAPI?
.
>
> There is a wide range of ways that we use to throw the fact that the
> method is not implemented, namely:
>
> throw new Error("ComponentUI.createUI not implemented");
> throw new Error("getHelpMenu() hasn't been implemented yet");
> throw new Error("not yet implemented");
> throw new Error("Not yet implemented");
> throw new Error("setHelpMenu() hasn't been implemented yet");
> throw new IllegalArgumentException("method is not implemented");
> throw new LoginException();//FIXME not yet implemented
> throw new RuntimeException();//FIXME not implemented yet
> throw new RuntimeException("Is not implemented yet"); //FIXME
> throw new RuntimeException("KerberosErrorMessage encoder is not
> implemented");
> throw new RuntimeException("Method is not implemented");
> throw new RuntimeException("Not implemented");
> throw new SocketException("Unbound server socket: not implemented");
> throw new SocketException("Unbound socket: not implemented");
> throw new UnsupportedOperationException("not implemented");
> throw new UnsupportedOperationException("Not implemented");
> throw new UnsupportedOperationException("Not implemented tag: " + tag);
> throw new UnsupportedOperationException("not implemented yet");
> throw new UnsupportedOperationException("Not implemented yet");
> throw new UnsupportedOperationException("Not yet implemented");
>
> JAPI is designed to support looking into methods that throw an exception
> that ends with .NotImplementedException. Such an exception actually
> exists in our classlib
>
> modules/luni/src/main/java/org/apache/harmony/luni/util/NotImplementedException.java
>
> but the only class that uses it, it's a test that tests the exception
> itself. Not that useful.
>
> It doesn't help us if we cheat on JAPI results, sooner or later we'll
> have to work on those methods anyway, so it's better to keep them
> visible in our API coverage reports so that it's easier for volunteers
> to know where to donate their work.
>
> I propose that we change all those exception into
> o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> show us real results and we do it sooner rather than later.
>
> Thoughts?
I don't understand why we're fooling JAPI. I'll read the rest of this
thread (was offline yesterday for thanksgiving holiday here in the US...)
geir
>