From harmony-dev-return-1348-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Sun Jun 05 13:47:31 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 3234 invoked from network); 5 Jun 2005 13:47:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Jun 2005 13:47:30 -0000 Received: (qmail 24335 invoked by uid 500); 5 Jun 2005 13:47:25 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 23984 invoked by uid 500); 5 Jun 2005 13:47:23 -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 23967 invoked by uid 99); 5 Jun 2005 13:47:23 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: error (hermes.apache.org: encountered temporary error during SPF processing of domain of dl@cs.oswego.edu) Received: from gee.cs.oswego.edu (HELO gee.cs.oswego.edu) (129.3.20.1) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 05 Jun 2005 06:47:15 -0700 Received: from [129.3.20.1] (gee [129.3.20.1]) by gee.cs.oswego.edu (8.13.3+Sun/8.13.3) with ESMTP id j55DkdiI024184 for ; Sun, 5 Jun 2005 09:46:40 -0400 (EDT) Message-ID: <42A3023F.1040404@cs.oswego.edu> Date: Sun, 05 Jun 2005 09:46:39 -0400 From: Doug Lea User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface References: <41200565319138160@earthlink.net> <24863B96-A276-4B0B-BEB9-D5EEDE38D131@apache.org> In-Reply-To: <24863B96-A276-4B0B-BEB9-D5EEDE38D131@apache.org> 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: >>>>>>> >> >>Dan> That includes the language protection features like Geir's >>Dan> example of package private, >> ... Sorry for not following up on some of my previous remarks on such things. But briefly, here's a trick that works, without any need for language-based module support (which would be much nicer, and will surely come for J2SE7, but isn't strictly needed in this case.) If you have functionality that should only be used across the packages inside the JDK library, and never by users, define it as (non-static) public method of a class (defined outside of java.* packages) that has no public constructors, but does have a factory method. That factory method includes the one bit of pure VM magic: It must only allow creation (or return a singleton) if the calling class is in bootclasspath, otherwise throwing some kind of exception. (The implementation of this check is just a specialization of other kinds of security checks JVMs must do.) Of course all JDK classes using such functionality should never pass around references to such classes. (This is one of the places where language support is needed). You'd like to define as few such classes as possible. It would be nice to standardize these across JVMs, but as I mentioned before, this is hard because JVM implementors want these internal APIs to remain flexible. This is probably the best way to handle all of those aspects of required Java APIs that cannot be described as bytecodes and/or require close Java<->JVM coupling for the sake of efficiency. This scheme also applies to replacements for "native" in those cases where the implementation is not a call to native code, but is instead "intrinsified", causing a JIT to produce custom instructions, as in the JikesRVM "magic" classes. I believe that the lack of such a facility might be one reason for some JVMs not yet supporting java.util.concurrent, which requires something like this to support compareAndSet instructions etc which must be intrinsified for performance to be acceptable. -Doug