Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [classlib] Getting more real JAPI results
Date: Fri, 24 Nov 2006 11:06:56 +0300
Message-ID: <8E389A5F2FEABA4CB1DEC35A25CB39CE7834F5@mssmsx411>
Thread-Topic: [classlib] Getting more real JAPI results
Thread-Index: AccPns9d6Pwpx4S1SEOuaP9UmscquAAAF6FA
From: "Ivanov, Alexey A" <alexey.a.ivanov@intel.com>
To: <dev@harmony.apache.org>

>-----Original Message-----
>From: Mikhail Loenko [mailto:mloenko@gmail.com]
>Sent: Friday, November 24, 2006 10:54 AM
>To: dev@harmony.apache.org
>Subject: Re: [classlib] Getting more real JAPI results
>
>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

To my understanding these methods are implemented then.

AFAIK we talk about those methods which are *real* stubs, then such
methods should also be marked with throws NotImplementedException.

Does it make sense?

Regards,
Alexey.


>
>2006/11/24, Mikhail Loenko <mloenko@gmail.com>:
>> I'm sorry but I completely don't understand what you mean
>>
>> 2006/11/24, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
>> > 2006/11/24, Mikhail Loenko <mloenko@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 <alexey.a.petrenko@gmail.com>:
>> > > > 2006/11/24, Mikhail Loenko <mloenko@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 <mloenko@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 =3D 12;// confounder(8)+CRC-32
checksum(4)
>> > > > > >                // copy of original key
>> > > > > >                initCipherState =3D new
>IvParameterSpec(key.getEncoded());
>> > > > > >                break;
>> > > > > >            case DES_CBC_MD4:
>> > > > > >            case DES_CBC_MD5:
>> > > > > >                offset =3D 24;// confounder(8)+ MD4/5
checksum(16)
>> > > > > >                // all-zero
>> > > > > >                initCipherState =3D 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.p.ellison@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.
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division