Hi,
On Sun, 2005-01-09 at 14:25 +0100, Mark Wielaard wrote:
I just send a patch to classpath-patches to make our gjdoc documentation
generation work again. To give you an impression how it currently looks
I have build --with-gjdoc (using native gnujaxp and gjdoc) and put the
results at
Hi,
On Sat, 2005-01-15 at 22:55 -0500, Steven Augart wrote:
When we're at the phase in the bootstrap process where we are
generating the application class loader, the current context
loader is the bootstrap class loader. If URLClassLoader would use
only the bootstrap class loader, everything
Hi,
the last days I have been entering data for a Wiki on
developer.classpath.org/mediation .This place is going to supplement the
Hacker's guide, the mailing list and the homepage (FAQ) by providing
useful information about developer decisions. Another whole page deals
with issues that might
On Sun, 2005-01-16 at 10:23, Paul Jenner wrote:
Hi Andrew.
On Sat, 2005-01-15 at 21:07, Andrew John Hughes wrote:
Currently, GNU Classpath HEAD has 65.94% binary compatibility with JDK 1.5
I saw a thread about Japitools and 1.5 but did not follow closely. Are
there Japitools Classpath
Mark Wielaard wrote:
Note, that I already agree we should change to use the context
classloader (and the application classloader as backup if loading
through the context classloader fails and it isn't the same as the
application classloader). I just didn't make time to implement it.
I should have
On Thu, 2005-01-13 at 17:08, Stuart Ballard wrote:
On Thu, 13 Jan 2005 17:01:59 +, Andrew John Hughes
[EMAIL PROTECTED] wrote:
Great -- please let the list know how it goes. As I say, I haven't yet
tested it against a VM.
I will, but I'll be building against vm/reference myself until
Steven Augart wrote:
I propose adding a new class that may be optionally implemented by the
VM, gnu.classpath.VMStackBrowser. I say that it is optional because
I have here a reference implementation for it that uses the existing
gnu.classpath.VMStackWalker to do all the work:
/*
Steven Augart wrote:
I have what I think is a strong argument for why we need to
use the context classloader.
What if someone is attempting to use the URL class in writing
their Application Class Loader (also known as the system class
loader)? We get a serious recursion and bootstrap
Steven Augart wrote:
I propose adding a new class that may be optionally implemented by the
VM, gnu.classpath.VMStackBrowser. I say that it is optional because
I have here a reference implementation for it that uses the existing
gnu.classpath.VMStackWalker to do all the work:
Looks like a
have a truly lightweight solution which will allow the OOME to be thrown
without a stack trace (could be as little as a 1-bit flag in the thread
control block),
On a related note, I mentioned a long time back that it would be useful to
be able to control whether or not a stack trace were
Hi Hackers!
The FOSDEM organisation has been so nice to provide us with a developer
room during the conference during the weekend of February 26 and 27 in
the beautiful city of Brussels, Belgium. We asked a couple of people to
give talks and reserved some time to have technical planning and
Mark Wielaard wrote:
Hi,
On Sun, 2005-01-16 at 10:09 -0500, Steven Augart wrote:
I don't think we should use the application classloader as backup
in every case. Remember, the application class loader may not be
available or working at this phase in the booting process
-- and it won't be if
Steven Augart writes:
If every context class loader were guaranteed to delegate upward first,
then we'd have no reason to put in the backup plan (delegate to the system
class loader) at all.
I'm a little rusty on the overall situation - despite submitting the bug
report :) I believe the
13 matches
Mail list logo
