From harmony-dev-return-274-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu May 12 07:33:41 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 73508 invoked from network); 12 May 2005 07:33:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 May 2005 07:33:38 -0000 Received: (qmail 64189 invoked by uid 500); 12 May 2005 07:36:58 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 64080 invoked by uid 500); 12 May 2005 07:36:56 -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 64040 invoked by uid 99); 12 May 2005 07:36:56 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from imag.imag.fr (HELO imag.imag.fr) (129.88.30.1) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 12 May 2005 00:36:56 -0700 Received: from [129.88.103.2] (invite2.imag.fr [129.88.103.2]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j4C7WaJU010799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 May 2005 09:32:39 +0200 (CEST) Message-ID: <42830698.3020106@ungoverned.org> Date: Thu, 12 May 2005 03:32:40 -0400 From: "Richard S. Hall" User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Class Library Modularity [Was Re: State of the World] References: <42806577.6080503@ungoverned.org> <4281A571.6010304@realityforge.org> <4281BD0B.1040100@ungoverned.org> <4281D861.7070900@realityforge.org> <4281FB92.1010601@ungoverned.org> <42820849.4060207@kaffe.org> In-Reply-To: <42820849.4060207@kaffe.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Thu, 12 May 2005 09:32:39 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Dalibor Topic wrote: > I think that would be pretty interesting, actually. One of the hard > challenges so far for me has been efficient support for 'profiles'[1] > in class libraries. What I have done in Kaffe is just a simple > mechanism to select the classes to build as part of a profile, but > that usually drags in a superset of an API due to implementation > internals required by added methods in later versions of a class, > rather then a minimal implementaiton of just the classes, methods, > fields, and their transitive closure. > > My experiments with kaffe last year have shown me that it is possible > to separate the class library into large chunks with certain ease, > though unfortunately the maintenace of such a modular seperation is > burdensome without tool support. From my cursory glance at the OSGi > specs, it seems as the OSGi devs have put a good amount of though into > dealing with the subject, so I'd be very interested to hear more about > it, including about respective tools. :) Yes, this is definitely something that could benefit from such a packaging mechanism. If it were possible to chunk the class libraries into modules, then without some mechanism to support/enforce this encapsulation the exercise becomes somewhat pointless. Some of the features I am talking about are already available in the OSGi spec, but these ideas in general are definitely in the purview of the OSGi framework and the work done around it. I have an experimental release of Oscar that starts to deal with the issues we are discussing here...these things are of interest to the OSGi Alliance Core Platform Expert Group too. I agree that these types of mechanisms require some sort of tooling support. One area that I want to investigate more is the generation of the module metadata by analyzing its byte code. There are already tools that do this for the R3 OSGi spec, so it should be possible to extend the approach to handle the metadata required for this type of encapsulation stuff too. Unfortunately, the tool support is still coming up from behind. Maybe this will change now that Eclipse depends on OSGi as well. > Yes, I agree. To give an example, an unfortunately common mispractice > that leads to unportable source code written in the Java programming > language is the abuse of runtime-specific classes by non-runtime code > to get access to runtime-specific services. Being able to, with > relative ease, make sure that modules of a class library only export > the interfaces specified in the specs would be pretty useful to help > people avoid writing implementation-specific code. Exactly. This my thought too. Plus it ensures that the VM and standard libraries themselves do not do practices that make it difficult to do various deployment/management activities on top of the VM. > Well, I am all ears. :) It would surely be interesting to be able > dynamically update a runtime installation's class libraries, for > example, or just it's JIT, if one can get the architecture right. Yes, these are the sort of thoughts I was having too as other people were having discussions about modular VM architectures. > On a side note, I'd love to see such mechanisms work hand-in-hand with > the native platform's package management, to avoid having to jump > through multiple hoops to manage software. This is another valid issue, but one that I have not given that much thought to at this point. > p.s. OSCAR already works on Kaffe & other GNU Classpath runtimes, > right? I remember seing some mails from that direction :) I am aware of users using Oscar on Kaffe, yes. I try to keep it pretty neutral and try to fix issues if I get reports of difficulties. -> richard