Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 84118 invoked from network); 27 May 2005 22:25:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 May 2005 22:25:25 -0000 Received: (qmail 39806 invoked by uid 500); 27 May 2005 22:25:21 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 39754 invoked by uid 500); 27 May 2005 22:25:20 -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 39737 invoked by uid 99); 27 May 2005 22:25:20 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from jarnbjo.de (HELO vl11s25.smart-weblications.de) (83.151.18.106) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 27 May 2005 15:25:20 -0700 Received: from p549a7ce1.dip.t-dialin.net ([84.154.124.225] helo=[192.168.2.100]) by vl11s25.smart-weblications.de with asmtp (Exim 3.35 #1 (Debian)) id 1DbnGW-0006TP-00 for ; Sat, 28 May 2005 00:25:16 +0200 Message-ID: <42979E4D.3030203@Jarnbjo.de> Date: Sat, 28 May 2005 00:25:17 +0200 From: Tor-Einar Jarnbjo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [arch] VM/Classlibrary interface References: <60510FC8-4503-4149-A7EA-9CEBA018D0FA@apache.org> <42978057.7080403@Jarnbjo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Geir Magnusson Jr. wrote: > (Tomcat : I'd bet they fixed that (or will fix...)) It doesn't seem so. The SSL code has been in Tomcat versions 4.1.x to 5.5.9 and I just saw that also the LDAP code in Tomcat 5.5.9 uses classes in com.sun. > Well, can't the VM just prevent non-kernel code from using them? > Maybe overhead too high? How do you distinguish "kernel code" and "non-kernel code"? From the VM point of view, the classes in the java(x).* packages do not differ from user code classes and it is also possible to bootstrap the VM and replace java(x).* classes with own implementations. Been there, done that. Tor