Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 24346 invoked from network); 11 May 2005 11:08:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 May 2005 11:08:09 -0000 Received: (qmail 99757 invoked by uid 500); 11 May 2005 11:11:40 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 99648 invoked by uid 500); 11 May 2005 11:11:39 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 99620 invoked by uid 99); 11 May 2005 11:11:38 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of kumpera@gmail.com designates 64.233.170.203 as permitted sender) Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.203) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 11 May 2005 04:11:38 -0700 Received: by rproxy.gmail.com with SMTP id c16so43428rne for ; Wed, 11 May 2005 04:07:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=shsff8CyR3Kl8N4BqXQHPg7zyNVBTPJLgc8eD0XV+SMryd8xE8/uZaKh2NbxDRZPVX/7fdyJ6WPWOHxNS8GjFARoX+YE+a7tlAaxfB//wvy38bEUoYHYBEtwsq1ww/BecAOWXyjaVXTSKLlRxx4DWVSRfoaLZbx9A1RizB8lT3A= Received: by 10.38.153.45 with SMTP id a45mr190523rne; Wed, 11 May 2005 04:07:49 -0700 (PDT) Received: by 10.38.90.73 with HTTP; Wed, 11 May 2005 04:07:48 -0700 (PDT) Message-ID: <8cca42d8050511040729e58218@mail.gmail.com> Date: Wed, 11 May 2005 08:07:48 -0300 From: Rodrigo Kumpera Reply-To: Rodrigo Kumpera To: harmony-dev@incubator.apache.org, FaeLLe Subject: Re: Java Security for Harmony In-Reply-To: <50088f920505110353a52c0eb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <5f21a0a9577705abd531cebc48d11085@earthlink.net> <42807005.4070500@algroup.co.uk> <01f801c55541$f26d9430$8400000a@MEANMACHINE> <4280D63C.2060801@algroup.co.uk> <4281D36A.3090303@algroup.co.uk> <1115808071.4765.153.camel@localhost.localdomain> <4281E2A4.9030306@algroup.co.uk> <50088f920505110353a52c0eb@mail.gmail.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N The verifier is part of the the class loading process, it's the first step of linking a class to the runtime. More about that can be found in [1], but the verifier makes sure that a given piece of bytecode won't mess up the stack or incorrectly use types. Rodrigo [1] The Java Virtual Machine Specification, Second Edition On 5/11/05, FaeLLe wrote: > So byte code verification can occur at runtime and still be a confronting > implementation ? >=20 > I think it would make since as long as it occurs because even J2ME pre > verifies (as i guess you guys know) and that is accepted at run time as l= ong > as it remains in that state. >=20 >=20 > On 5/11/05, Ben Laurie wrote: > > > > Anthony Green wrote: > > > On Wed, 2005-05-11 at 10:42 +0100, Ben Laurie wrote: > > > > > >>I'm more interested in the modularity with this question - by the sou= nd > > >>of it, the verifier is an optional module. > > > > > > > > > No, a conforming implementation requires a bytecode verifier. > > > > I thought we'd established that it didn't? That is, verification must > > occur, but it can occur at runtime. > > > > -- > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/ > > > > "There is no limit to what a man can do or how far he can go if he > > doesn't mind who gets the credit." - Robert Woodruff > > >=20 > -- > www.FaeLLe.com >=20 >