Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexey.v.varlamov@gmail.com
 designates 66.249.82.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WbV6SAMCmDPIFXdyL2Yj6g3shnDAvc1IyOUSeuRibxe2VoJCVCloJgAzE9Q0lZ1RmXkmqNnNh24oXL1qdQFe0wf835auA/7D1BMBZl4qtoDgQS6jt9gvhood4w+plKF9zvSB++quisyarn5QXS1uztfg7kZyHAXzAHB+QoQ2sXE=
Message-ID: <f944d83d0611291730r3a47b40dwa5cc35436ac91899@mail.gmail.com>
Date: Thu, 30 Nov 2006 07:30:56 +0600
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org, geir@pobox.com
Subject: Re: [drlvm/classlib/jdktools] system property o.a.h.boot.class.path
In-Reply-To: <456E1959.8050408@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <456E1959.8050408@pobox.com>

2006/11/30, Geir Magnusson Jr. <geir@pobox.com>:
> (How's that for a category in the subject line?)
>
> I'm working on jdktools, and was getting javac going.  We have a small
> issue.  Currently, the wrapper code grabs the boot class path via the
> system property
>
>     org.apache.harmony.boot.class.path
>
> This is initially set by luni, which collects all the entries in
> bootclasspath.properties and adds them to the path.
>
> Now, the one thing that it doesn't do is include the kernel.jar, as
> that's a degree of freedom for the vm which provides that jar.
>
> Now, in DRLVM, we take the o.a.h.b.c.p and prefix the kernel.jar, prefix
> and postfix -Xbootclasspath/? for a complete runtime bootclasspath, and
> call it
>
>     vm.boot.class.path

Things are changing :) Since recent H-2008 commit, magics support jars
are going to bypass this machinery and slip into boot loader directly
via SetBCPElement().
I'll fix this while integrating properties refactoing submission
(HARMONY-1925), please shout if there are objections.

>
> I had to modify the javac wrapper to use this rather than o.a.h.b.c.p.
>
> We need to change something - either we can suggest that VMs modify the
> value of o.a.h.b.c.p, or create a new one -  formally declare something
> like
>
>    o.a.h.vm.boot.class.path
>
> as a standard property for this purpose.
>
> I prefer the latter - it keeps it cleaner, and makes it easy to figure
> out what the VM is glomming on.

For me, lesser properties diversity is better. Do we have some
sensible use for o.a.h.b.c.p alone?

>
> If we agree, I'll do the switch in DRLVM and javac.  There should be no
> changes required elsewhere.

Please hold on DRLVM mods, until I finish with H-1925 (hopefuly today).

--
Alexey