From harmony-dev-return-1387-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Jun 06 09:28:25 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 81885 invoked from network); 6 Jun 2005 09:28:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jun 2005 09:28:24 -0000 Received: (qmail 24100 invoked by uid 500); 6 Jun 2005 09:28:19 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 24026 invoked by uid 500); 6 Jun 2005 09:28:18 -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); 6 Jun 2005 09:28:17 -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 syslx11.physto.se (HELO mail2.physto.se) (130.237.208.17) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 06 Jun 2005 02:28:15 -0700 Received: from localhost (localhost [127.0.0.1]) by mail2.physto.se (Postfix) with ESMTP id 1875A2822A for ; Mon, 6 Jun 2005 11:27:43 +0200 (CEST) Received: from mail2.physto.se ([127.0.0.1]) by localhost (syslx11.physto.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20578-01-2 for ; Mon, 6 Jun 2005 11:27:42 +0200 (CEST) Received: from qcplx01.physto.se (qcplx01.physto.se [130.242.128.121]) by mail2.physto.se (Postfix) with ESMTP id DF0C728ACD for ; Sun, 5 Jun 2005 21:17:38 +0200 (CEST) Subject: Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface From: Sven de Marothy To: harmony-dev@incubator.apache.org In-Reply-To: <5A9F6F91-D53F-4E15-ADBC-B37E70860DF1@apache.org> References: <41200565319138160@earthlink.net> <1117900759.24056.24.camel@qcplx01.physto.se> <1DFBE8EF-83E5-4F6F-AC28-0DDBBC69259B@apache.org> <1117989916.18145.23.camel@qcplx01.physto.se> <5A9F6F91-D53F-4E15-ADBC-B37E70860DF1@apache.org> Content-Type: text/plain Date: Sun, 05 Jun 2005 21:17:38 +0200 Message-Id: <1117999058.18145.39.camel@qcplx01.physto.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 (2.0.3-0.mozer.1) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at physto.se X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Sun, 2005-06-05 at 14:20 -0300, Geir Magnusson Jr. wrote: > > > > Reimplementing java.lang certainly is a penalty. > > I don't understand - I might have misstated something. Why do you > think I want to re-implement java.lang? No, I can't speak for you. But it's been suggested on this list. > Any JVM that uses GNU Classpath has to implement java.lang parts, right? > All I'm suggesting that we move the stuff that's not standard java.lang as > defined in a spec somewhere off to another package name. Thanks for clarifying your position. > Why not do it now so we don't have to fix it later, since to do J2SE > 5 we *are* going to have to modify it... Because I'm doubtful that we'll be able to produce a good specification without anyone having done at least one implementation. > But before we go leaping off to 1.6, how about 1.5? And perhaps support 1.4 before that? I'd say wait until you get full 1.4 before worrying about 1.5. > >> why not? Why restrict that freedom for users? > >> > > > > 1) Because Sun hasn't documented their VM interface. > > We don't care, do we? We can do our own. Ok. But then you won't be able to use Sun's class library. Which I believed was the point here? > Remember the modularity goal - we want people to be able to take this > stuff and plug-n-play with whatever they want. If for whatever > reason they wanted to plug in Sun's class library, why would we want > to prevent that? I don't see any reason for wanting to prevent that. But I don't see why you should go out of your way to enable it, if it means implementing undocumented proprietary interfaces. And it does. /Sven