Re: Patch: FYI: Logger -vs- stack trace

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> I don't like this very much. It adds a divergence with GNU Classpath
Mark> that imho should be handled more elegantly. Could we do this in a
Mark> runtime neutral way by delegating to a package local final class
Mark> VMLogger which has a method getCallerStackFrame()?

Mark> This is how it is done in most other parts of the core libraries that
Mark> are shared with GNU Classpath and makes it clear which classes/methods
Mark> are runtime specific and which are not. That way we can also provide the
Mark> original reference implementation in GNU Classpath by default and let
Mark> each runtime override the VMLogger class explicitly if they want to gain
Mark> efficiency.

Yes, I agree, we should parameterize this on the VM.
This isn't exactly a good time to do it though.
And, as you know, Classpath changed its stack trace implementation
again, and we still haven't caught up with this.

So, my thinking is, we should delay worrying about this until after
4.0 is branched.  Then we can look seriously at the proposal to use
an unmodified Classpath with only relatively minor gcj-specific
changes.

Mark> Nice. What parts of jacorb are needed?

AFAIK, all of it.  My impression is that jonas relies on corba
actually working.  I haven't actually tried playing around with this
though.

Tom