Re: [cp-patches] [generics] RFC : implementation of jjava.lang.instrument package

Hi Christian, Christian Thalinger wrote: On Fri, 2005-12-02 at 12:22 +0100, Nicolas Geoffray wrote: gnu/java/lang/instrument. Would you like InstrumentationImpl to be in vm/reference/java/lang/InsutrumentationImpl? This sounds weird. We could also make the callTransformers method public.

[cp-patches] [generics] FYI: New Instrumentation parameter to VMInstrumentationImpl.redefineClasses

Here's a fix that eases implementation of the VMInstrumentationImpl.redefineClasses method. The VM might not want to keep the Instrument object, therefore it must be given explicitely to the VMInstrumentationImpl.redefineClasses method 2005-12-04 Nicolas Geoffray [EMAIL PROTECTED]

[cp-patches] RFC : Instrumentation in the vm integration guide

Hi, Here's a small documentation on how to use the instrumentation functionnality in gnu classpath generics for vm implementers. I added at the end that default implementation might break the ClassLoader/VMClassLoader interface. 2005-12-04 Nicolas Geoffray [EMAIL PROTECTED]

Re: [cp-patches] RFC : Instrumentation in the vm integration guide

Hi Nicolas, On Sun, 2005-12-04 at 16:20 +0100, Nicolas Geoffray wrote: 2005-12-04 Nicolas Geoffray [EMAIL PROTECTED] * doc/vmintegration.texinfo: Added subsection in the classpath hooks for the VMInstrumentationImpl class. Thanks for writing this. Two small

[cp-patches] FYI: Disallow unsecure copy/paste exchange

Hi, After the last discussion about TransferHandler and security issues it seemed safer to me to just disallow any copy/paste between untrusted code paths as was suggested earlier. 2005-12-04 Mark Wielaard [EMAIL PROTECTED] * javax/swing/TransferHandler

Re: [cp-patches] FYI: Disallow unsecure copy/paste exchange

Maybe yes. The recent insecure approach comes from the historcal past. Mark Wielaard wrote: Hi, After the last discussion about TransferHandler and security issues it seemed safer to me to just disallow any copy/paste between untrusted code paths as was suggested earlier. 2005-12-04 Mark

Re: [cp-patches] FYI : Instrumentation in the vm integration guide

Hi Mark Maybe explicitly say for calling the @code{InstrumentationImpl.callTransformers} when a class byte code is defined with @code{ClassLoader.defineClass} So the vm implementer knows this is their job at the moment. Allright added. I'm committing this in the main branch. 2005-12-04

Re: Compilation of Classpath with ecj on a 64-bit VM

Hi Andrew, On Sat, 2005-11-26 at 21:04 +, Andrew John Hughes wrote: I recently hit on the same bug again for the second time, and still there seems to be no general solution to it. ecj is a Java-based Java compiler, which means that in compiling Classpath, it can run across

memory behavior to expect with gjdoc-0.7.6

Greetings, I'm using gjdoc-0.7.6 to test a new port of JamVM-1.4.1 + classpath-0.19 on OpenBSD. I'm trying to get gjdoc to do all the classpath documentation. gjdoc makes a lot of progress (it's outputting stuff), but blows off by hitting an upper memory limit. My question is this: Should I

[commit-cp] classpath ./ChangeLog vm/reference/java/lang/VM... [generics-branch]

CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Nicolas Geoffray [EMAIL PROTECTED]05/12/04 13:19:39 Modified files: . : ChangeLog vm/reference/java/lang: VMInstrumentationImpl.java java/lang

[commit-cp] classpath ./ChangeLog javax/swing/TransferHandl...

CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard [EMAIL PROTECTED] 05/12/04 19:51:44 Modified files: . : ChangeLog javax/swing: TransferHandler.java Log message: *

[commit-cp] classpath ./ChangeLog java/net/URL.java

CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Guilhem Lavaux [EMAIL PROTECTED] 05/12/04 20:52:47 Modified files: . : ChangeLog java/net : URL.java Log message: 2005-12-04 Guilhem Lavaux [EMAIL