Hi Jeroen, Am Dienstag, den 16.05.2006, 14:25 +0200 schrieb Jeroen Frijters: > Roman Kennke wrote: > > Here (@Aicas) we faced a similar problem as described by Tom. > > We came up with another possible (but similar) solution, which > > doesn't 'muddle up' the VM interface (ok, depends on your meaning > > of 'muddle up', it adds a new method with -IMO - also clearly > > defined semantics). It has the added advantage that it also > > returns the method name, which is very useful in the logging API. > > If I understand you correctly, this is a different issue from the one we > were discussing. Tom wanted to change the existing API because he > believed it wasn't implementable in gcj. If I understand you correctly, > you want to add a new API to use in logging, right? Or does Aicas use a > custom version of Class (for example) to relies on this API?
No, this is (ATM) only used by the logging API. However, we see a couple more usecases for such an extension. > > Any opinions about that approach? > > It looks fine, but as long as it isn't needed by shared GNU Classpath > code, it doesn't need to be part of the VM interface (IMO). We could then merge some patches for java.util.logging, which would make use of this for more efficient logging. I think this would be useful for GNU Classpath. As it is now, we faced severe bottlenecks in applications that make use of the logging API. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
