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: domain of mloenko@gmail.com designates
 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RR4VLdAb9sstt/9dEezjvHD+7MK7yhzC1Om44nPwSSbBK5x/TN+PjeNOwrur3NCA4ehnSMkFXFXG/LxXIsXaWCQtrrS2y1Zm8SKPmflN8Pr3Nl1gnrXf/BLKuFmayJTS3/PGrhiwh00ZKfIllHvBO9JDapRNyOT5aZQ8W+Ib23c=
Message-ID: <906dd82e0611232351n16cb12b7u1d0e11a67bfd7cbc@mail.gmail.com>
Date: Fri, 24 Nov 2006 13:51:24 +0600
From: "Mikhail Loenko" <mloenko@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib] Getting more real JAPI results
In-Reply-To: <c3755b3a0611232347r623396ccs15c2222697c395c8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45655DE2.6050407@apache.org> <45657F64.7080800@gmail.com>
	 <906dd82e0611232205y1e042c38nf5152560d38d0715@mail.gmail.com>
	 <906dd82e0611232216n63c3dc54se61d607fe7c9fbc5@mail.gmail.com>
	 <c3755b3a0611232316x50d942e7qf22fee42e4d41c5d@mail.gmail.com>
	 <906dd82e0611232320g5a4d082bw2382c8e011c4f9c6@mail.gmail.com>
	 <c3755b3a0611232347r623396ccs15c2222697c395c8@mail.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 = 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.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.
> > > > > >
> > > > >
> > > >
> > >
> >
>