From harmony-dev-return-1391-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Jun 06 13:51:54 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 57943 invoked from network); 6 Jun 2005 13:51:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jun 2005 13:51:54 -0000 Received: (qmail 11792 invoked by uid 500); 6 Jun 2005 13:51:48 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 11738 invoked by uid 500); 6 Jun 2005 13:51:48 -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 11712 invoked by uid 99); 6 Jun 2005 13:51:48 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from granite1.mail.cornell.edu (HELO authusersmtp.mail.cornell.edu) (128.253.83.141) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 06 Jun 2005 06:51:46 -0700 Received: from [128.253.57.77] (aeolus.cit.cornell.edu [128.253.57.77]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id j56DsOQK010559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 6 Jun 2005 09:54:26 -0400 (EDT) Message-ID: <42A454D9.3050901@cornell.edu> Date: Mon, 06 Jun 2005 09:51:21 -0400 From: Aaron Hamid 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] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface References: 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 Jeroen I think there are at least two perceived problems being voiced: * aversion to the idea of "polluting" a standard library distribution (e.g. Classpath) with VM-specific interface implementations. Although there have been assurances that such work is trivial and the interface is always-changing, it makes it harder to decouple the VM from the class library (although another opinion is that this is not a goal of Harmony anyway). The fact that all (?) VMs using the Classpath library must make modifications to Classpath itself is an indication that perhaps standardization on interfaces (not implementations of course) would be beneficial. * uncomfortableness with relying on language visibility modifiers alone to prevent user code access to these internal APIs (this I am personally not that concerned about) Not to be pedantic - but for purposes of clarification can we quantify the "performance and complexity hit" for using well-defined interfaces as opposed to carnal knowledge between the class library and VM interface implementations? From what I have understood, for example, of the JikesRVM, these sorts of things are candidates for some heavy optimizations - especially given that these interfaces should not be used by user code at all, and should probably not be reloaded/unloaded/subject to traditional class loading issues (perhaps use some modularization, annotation, or magic keyword syntax that allows aggressive optimization of otherwise "public" interfaces?). Aaron Jeroen Frijters wrote: > You are correct, but why take the performance and complexity hit to > solve a non-existing problem? > > Regards, > Jeroen > > >>-----Original Message----- >>From: Aaron Hamid [mailto:arh14@cornell.edu] >>Sent: Sunday, June 05, 2005 20:44 >>To: harmony-dev@incubator.apache.org >>Subject: Re: [arch] How much of java.* and friends does >>Harmony need to write. Was: VM/Classlibrary interface >> >>I actually had not considered this issue which would seem to warrant >>these classes living in the same package. But can not an equivalent >>solution be constructed such that the implementations of these public >>classes can hand the VM* classes references to internal >>structures (and >>vice versa) though well defined interfaces, instead of relying on >>visibility modifiers to allow the VM* objects to access >>private state of >>java.lang classes, thereby allowing the VM* objects to live in a >>separate package? Or am I misunderstanding your statement (or maybe >>that is just too cumbersome)? >> >>Aaron >> >>Jeroen Frijters wrote: >> >>>You're missing the fact that moving these classes into >> >>another packages >> >>>creates another problem that is much worse. Namely that you >> >>often need >> >>>to access private state in the public classes, you can do >> >>that by living >> >>>in the same package, that's why the VM* classes live in the >> >>same package >> >>>as their public counterpart. >>> >>>Regards, >>>Jeroen >>