Re: Quality control and FOSS rant
And in case anyone is under any illusions, Sun's record of fixing bugs (and not re-breaking them) is poor. The number #1 voted bug* in their bug database has been unfixed for over 5 YEARS! -Archie * http://bugs.sun.com/view_bug.do?bug_id=4670071 -- Archie L. Cobbs
Re: [cp-patches] RFC: ClassLoader associative cache
Jeroen Frijters wrote: There are several places in our codebase were we need/want to cache stuff that is associated with a class or class loader. Currently these places retain a strong reference to the class loader, which is not correct, because the class loader should be garbage collectable. I cooked up proposal for an API to use for this and implemented it in the three places I could think of off the top my head (serialization, proxy and resource bundle). This is just a first stab, so no documentation and no change log entry yet. Please comment on the idea and/or the API. Dumb question.. why wouldn't it work to just use a WeakHashMap instead of a HashMap in all those places? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: jboss-4.0.4
Christian Thalinger wrote: On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? JCVM has class unloading, but I've never tried JBoss. If you want to try it, use the harmony version because it's more up to date: https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: java.lang.StrictMath#cbrt implemented
Carsten Neumann wrote: Here is an updated version. + * Returns the cube root of codex/code. The sign of the cube root + * is equal to the sign of the sign of codex/code. You've got an extra the sign of in there.. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Harmony's Classpath adapter
Hey all, As some of you know I donated a version of JCVM to the Apache Harmony project under the Apache license called JC Harmony Edition. BTW, SableVM has been donated too. However, Harmony has its own class library called classlib (why so is a different discussion for another thread). So my advice for JCHEVM was to start integration by creating a Classpath adapter, which is a small shim layer of Java code that sits between classlib (above) and the JVM (below), roughly at the VMFoo layer. It takes any Classpath-compatible JVM and makes it work with classlib. The goal is that any Classpath-compatible JVM can run with classlib instead of Classpath simply by putting the Classpath adapter on the bootclasspath and the classlib libraries on the library path. So why am I bringing this up here? Because although I don't like the fact that there are two whole class libraries out there that people are working on, there is one advantage in terms of testing and debugging: by being able to mix and match JVMs and class libraries, we can get a lot of testing leverage for detecting bugs and incompatibilities. I think this could be an interesting opportunity. So if any Classpath/JVM developers are interested in getting involved, you can SVN check out the evolving Classpath adapter via this URL: http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlibadapter Of course on the Harmony mailing list is lots more info, etc. Cheers, -Archie P.S. This email is purely informational (i.e., don't blame me if you think Harmony is stupid in the first place). __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve reports
Roman Kennke wrote: I'd like to get JCHEVM (the Harmony edition of JCVM) included.. is that possible? Let me know what I can do to help if so. This should be possible. Whenever me or Mark or somebody else finds time to fiddle with the build scripts we will include this. OTOH, it might be possible that Mark gives you access to the machine so you can set this up yourself? That'd be fine with me... just let me know what I need to do. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve reports
David Gilbert wrote: Roman Kennke wrote: These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I'd like to get JCHEVM (the Harmony edition of JCVM) included.. is that possible? Let me know what I can do to help if so. Some details... - It's easy to download the latest source, but you'll need an SVN client - The SVN build requires the usual autofoo stuff (automake, autoconf, etc). There is a script included that runs everything (including ./configure). - Still targeted at Classpath 0.90, due to the fatal bug in Classpath 0.91 that makes startup fail with a NullPointerException. I have a patch for 0.91 though (it's currently checked in as an unapplied patch). Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] FYI: [generics] Fix for System.getenv bug
Andrew John Hughes wrote:
I'm committing the patch which fixes a bug in System.getenv()
when an environment variable has an empty value.
Not part of your patch (code was there before) but:
String[] parts = pair.split(=);
Shouldn't this be pair.split(=, 1) instead? E.g. what if I have
a variable like FOO=2+2=4.
Actually, even that is not right. E.g., consider FOO==BAR. The
value is =BAR not empty string.
Instead, I think using pair.indexOf('=') is required here...
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] [jessie-nio] merge scatter-gather NIO support
Casey Marshall wrote: I do wish that Savannah would support SVN. Me too! These days having to work with CVS is a big turn-off for me. Guess I'm just spoiled. IMHO CVS should be put out to pasture. FreeBSD is another example still stuck in the CVS stone age. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[cp-patches] Classpath 0.91 startup exception
After upgradeing JCVM to 0.91, I'm seeing an exception due to broken static initializer ordering in java.lang.VMClassLoader. The bootjars static field is initialized on line 173, but this is after its use (indirectly) in the static initializer that starts on line 83. Here's a stack trace: java.lang.NullPointerException at java.lang.VMThrowable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Throwable.java:498) at java.lang.Throwable.init(Throwable.java:159) at java.lang.Exception.init(Exception.java:78) at java.lang.RuntimeException.init(RuntimeException.java:76) at java.lang.NullPointerException.init(NullPointerException.java:80) at java.lang.VMClassLoader.getResources(VMClassLoader.java:206) at java.lang.VMClassLoader.getResource(VMClassLoader.java:166) at java.lang.VMClassLoader.getBootPackages(VMClassLoader.java:252) at java.lang.VMClassLoader.clinit(VMClassLoader.java:76) at java.lang.Integer.clinit(Integer.java:81) at java.lang.String.valueOf(String.java:1756) at java.lang.StringBuffer.append(StringBuffer.java:530) at gnu.java.nio.channels.FileChannelImpl.init(FileChannelImpl.java:157) at gnu.java.nio.channels.FileChannelImpl.clinit(FileChannelImpl.java:91) at java.io.FileDescriptor.clinit(FileDescriptor.java:63) at java.lang.VMSystem.makeStandardInputStream(VMSystem.java:186) at java.lang.System.clinit(System.java) at java.lang.Math.clinit(Math.java:71) at java.util.WeakHashMap.hash(WeakHashMap.java:575) at java.util.WeakHashMap.internalGet(WeakHashMap.java:652) at java.util.WeakHashMap.get(WeakHashMap.java:760) at java.lang.VMString.intern(VMString.java:77) at java.lang.String.intern(String.java:1806) at java.lang.String.clinit(String.java) Note the call to String.intern() (second line from the bottom in the stack trace) is generated by the VM to handle creation of a String constant. Although VM-specific, this is unrelated to the initialization ordering problem in VMClassLoader. This is fixed by the attached patch, which I'll commit if there are no objections... but with that fix, I don't get much further: Caused by java.lang.NullPointerException at java.lang.VMThrowable.fillInStackTrace(Native Method) at java.lang.Throwable.fillInStackTrace(Throwable.java:498) at java.lang.Throwable.init(Throwable.java:159) at java.lang.Exception.init(Exception.java:78) at java.lang.RuntimeException.init(RuntimeException.java:76) at java.lang.NullPointerException.init(NullPointerException.java:80) at java.lang.Thread.getThreadLocals(Thread.java:1032) at java.lang.ThreadLocal.get(ThreadLocal.java) at java.security.VMAccessController.pushContext(VMAccessController.java:108) at java.security.AccessController.doPrivileged(AccessController.java:93) at gnu.java.nio.charset.Provider.provider(Provider.java:237) at java.nio.charset.Charset.provider(Charset.java:250) at java.nio.charset.Charset.charsetForName(Charset.java:204) at java.nio.charset.Charset.forName(Charset.java:188) at java.lang.String.init(String.java:348) at java.util.zip.ZipFile$PartialInputStream.readString(ZipFile.java:668) at java.util.zip.ZipFile.readEntries(ZipFile.java:272) at java.util.zip.ZipFile.getEntries(ZipFile.java:357) at java.util.zip.ZipFile.getEntry(ZipFile.java:378) at java.lang.VMClassLoader.getResources(VMClassLoader.java:226) at java.lang.VMClassLoader.getResource(VMClassLoader.java:170) at java.lang.VMClassLoader.getBootPackages(VMClassLoader.java:252) at java.lang.VMClassLoader.clinit(VMClassLoader.java:79) at java.lang.Integer.clinit(Integer.java:81) at java.lang.String.valueOf(String.java:1756) at java.lang.StringBuffer.append(StringBuffer.java:530) at gnu.java.nio.channels.FileChannelImpl.init(FileChannelImpl.java:157) at gnu.java.nio.channels.FileChannelImpl.clinit(FileChannelImpl.java:91) at java.io.FileDescriptor.clinit(FileDescriptor.java:63) at java.lang.VMSystem.makeStandardInputStream(VMSystem.java:186) at java.lang.System.clinit(System.java) at java.lang.Math.clinit(Math.java:71) at java.util.WeakHashMap.hash(WeakHashMap.java:575) at java.util.WeakHashMap.internalGet(WeakHashMap.java:652) at java.util.WeakHashMap.get(WeakHashMap.java:760) at java.lang.VMString.intern(VMString.java:77) at java.lang.String.intern(String.java:1806) at java.lang.String.clinit(String.java) I haven't investigated the second problem yet... I'm very curious though.. why is nobody else seeing these problems?? It doesn't seem VM-specific but maybe I'm missing something. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: ChangeLog === RCS file: /sources/classpath/classpath/ChangeLog,v retrieving revision 1.7530 diff -u -r1.7530 ChangeLog
[commit-cp] classpath ./ChangeLog vm/reference/java/lang/VM...
CVSROOT:/sources/classpath Module name:classpath Branch: Changes by: Archie Cobbs [EMAIL PROTECTED]06/05/23 16:11:33 Modified files: . : ChangeLog vm/reference/java/lang: VMClassLoader.java Log message: * vm/reference/java/lang/VMClassLoader.java: fix static initializer ordering problem. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7532tr2=1.7533r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/vm/reference/java/lang/VMClassLoader.java.diff?tr1=1.37tr2=1.38r1=textr2=text
Re: [cp-patches] RFC: Making java.lang.Thread.getContextClassLoader() lazy for threads created outside of Java
Jeroen Frijters wrote: I would like to apply the attached patch. It fixes a potential initialization order issue for VMs that support running Java code without first initializing the VM explicitly (like IKVM does). Dumb questions: why don't you initialize the VM in JNI_CreateJavaVM()? What is gained by deferring initialization? Curiously, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] Logger initialization regression fix and a little story on security contexts during class initialization
Mark Wielaard wrote: We had an interesting regression with the logging code in GNU Classpath. It wasn't immediately apparent because it was only caused with certain compilers. The class initialization order was subtly different between byte code compiled with gcj -C and jikes. So it didn't show up with gcj -C which I used when committing this code. Since class initialization is strictly defined by the JVM spec, doesn't this necessarily imply a bug in either gcj or jikes? The only other alternative is that they both compile the same code correctly, but do so differenly enough to change the class initialization order, which to me seems even more surprising (but possible I guess.. ?) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: fix for PR 24642
Casey Marshall wrote: Getting a seed value does the following: 1. Try to read from the URL given in the security property `securerandom.seed.' 2. If that property is not set, or is set to a malformed URL, try to read from the URL given by the system property `java.security.egd.' 3. If neither property is set to a valid URL, or if reading that URL fails, call `VMSecureRandom.generateSeed.' The thing to do on most Unix systems is to point the `securerandom.source' property to `file:/dev/random' or `file:/dev/ urandom.' So there needs to be a NEWS entry for VM implementors that notifies them they should set the securerandom.seed system property at VM startup, right? If so please add one to your patch. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] FYI: Merge Thread.UncaughtExceptionHandler support from generics branch
Mark Wielaard wrote:
+ /**
+ * p
+ * Returns the handler used when this thread terminates due to an
+ * uncaught exception. The handler used is determined by the following:
+ * /p
+ * ul
+ * liIf this thread has its own handler, this is returned./li
+ * liIf not, then the handler of the thread's codeThreadGroup/code
+ * object is returned./li
+ * liIf both are unavailable, then codenull/code is returned./li
+ * /ul
+ *
+ * @return the appropriate codeUncaughtExceptionHandler/code or
+ * codenull/code if one can't be obtained.
+ * @since 1.5
+ */
+ public UncaughtExceptionHandler getUncaughtExceptionHandler()
+ {
+return exceptionHandler;
+ }
The Javadoc and the implementation here don't seem consistent: how
could this ever return the thread's ThreadGroup (option #2)?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Beanshell support for Mauve
Roman Kennke wrote: while having dinner I had a great idea: IMO it would be ubercool to have Mauve support Beanshell scripts as testcases. I came to this idea This sounds like a good idea. In any case, it can be done without any harm to the existing infrastructure, i.e., it could be prototyped as an optional add-on. Mauve could look for foo.class OR foo.bsh, and do the appropriate wrapper type operation in the latter case. We use BeanShell for lots of stuff at work and it's great. One glitch is: does BeanShell run on Classpath? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: running pscan, rats. flawfinder and splint on classpath
Dalibor Topic wrote: functions. Some of those are a little odd, for example it is not clear to me what to do if JNI function call ThrowNew fails. rats and Good question.. I think the only reasonable answer is proceed with the knowledge that an exception was posted, but perhaps not the one you asked for (e.g., OutOfMemoryError or somesuch). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Clemens Eisserer wrote: For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. It seems you are some years behind actual development. The threading model you describe was used till linux-2.4, since 2.6 NPTL is used instead which outperforms almost everything else. Good to hear that :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Ian Rogers wrote: Archie Cobbs wrote: IMHO using POSIX threads is the only right answer for a multi-platform JVM. You have no other choice except to leave it up to the specific platform to then implement POSIX threads efficiently. For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. I agree with you. I think it's always the case that Java threads are going to be better than POSIX threads though, as with some commodity processors, in particular I'm thinking of Cell, you no longer have a shared memory model. In such a situation you could use a distributed JVM, such as JESSICA2 - that's built on top of Kaffe :-). So whilst implementing a JVM assuming POSIX threads is a good idea to run on many platforms, there are legitimate reasons why you may want to be flexible and not assume a 1-to-1 mapping of Java threads to POSIX threads, and of course avoid native code. You're right.. there is a subtlety here I was glossing over. When referring to threads above, I guess I meant things that actually need to consume C runtime stack. For example, if you have code that invokes read(2), this code needs to have it's own C runtime stack and needs a real O/S-supplied thread to sleep with. Any time you invoke JNI native code, you'll also need a real thread and runtime stack. On the other hand, Java threads are entirely virtual and their stacks don't have to correspond 1:1 to C runtime stacks (although it surely is convenient to do it that way). I don't know which JVMs make this distinction. You would have to lend a real thread to a Java thread anytime it invokes native code. But you could re-use that thread once the thread returned to Java code; if the thread called back into Java code from within the native method, you could also return the real thread to the thread pool, but the chunk of C runtime stack that supported the native method call would have to be saved somewhere of course. You'd need a lot of longjmp() or setcontext() magic to do this. The upshot would be that you only use real threads when absolutely required, e.g., you're making a blocking system call, and Java threads would be very lightweight (corresponding merely to linked lists of Java stack frame structures, or whatever). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Green threads - some experience
Andrew Haley wrote: I think the long term view is to switch to POSIX threads. Having used the Jikes RVM for an OS like project, relying on native threads wouldn't have been desirable. In theory green thread context switches should be possible in a few instructions whereas a full context switch takes a few hundred. I guess its all down to the situation the JVM is trying to optimise for. Indeed. I've been thinking about this, and it occurs to me that threads are used to solve two entirely problems, and which threading model is desirable depends on which problem you are trying to solve. IMHO using POSIX threads is the only right answer for a multi-platform JVM. You have no other choice except to leave it up to the specific platform to then implement POSIX threads efficiently. For example, on Linux where each POSIX thread is a cloned process, it's Linux's fault (not the JVM's fault) if that doesn't scale well. For example, other OS's don't have such heavyweight threads. FreeBSD's KSE's are an example of a better tradeoff using M:N user:kernel threading. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] Patch: RFC: changing parts of VM reflection API
[EMAIL PROTECTED] Tromey wrote: I'm posting this for comment. This is the patch to change Method/Field/Constructor to have a 'getModifiersInternal' method, which returns the un-masked modifiers as read from the .class file. This lets us implement the new 1.5 reflection predicates such as isSynthetic. Looks good to me... accompianied by a NEWS entry of course. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: RFC: VMClassLoader changes proposition
Olivier Jolly wrote: So basically, I'm asking about your thought on how to make the boot class loader (which is out of range of classpath) defines packages as it load classes. JCVM doesn't have any support for Packages, so any general-use code that gets added to Classpath and can save me work has my vote :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Where's the love?
Brian Jones wrote: I'm not following Harmony too closely (so let me talk out my ... a moment) but let me see if I understand it so far. Harmony is: 1) Writing their own class libraries (based on email about japi comparisons) 2) Writing their own JVM (which I think is based in some part on one of the current JVMs, but ok, sure, everyone seems to write one eventually) 3) Writing their own test suite (because Mauve doesn't use junit and has a different license, but I think that's going to be fixed) Here's a little bit more information re #2. I've donated an interpreter-only version of JCVM to Harmony (called JC Harmony Edition) under the Apache license. Whether they'll end up using it or not, who knows. IBM has donated a class library (called, unfortunately, classlib). There is an effort underway to port that class library to JCHEVM, using the existing (Classapath-defined) Java/VM API. This effort has seen some initial success. So in theory, if all goes well, any combination of (classlib or Classpath) and (any VM that works with Classpath) will run. This would be great if it can be achieved. As for all the license stuff, I don't understand it all and don't care strongly enough to follow the debate. I do think it's a real irony that free software can't be packaged with other free software. I don't in general like the idea of two competing class libraries nor two competing test frameworks (the latter being especially stupid). So #1 is not really true: they're not writing new stuff, they've just accepted a pre-existing donation. They believe they can't just use Classpath for license reasons (this part I don't fully understand). Re #3 I've not been following it. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: RFC: Removing unused import
Arnaud Vandyck wrote: Filtering warnings in Classpath with Eclipse, I found there are 388 warnings about The import XXX is never used. I can work on these warnings and I think I can commit the result without requesting for comment on each classes because it's a minimal impact patch. But before proceeding, I'd like to ask: 1- is it useful; It's useful.. but first verify that the tool is javadoc-aware. E.g., some imports may only be used in javadoc comments (in theory). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Real questions
Philippe Laporte wrote: Does this library have (ie is in a perfect state) all the security and signing stuff that classpath lacks right now? How about the security audit? I'm not sure exactly what it has, as I've been too busy to take a good look at it. It's all visible for inspection via the Apache SVN server if you want to have a look. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Where's the love?
David Daney wrote: So, given these things and my love for this project, I would really like the FSF to allow the developers to provide Classpath under an Apache compatible license in addition to the current licensing scheme, at least I would support that idea. However, I don't think we require the FSF's permission. We are the authors of Classpath and therefore retain copyright privledges. IANAL, but I could swear that I signed over copyright to the FSF long ago. IANAL either .. but I think you assigned copyright to them, meaning you gave them the right to copyright. This has no effect on your own right to the copyright of your own work. Ie, you did cp self fsf, not mv self fsf. But since IANAL and TINLA [1], I should probably just shut up for now :-) -Archie [1] http://en.wikipedia.org/wiki/IANAL __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: JNI calls that don't return
Ian Rogers wrote: Thanks for the replies. I have worked further on this and the particular issue isn't with GC barriers but with M-to-N threading. In theory if 1 of the M threads becomes blocked in a JNI call then the other threads should be moved onto another of the N underlying native threads. Unfortunately, as it's possible to call back into the JVM, the JVM's yield code can schedule another thread on the same native thread before realising the 1st thread is blocked and now its possibly handling a I agree that this model though well intentioned is fundamenally broken. You simply can't implement correct M-N threading unless you have some way of being notified properly when a lower layer thread blocks. For example look at FreeBSD's KSE threading model, which is similar to activations. If a system call blocks, the user thread manager is immediately notified by the kernel... http://www.freebsd.org/kse/ Without this kind of notification the only other alternative is to wrap every system call that could possibly block. That's not implemented in classpath (and besides the VM would also have to implement it). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: JNI calls that don't return
Jeroen Frijters wrote: Some VMs require all Java threads to run upto a garbage collection barrier before garbage collection can be performed. If a Java thread never leaves JNI code then this will never happen and the VM deadlocks. Why not fix the VM? Real world applications are likely to have this issue as well, besides how is this any different from blocking on I/O inside a JNI method for a very long time? I agree.. any thread that's running JNI code is cannot possibly affect the state of the VM until if/when it either returns or invokes a JNI method. Therefore there's (in theory) no need to wait for it to return in order to do anything. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cygwin: HOWTO
Enrico Migliore wrote: I'm using Classpath with Archie Cobbs' JCHEVM virtual machine, and I'm writing another document that explains how to build JCHEVM on Cygwin. If you think it might be of interest, I'll post this second document too. The latter document (building JCHEVM on Cygwin) is better placed on the Apache Harmony web site. But it should definitely contain a pointer to the Classpath wiki entry describing how to build Classpath on Cygwin. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: file resources can be directory too
Olivier Jolly wrote: following the mauve testlet commit, here is the fix proposition in classpath. Basically, we were explicitly preventing directories to be retrieved as file resources, while I don't see any reason to do so (nor sun implementors afaik). So, I propose this very trivial patch to deal with it. Looks like I was the one who disabled this behavior in rev 1.32. Right now I can't remember why. But I think there was some bug in the previous code. Note rev 1.32 removed code in getInputStream() too, which is where ISTR the bug was. I can't access the archives right now (web site too slow) but it might be worth checking them for the original reasoning for the change. Had something to do with something working with file:// URLs but not http:// URLs, or the other way around, or... Otherwise it looks OK to me. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Next release
Mark Wielaard wrote: - Decide on the version number. We had a very small/brief discussion about this during Fosdem. Everybody seems to agree 0.x really doesn't do justice to the maturity we have reached over the years. And it is really hard to define when we hit 1.0. So the proposal is to keep using a sequence version number. Either just drop the 0. and make the next release-number classpath-21, or adopt a year.month style version number and make the next version number classpath-6.3 for the March 2006 release. In either case we will just use a code name for a release that has some special feature set that we are proud of, but we will always just increase the release snapshot number. Suggestions or Opinions? Opinion requested, here granted :-) Changes in version number format, etc. have a cost in that can confuse (or at least complicate) packaging and versioning software like RPM, FreeBSD ports, etc. not to mention consumers (i.e., users). If all we want is a sequence numbering, then 0.xx has been working fine so why change it? If we want to be prouder, let's just release 1.0 and be done with it. Surely 1.0.1, 1.1, 1.2, etc will shortly follow and the whole grandness of 1.0 will fade quickly. So I vote either keeping the status quo, or releasing 1.0. A classpath-6.3 seems to be the worst of both worlds. Not a big deal really, but that's my $0.02 anyway... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Olivier Jolly wrote:
I bumped into a major problem with spring and easymock which boiled
down to being a subtle definition of a Proxy. In the case of the
creation of a proxy which defines the same method as Object (which is
non final and public), the method in the interface must be so that
getDeclaringClass is Object.class and not the actual interface.
Just curious.. are you sure this is a Classpath issue and not
a VM issue?
yes, as far as the VM isn't handling natively the creation of
java.lang.reflect.Proxy. In the Proxy.java source file of classpath
we're (incorrectly) building the proxy with methods that shouldn't be
there.
What does the failure look like?
Within an InvocationHandler, the method instance which is given as
parameter is not equals to Object.class.getDeclaredMethod(..., ...) if
the interface the proxy is built on redefines one of the core Object
methods. Easymock is correctly expecting to catch all equals call with
Object.class.getDeclaredMethod(equals, new Class[]
{Object.class}).equals(method) which is not the case without my patch.
Still curious.. :-)
It's not an error for an interface to declare a method that matches
an Object method (such as equals), and then for some bytecode somewhere
to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would make
more sense. E.g. code somewhere in Eclipse does this.
So isn't this an easymock bug? In such a case, wouldn't easymock fail
to catch a valid equals() invocation?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: fix in proxy creation of interfaces redefining toString, equals or hashCode
Olivier Jolly wrote: It's not an error for an interface to declare a method that matches an Object method (such as equals), and then for some bytecode somewhere to INVOKEINTERFACE that method, even though INVOKEVIRTUAL would make more sense. E.g. code somewhere in Eclipse does this. No, it's not an error and it actually mostly works just like everyone expects it to. Excepted that Sun stated special cases in the javadoc of Proxy : An invocation of the hashCode, equals, or toString methods declared in java.lang.Object on a proxy instance will be encoded and dispatched to the invocation handler's invoke method in the same manner as interface method invocations are encoded and dispatched, as described above. The declaring class of the Method object passed to invoke will be java.lang.Object. Ah, thanks... I knew there had to be a kludge in there somewhere :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) But let's talk practicalities.. here's a simple thing I don't understand. What exactly prevents Harmony from using Mauve as a test suite? Would Apache want to create it's own copy of Mauve and check that into SVN? That seems like a bad idea -- i.e, creating a code fork. So then if Apache only wants to run Mauve tests, what impact does Mauve being GPL have? Why can Apache folks just download Mauve and run it, the same way Classpath hackers do? Mauve is its own self-contained project. As to the issue of converting Mauve to JUnit, that's surely a lot of work any way you slice it, and in any case that seems like an orthogonal issue. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. This can make sense if the Harmony tests are Harmony-specific. Otherwise I don't see what the point is. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? There may be no real reason it should be GPL, but in any case it is... so.. what's the problem with that? I mean, from a practical standpoint. But you seem also to be asking the religious question why GPL? Like most religious questions that one has no objective answer.. If you really want to hear an answer then you can read the official one in the GPL FAQ... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
Stuart Ballard wrote: The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. Well then IMHO those people are the ones who are being difficult and putting politics over progress. Saying you won't contribute to a GPL project is more a political statement than the result of some reasonable decision-making process, because even if you do contribute to GPL software, you still own the copyright so you can also release your code under any other license you choose. Personally I don't love the GPL because it imposes more restrictions than a BSD style license (making, in my opinion, GPL software less free). But I respect others' religious beliefs. So if the GPL is not otherwise in the way, I have no problem working with it, etc. Can't we all just get along? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Hashtable's and the tale of runtime
Tom Tromey wrote: At some point we changed libgcj's hash function to this: // This was chosen to yield relatively well distributed results on // both 32- and 64-bit architectures. Note 0x7fff is prime. return (jint) ((unsigned long) obj % 0x7fff); What if you're on a 32-bit machine and all the object addresses are less than 0x8000.. won't that give you the same result as just returning (jint)obj ? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Classpath on Cgwin: UnsatisfiedLinkError problem
S. Meslin-Weber wrote: VM writers typically handle the delegated loadLibrary() call via their implementation of the VM* interface classes and in their own native code. As cygwin uses a decidedly odd naming convention for its dlls, I'd say those parts of jc would need to be investigated. IIRC, Cygwin calles its equivalent of libjavanio.so cygjavanio-0.dll. So... what's an #ifdef one can use on cygwin to detect cygwin? E.g. #ifdef WINDOWS or #ifdef CYGWIN or something? (This is hard for me to fix right now because I don't have cygwin set up anywhere). Presumably other VMs have the same issue (if they want to run on cygwin). Has anyone already solved this problem? Enrico: the relevant macro is _JC_LIBRARY_FMT in definitions.h. Perhaps you can play with some possibilities there. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] RFC: arm doubleToLongBits fix
Christian Thalinger wrote: +#if defined(__IEEE_BYTES_LITTLE_ENDIAN) + /* On little endian ARM processors when using FPA, word order of + doubles is still big endian. So take that into account here. When + using VFP, word order of doubles follows byte order. */ + +#define SWAP_DOUBLE(a)(((a) 32) | (((a) 32) 0x)) + + val.j = SWAP_DOUBLE(val.j); +#endif + Could instead you just have a configure test for byte order? Not sure if __IEEE_BYTES_LITTLE_ENDIAN is going to cover all possible cases. Of course, since you've got a patch and I don't feel free to ignore me :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [cp-patches] FYI: ObjectView implemented
Roman Kennke wrote: Sorry, this was an accident with cvs add/ cvs diff. Now I attached the new file. FYI, cvs diff -uN (note the -N) includes added files in the diff (it took me a while to realize this). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: SecurityManager troubles
Gary Benson wrote:
+ catch (Throwable t)
+ {
+ }
It might be more appropriate to only catch Exception, not Throwable.
So I was halfway through thinking about this when I forgot and
committed it :(
Why Exception as opposed to Throwable? My reasoning was that the code
was added to possibly make more things work than do already, and that
anything that might make less things work was to be avoided.
The alternative to Throwable is to catch ClassNotFoundException, which
is the only subclass of Exception that Class.forName throws.
It's definitely not a big deal, but e.g. you should at least not
catch ThreadDeath. Moreover, if there is some obscure, unrelated VM
startup issue, you might get an Error thrown at any time.. if you
discard that here, it might make the obscure issue even more obscure.
This comes from someone who's created his fair share of obscure
VM startup issues :-)
You're right that ClassNotFoundException would be more appropriate
still than Exception. Then the code is clearest about what exactly
is intended.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Mark Wielaard wrote: Maybe we can again special case that security check by doing a this.getClass().getClassLoader() == null? Hmmm, no, that doesn't work since getClassLoader() will trigger a security check. Nasty... That's what VMStackWalker.getClassLoader() is for... you could use it. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: SecurityManager troubles
Gary Benson wrote:
Gary Benson wrote:
Jeroen Frijters wrote:
I think I figured it out. With the attached test I could reproduce
the problem on IKVM as well. The attach Classpath patch fixing
things, although past 0.20 I think we should refactor the security
properties like I did with the system properties (i.e. introduce a
gnu.classpath.SecurityProperties class).
The change to java.security.Security has made the majority of the
Mauve workarounds unnecessary: thanks! Now to see if I can get rid
of the last little bit...
The attached patch allows all Mauve workarounds to be removed.
Ok to commit?
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.6049
diff -u -r1.6049 ChangeLog
--- ChangeLog 13 Jan 2006 14:30:27 - 1.6049
+++ ChangeLog 13 Jan 2006 14:33:56 -
@@ -1,3 +1,8 @@
+2006-01-13 Gary Benson [EMAIL PROTECTED]
+
+ * java/lang/System.java (setSecurityManager): Ensure policy
+ files are loaded before a security manager is put in place.
+
2006-01-13 Mark Wielaard [EMAIL PROTECTED]
* configure.ac: Set version to 0.20.
Index: java/lang/System.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/System.java,v
retrieving revision 1.53
diff -u -r1.53 System.java
--- java/lang/System.java 13 Sep 2005 22:19:15 - 1.53
+++ java/lang/System.java 13 Jan 2006 14:33:56 -
@@ -178,6 +178,23 @@
if (SecurityManager.current != null)
SecurityManager.current.checkPermission
(new RuntimePermission(setSecurityManager));
+
+// java.security.Security's class initialiser loads and parses the
+// policy files. If it hasn't been run already it will be run
+// during the first permission check. That initialisation will
+// fail if a very restrictive security manager is in force, so we
+// preload it here.
+if (SecurityManager.current == null)
+ {
+ try
+ {
+ Class.forName(java.security.Security);
+ }
+ catch (Throwable t)
+ {
+ }
+ }
+
SecurityManager.current = sm;
It might be more appropriate to only catch Exception, not Throwable.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch: RFC: remove InetAddress caching
Tom Tromey wrote: I'm not checking this in yet -- I would like comments first. I happened to run across the caching code in java.net.InetAddress today. We had a couple discussions about this already in the past, e.g. one is here: http://gcc.gnu.org/ml/java/2000-04/msg00106.html I still think this code is incorrect, as it doesn't respect TTL properly. I would like to remove it, which is what this patch does. Sounds good to me. Let the upstream DNS server do the caching, that's what it's there for. Or, at least, this reverts to doing the correct and conservative thing while the correct and optimized thing is being worked on. What we have now is incorrect and optimized :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: SecurityManager troubles
Guilhem Lavaux wrote: I must say that I don't understand this problem. Me neither... I do not think it is strictly linked to the VM. I have produced an artificial stack trace by tweaking kaffe's VM. Normally this stack trace is hidden by the VM and replaced by a NoClassDefFoundError. Here I removed the class preloading from my test. You can see there is a loop in CharsetProvider at least. Maybe it's VM related but it would be really weird. It doesn't happen with JCVM.. but see below.. This block is the loop: at testSM$MySM.checkPermission (testSM.java:17) at java.lang.SecurityManager.checkSecurityAccess (SecurityManager.java:1011) at java.security.Security.getProperty (Security.java:396) at java.lang.SecurityManager$1.run (SecurityManager.java:1055) at java.security.AccessController.doPrivileged (AccessController.java:96) at java.lang.SecurityManager.checkPackageList (SecurityManager.java:1051) at java.lang.SecurityManager.checkPackageAccess (SecurityManager.java:920) at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1108) at java.lang.ClassLoader.loadClass (ClassLoader.java:294) The last loadClass is already loading java/security/Permission and checkPermission needs to load java/security/Permission too. Maybe it is also a SystemProperties trouble ? OK, so this requires that the VM be lazily resolving classes, i.e., java.security.Permission, as referenced by testSM$MySM, is not resolved until checkPermission() is about to be invoked. JCVM resolves classes all at once, so it doesn't have this problem. Having said that, still not sure what the solution is. Seems likely that any class used as a security manager needs to be fully resolved before being used. Perhaps System.setSecurityManager(s) can always invoke Class.forName(s.getClass().getName, true, s.getClass().getClassLoader()). Right now I can't remember if class initialization implies (complete) class resolution. I think it does.. but if not then the above trick wouldn't necessarily work. Clearly it does NOT in kaffe, otherwise the above example couldn't happen. Hmm, maybe System.setSecurityManager() can do a phony invocation of s.checkPermission() to ensure that it's resolved... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Archie Cobbs wrote: Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? There's no reason strtod() should be thread-unsafe. It doesn't return a static buffer or remember any state across calls. In any case, I'm not familiar enough with the code to understand whether using the system strtod(3) would avoid this assertion failure, which appears to come from Balloc in mprec.c. Sorry for the noise, that email got delayed several hours for some reason. As we now know strtod() has different behavior than desired... In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Assertion failure
FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Mark Wielaard wrote: Subversion support for savannah is planned in the future. And it might make sense to adopt it then since other projects that rely on GNU Classpath also use it and it makes merging easier. On the other hand That would be great. subversion is still a bit immature and not widely supported yet (for example on builder.classpath.org we needed to install the latest 1.3.0rc4 to get around some network timeout issues). CVS might be old and clumsy at times, it is much more mature and supported atm. That said, if savannah adds subversion support I would vote for us to switch. I think you're information is slightly dated :-) Subversion is quite matture. The 1.0 release, which itself was very stable, was released almost two years ago. Now they're up to version 1.2.3. For example, all of Apache is on a single Subversion server and they're up to revision #356264 (including imported CVS commits). We've used it at my real job for over a year with zero problems. As far as being supported, not sure what you're referring to. Everything I've ever wanted to do with CVS I can do with SVN, plus a lot more. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Re: RFC: Patch for duplicate entries in serialPersistentFields
Stuart Ballard wrote: Jeroen pointed out to me a while back that you can use generics to throw an unchecked exception: There's also a way to do this without using JDK 1.5 stuff, but it's even uglier :-) Construct a class (dynamically) that has a default constructor that simply throws whatever exception you want. Then invoke Class.newInstance() on the class. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Mark Wielaard wrote: - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath Hmm.. could this new infrastructure include possible a switchover from CVS to Subversion? (I'm so used to SVN now that CVS is gotten pretty gross to deal with). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] [generics] RFC: fix generics branch compilation on Darwin
Casey Marshall wrote: This puts the 'environ' declaration/define in jcl.h; I hope this is OK, it looks like the best place for a global thing like this. What you have now results in a duplicate declaration of environ on systems that already declare environ in unistd.h (or wherever), but don't have a crt_externs.h. Not a big deal (the build should still work) but it will cause a GCC warning with -Wredundant-decls. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote:
I don't know if this is performance critical code or is used very often,
but this seems to be a special case and i'd suggest something like:
public void write (int oneByte) throws IOException
{
try {
out.write(oneByte);
return;
} catch (NullPointerException e) {
throw new IOException(Bad file descriptor);
}
}
I'll not win a beautiful-code prize, but will be compiled to the fastest
code.
That's getting into the micro-optimzation realm, which is
fraught with danger and mistaken assumptions :-) E.g., on
some machines the time overhead of setting up a try/catch in
a method that wouldn't otherwise have one is higher than
the single comparison required to test for null. In particular,
any interpreter is going to have to test for null anyway,
so the second time it's already in cache, blah blah, etc.
Not to mention that the space overhead of a try/catch (vs. none)
will probably be higher too. So IMHO it's better to avoid
too much of this kind of thing (unless it actually makes the
source code clearer (don't think so in this case)).
Apologies for the minor IMHO rant.. :-)
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote: That's getting into the micro-optimzation realm, which is fraught with danger and mistaken assumptions :-) E.g., on some machines the time overhead of setting up a try/catch in a method that wouldn't otherwise have one is higher than the single comparison required to test for null. In particular, any interpreter is going to have to test for null anyway, so the second time it's already in cache, blah blah, etc. ...setting up a try/catch...? What do you mean? Agreed on the Simply that on some VM's there is overhead associated with executing code that can possibly catch an exception, even if no exception is actually thrown. For example, locals might be stored on the stack instead of in registers if the engine doesn't know how to unwind registers. Not to mention that the space overhead of a try/catch (vs. none) will probably be higher too. So IMHO it's better to avoid too much of this kind of thing (unless it actually makes the source code clearer (don't think so in this case)). Actually the generated code is smaller and i don't think there is too much space overhead in the VM (at least not in CACAO). Yes, the code is not clearer but it's just a 6-liner in a core class... so it should be understandable for everyone :-) You say the generated code is smaller but that depends on who generates the code (if you mean the generated Java bytecode, I'd guess you're wrong there too because of the extra exception table required). And that depends on which VM you're using.. which is my only point: it all depends, so you can't assume anything for sure. I didn't really mean to criticize this change so much as the idea of initiating a wild goose chase of similar changes which may or may not actually improve anything. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: Opening RandomAccessFiles requires excessive permission
Christian Thalinger wrote: what i'm trying to say is, if we ever want to catch up (or even be better) than sun or other proprietary JVMs, we should think about optimizing some core functions in classpath... I definitely agree there. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Kerberos
Jeff Bailey wrote: Sorry, I chose my words poorly there. By 'native' I meant Done in Java. Is there a better word that means that? =) Pure Java... ? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[cp-patches] VMStackWalker infinite loop fix
I've committed the attached patch to fix an infinite loop between VMStackWalker.getCallingClassLoader() and Class.getClassLoader(). 2005-11-13 Archie Cobbs [EMAIL PROTECTED] * vm/reference/gnu/classpath/VMStackWalker.java (getClassLoader()): added to fix an infinite loop bug. * NEWS: note VM interface change. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: NEWS === RCS file: /cvsroot/classpath/classpath/NEWS,v retrieving revision 1.104 diff -u -r1.104 NEWS --- NEWS2 Nov 2005 22:31:47 - 1.104 +++ NEWS13 Nov 2005 22:25:48 - @@ -1,3 +1,10 @@ +New in release 0.20 + +Runtime interface changes: + +* New method VMStackWalker.getClassLoader() was added to avoid an infinite + loop between getCallingClassLoader() and Class.getClassLoader(). + New in release 0.19 (Nov 2, 2005) * The Swing RepaintManager has been reworked for more efficient painting, Index: vm/reference/gnu/classpath/VMStackWalker.java === RCS file: /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java,v retrieving revision 1.5 diff -u -r1.5 VMStackWalker.java --- vm/reference/gnu/classpath/VMStackWalker.java 2 Jul 2005 20:33:08 - 1.5 +++ vm/reference/gnu/classpath/VMStackWalker.java 13 Nov 2005 22:25:51 - @@ -88,9 +88,9 @@ /** * Get the class loader associated with the Class returned by - * codegetCallingClass()/code, or codenull/code if no - * such class exists or it is the boot loader. This method is an optimization - * for the expression codegetClassContext()[1].getClassLoader()/code + * codegetCallingClass()/code, or codenull/code if no such class + * exists or it is the boot loader. This method is an optimization for the + * expression codeVMStackWalker.getClassLoader(getClassContext()[1])/code * and should return the same result. * * p @@ -102,7 +102,15 @@ Class[] ctx = getClassContext(); if (ctx.length 3) return null; -return ctx[2].getClassLoader(); +return getClassLoader(ctx[2]); } + + /** + * Retrieve the class's ClassLoader, or codenull/code if loaded + * by the bootstrap loader. I.e., this should return the same thing + * as [EMAIL PROTECTED] java.lang.VMClass#getClassLoader}. This duplicate version + * is here to work around access permissions. + */ + public static native ClassLoader getClassLoader(Class cl); } ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Announcing JCVM release 1.4.7
JC is a Java virtual machine implementation that converts class files into C source files using the Soot Java bytecode analysis framework, compiles them with GCC, and loads them using a built-in ELF object file loader. JC utilizes the GNU Classpath class library and provides a fairly complete Java runtime including sophisticated optimizations to increase runtime performance. JC also includes a bytecode interpreter, and supports execution in either or mixed modes. http://jcvm.sourceforge.net/ Changes in version 1.4.7: - Fixed potential assertion failure in VMStackWalker.getClassContext(). - Upgrade to Classpath 0.19. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./NEWS ./ChangeLog vm/reference/gnu/c...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Archie Cobbs [EMAIL PROTECTED]05/11/13 22:29:45 Modified files: . : NEWS ChangeLog vm/reference/gnu/classpath: VMStackWalker.java Log message: * vm/reference/gnu/classpath/VMStackWalker.java (getClassLoader()): added to fix an infinite loop bug. * NEWS: note VM interface change. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/NEWS.diff?tr1=1.104tr2=1.105r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5568tr2=1.5569r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java.diff?tr1=1.5tr2=1.6r1=textr2=text
[cp-patches] Fix for autogen.sh
I've checked in this fix for autogen.sh on FreeBSD.
2005-11-11 Archie Cobbs [EMAIL PROTECTED]
* autogen.sh: Fix broken libtool version detection on FreeBSD.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: autogen.sh
===
RCS file: /cvsroot/classpath/classpath/autogen.sh,v
retrieving revision 1.13
diff -u -r1.13 autogen.sh
--- autogen.sh 3 Sep 2005 20:32:04 - 1.13
+++ autogen.sh 11 Nov 2005 17:44:31 -
@@ -16,7 +16,7 @@
have_libtool=false
if ${LIBTOOLIZE} --version /dev/null /dev/null 21 ; then
- libtool_version=`${LIBTOOLIZE} --version | sed
's/^[^0-9]*\([0-9.][0-9.]*\).*/\1/'`
+ libtool_version=`${LIBTOOLIZE} --version | sed
's/^.*[^0-9.]\([0-9]\{1,\}\.[0-9.]\{1,\}\).*/\1/'`
case $libtool_version in
1.5*)
have_libtool=true
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Infinite loop
Jeroen Frijters wrote: The infinite loop is simple: Class.getClassLoader() invokes VMStackWalker.getCallingClassLoader() VMStackWalker.getCallingClassLoader() invokes Class.getClassLoader() It would be nice if VMStackWalker.getCallingClassLoader() could invoke VMClass.getClassLoader(), but access permissions prevent that. Any ideas? One idea is to move VMStackWalker into java.lang. We can't do that, it needs to be public. I guess that VMStackWalker should have a native method to get the class loader from a Class. Sounds good.. how about this? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: VMStackWalker.java === RCS file: /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java,v retrieving revision 1.5 diff -u -r1.5 VMStackWalker.java --- VMStackWalker.java 2 Jul 2005 20:33:08 - 1.5 +++ VMStackWalker.java 9 Nov 2005 17:44:29 - @@ -88,9 +88,9 @@ /** * Get the class loader associated with the Class returned by - * codegetCallingClass()/code, or codenull/code if no - * such class exists or it is the boot loader. This method is an optimization - * for the expression codegetClassContext()[1].getClassLoader()/code + * codegetCallingClass()/code, or codenull/code if no such class + * exists or it is the boot loader. This method is an optimization for the + * expression codeVMStackWalker.getClassLoader(getClassContext()[1])/code * and should return the same result. * * p @@ -102,7 +102,15 @@ Class[] ctx = getClassContext(); if (ctx.length 3) return null; -return ctx[2].getClassLoader(); +return getClassLoader(ctx[2]); } + + /** + * Retrieve the class's ClassLoader, or codenull/code if loaded + * by the bootstrap loader. I.e., this should return the same thing + * as [EMAIL PROTECTED] java.lang.VMClass#getClassLoader}. This duplicate version + * is here to work around access permissions. + */ + public static native ClassLoader getClassLoader(Class cl); } ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Stuart Ballard wrote: Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? Yes, I suppose so... On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Yes.. all the other methods in there are too. VMStackWalker can only be used by classes loaded via the boot loader (see comment at the top). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
configure failure
Hi all, I'm trying to ./configure classpath-0.19 on Redhat9 and getting this: checking for freetype2... Package freetype2 was not found in the pkg-config search path. Perhaps you should add the directory containing `freetype2.pc' to the PKG_CONFIG_PATH environment variable No package 'freetype2' found configure: error: Library requirements (freetype2) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. $ rpm -qa | grep freetype freetype-2.1.3-6 freetype-devel-2.1.3-6 $ rpm -ql freetype | grep '\.pc' $ I'm not educated on the wonders of pkg-config. Where do I find freetype2.pc and why isn't it on this system? Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: configure failure
Christian Thalinger wrote: On Thu, Nov 03, 2005 at 08:50:40AM -0600, Archie Cobbs wrote: $ rpm -qa | grep freetype freetype-2.1.3-6 freetype-devel-2.1.3-6 $ rpm -ql freetype | grep '\.pc' $ I'm not educated on the wonders of pkg-config. Where do I find freetype2.pc and why isn't it on this system? Hmm, it seems that redhat 9 is too old. In an archive i found that gtk2 is: gtk2-2.2.1-4.i386.rpm Maybe you should try --disable-gtk-peer or upgrade your system :-) --disable-gtk-peer does workaround the problem. But FYI this same system was able to configure classpath-0.17 without that flag. Therefore something changed. I guess 0.17 didn't require freetype? Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updated FreeSwingTestApps
Mark Wielaard wrote: In preparation for the next snapshot on Wednesday I went through the FreeSwingTestApps list. There are now 4 categories Should Work, Starts but doesn't really work, Needs lots of Work and Untested. The first two categories are the most interesting since those are applications that (at least partially) work now. Another good one to test would be the Apache Batik SVG browser. http://xml.apache.org/batik/svgviewer.html This Swing app uses the graphics toolkit very heavily. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updated FreeSwingTestApps
Mark Wielaard wrote: Another good one to test would be the Apache Batik SVG browser. http://xml.apache.org/batik/svgviewer.html This Swing app uses the graphics toolkit very heavily. Interesting application. I am currently unable to get past the (beautiful!) splash screen. The progress bar updates, but then I get some obscure error. Could you add this one to the webpage (probably under and add some comments about what to download where and how to startup plus anything you think is helpful for people wanting to this going? http://developer.classpath.org/mediation/FreeSwingTestApps I added it to the wiki. Download instructions, etc. are on the home page, no need to repeat. You can add more details on the obscure error if you want to. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Has someone experimented with jedit?
David Gilbert wrote: Pointers to other Free-and-not-overly-complex Swing applications are welcome too. I'm happy to try running a few things and fixing some bugs (at least the easy ones). Haven't tried it with Classpath myself, but here's one that might be worth trying: http://pollo.sourceforge.net/ Pollo is a graphical XML editor. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] Patch: convert new Boolean(X) to Boolean.valueOf(X)
David Daney wrote: Archie Cobbs wrote: Mark Wielaard wrote: While messing around with FindBugs, I came up with the following useful patch. It converts all new Boolean(X) instances to Boolean.valueOf(X). Ok? [...] - return new Boolean(true); + return Boolean.valueOf(true); OK, but if you know the actual value then using Boolean.TRUE and Boolean.FALSE seems more appropriate then valueOf(). Could you make that change? That shouldn't be necessary .. the method inliner will likely take care of that (Boolean.valueOf() is guaranteed to return either Boolean.TRUE or Boolean.FALSE) so the ultimate effect should be the same. None of this is necessary. But we do it anyway to make the code better. For me Boolean.TRUE reads much more cleanly than Boolean.valueOf(true). I think it improbable that it is less efficient either. Apologies, I didn't see that you were referring to the specific patch chunk that used the literal constant true.. I completely agree with you in that case! All I meant to say is that Boolean.valueOf(x) is not worse than x ? Boolean.TRUE : Boolean.FALSE. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] DeleteLocalRef() in jcl.c
David Lichteblau wrote: jcl.c currently tries to turn a local reference into a global one after having deleted the local reference. (*env)-DeleteLocalRef(env, rawDataClass); rawDataClass = (*env)-NewGlobalRef (env, rawDataClass); Is my interpretation right that this is not allowed by the JNI spec? Yes.. patch looks OK to me too. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Persuading the apaches
Martin Olsson wrote: Could someone clarify the difference between GPL+Exception and ASF? I'm interested both in the general differences but also specifically: - Why do you guys prefer GPL+Exception over ASLv2 ? Just to clarify: it's not necessarily us guys that prefer GPL+ex over Apache license. Rather (at least in my case) I need to be able to contribute to Classpath, and the only way to do that is to assign copyright assignment to FSF. The FSF owns the copyright and only they have the power to change it. So perhaps you should be asking why does FSF prefer GPL+exception, which may have a more obvious answer. Personally, I'd happily agree to re-license Classpath under a BSD style license or something but that is probably highly unlikely, because I doubt *all* Classpath developers *and* the FSF would agree to that. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] [RFC/JDWP] ClassLoaderReferenceCommandSet
Jeroen Frijters wrote: I strongly agree with Archie. Also, approach #2 is incorrect, because the classes that should be returned are the classes for which this class loader has been recorded as the initiating loader. The class loader doesn't know whether it is the initiating loader or not, only the VM knows this. Tiny clarification.. that should be an initiating loader rather than the initiating loader... there can be more than one for a given class, right? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: Class Loader patch to record class withinitiating class loader
Mark Wielaard wrote: But for a larger change like this it is probably good to get a sign-off by Robert, Stephen, Archie or any other runtime implementor who you know uses pristine Class/ClassLoader classes from GNU Classpath to make sure they agree that they will keep on using them. Or hear from people like Tom, David or Dalibor that the new interfaces will make it easier for them to adopt the GNU Classpath versions. If you have one or two runtime developers with you that say that the change is good and they can/will provide it soon (or at least by the time we do a new snapshot release) then I don't really see a problem checking changes in. We do have to make breaking changes from time to time and people cannot really expect non-released versions to work flawlessly all the time (otherwise we would do a release every day!). For what it's worth, JCVM maintains its own intiated types and defined types tables internally, so this patch does not make life better (or worse). I would have to disable this code. However the larger question of what is the right API is an interesting one... not sure I could venture an answer without a lot of review/study. One possibility I've considered is moving a lot more of the code out of the VM and into Java. This of course would require everyone agreeing on what that code should look like :-) But probably a bigger problem is what to do with the bootstrap loader, which must be usable before any classes are loaded. So in JCVM, the end result is like this: I have to do all the machinery in C anyway for the boot loader, so might as well re-use that same code for user-defined loaders... referring here to the code which e.g. checks whether the requested type is already in the initiated types tree, grabs mutexes, checks whether another thread is already loading the type, adds newly loaded types to the initiated types tree, etc. The net result is that a simpler API where the VM does most of the work is better in JCVM's case. In fact, the current code is more than JCVM needs -- it doesn't need the loadedClasses hash table (so the new USE_VM_CACHE flag is an improvement), nor most of the synchronization. But other VMs may be different of course. So this area is murky and highly VM specific which makes it hard to imagine what the best answer is. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Re: RFC: Class Loader patch to record classwithinitiating class loader
Robert Lougher wrote: In my opinion, the logic for deciding whether to load via the bootstrap or via a classloader, whether to load an array or a normal class, initialization, and the managing of the cache is best done in the runtime for performance reasons. Most of what Robert said above is pretty much true in the same way for JCVM, so I agree :-) Perhaps there is some consensus to make this API simpler instead of more complicated. If we decide to keep it simple, what would definitely be helpful is comprehensive comments for these native methods sketching out what the VM should be doing (e.g., it's not immediately obvious when a type should be added to the initiated types tree, or even that a VM is required to maintain one). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] Re: RFC: New class loader patch proposal
Jeroen Frijters wrote: Here's an alternative patch that rips out most of the complexity and leaves everything to the VM. It took me about three minutes to implement this new interface for IKVM, so I know I'm happy with it! The only thing missing that the documentation should be improved a bit. Rob and Archie, is this (close to) what you both need? Yes, that looks great to me :-) My only comment is that findLoadedClass() needs some Javadoc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] FYI: ClassLoader caching Part 2
Jeroen Frijters wrote: Oh, I'm sorry, I think see what you mean. If a VM would take a binary GNU Classpath jar, it wouldn't be able to override the value of the flag. Is this an important scenario? I thought you long haired types didn't like binary distributions ;-) OK now I get it too... I call this idea of imposing VM-specific versions of a class in front of the stock Classpath versions overlaying instead of overriding to avoid confusion :-) Yes, I think not breaking overlaying is important.. so a static method (with comment why being used) would be better. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: JNI assertion failure
I checked in the aforementioned assertion patch. 2005-07-25 Archie Cobbs [EMAIL PROTECTED] * native/jni/classpath/native_state.c: add assertion for object type -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog native/jni/classpath/nati...
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Archie Cobbs [EMAIL PROTECTED]05/07/25 22:32:51 Modified files: . : ChangeLog native/jni/classpath: native_state.c Log message: * native/jni/classpath/native_state.c: add assertion for object type CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4224tr2=1.4225r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/native/jni/classpath/native_state.c.diff?tr1=1.11tr2=1.12r1=textr2=text ___ Commit-classpath mailing list Commit-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/commit-classpath
Re: JNI assertion failure
Dalibor Topic wrote:
Doesn't GetObjectClass change the state of env? If that's the case, it
maybe shouldn't be an assert.
Not sure what you mean.. but there is a bug: we need to delete the
local native reference obtained by calling GetObjectClass.
Attached is a better patch.
Thanks,
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 24 Jul 2005 22:38:39 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include stdlib.h
+#include assert.h
#include jni.h
#include native_state.h
@@ -165,6 +166,18 @@
*head = new_node;
}
+#ifndef NDEBUG
+static void
+cp_gtk_check_compat (JNIEnv * env, jobject obj, struct state_table *table)
+{
+ jclass objclazz;
+
+ objclazz = (*env)-GetObjectClass(env, obj);
+ assert ((*env)-IsAssignableFrom(env, objclazz, table-clazz));
+ (*env)-DeleteLocalRef(env, objclazz);
+}
+#endif
+
void
cp_gtk_set_state_oid (JNIEnv * env, jobject lock, struct state_table *table,
jint obj_id, void *state)
@@ -214,6 +227,11 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -227,6 +245,11 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -239,6 +262,11 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+#ifndef NDEBUG
+ cp_gtk_check_compat(env, obj, table);
+#endif
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Implementation details of VMStackWalker
[EMAIL PROTECTED] wrote: The next thing I would like to have is a method to get the calling method name. This would be good for logging. You could create a Throwable() object and then get the StackFrame[]. That is what the logging API currently does. But that's terrribly inefficient. We could add a new method to VMStackWalker that returns the calling method name and in the reference implementation it will just do the Throwable thing. Then every VM can decide if they want do add a native method. Sounds reasonable. We take this same approach with getCallingClass() and getCallingClassLoader(), which can be implemented more efficiently in native code, but are also have the fallback Java implementation. For the security part: Is it enough to check if the class loader of context[0] is the boot classloader? Not sure what the question is here. In the VMStackWalker source it says only code loaded from the boot classloader may call the methods of this class. But how should we make sure? My question was if it is enough to check if the class in getClassContext()[0] (i.e. the class that actually invoked a method on VMstackWalker directly or through reflection) was loaded by the boot classloader. I didn't write that comment so I'm not sure how (if at all) it is enforced. Not sure what the real security problem is though, even if we did allow random code to call these methods. Maybe someone else can shed some light? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Implementation details of VMStackWalker
Ingo Prötel wrote: I would like to get the common case where private or protected methods are called before the actual stack check happens. This changes the current semantic but I feel that it would be more useful and less fragile to changes of classes that want to use VMStackWalker. If there is a real need for a method with the current semantic we could just add a method to the interface for the new semantic. None of the existing code in Classpath that uses VMStackWalker calls it through private or protected methods, so I'm not sure why you're saying that having private and protected methods is a common case. Anyway, the reason it's done with the current simple semantics is to make these calls as efficient as possible. Although your semantics would make things more robust in the future, you have to balance that against a (probably small) loss of efficiency. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk/GtkGenericPeer
Here is the relevant stack trace snippet:
#7 0x29f862d7 in
Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2
(env=0x107ed6a0, obj=0x29795698, peer=0x2979569c)
at gnu_java_awt_peer_gtk_GdkGraphics.c:154
Hmm, no response.. can anyone else confirm this problem??
It looks like this code is completely broken, because
it's trying to save a pointer in a field that doesn't
exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says:
NSA_SET_PTR (env, obj, g)
but obj is a gnu/java/awt/peer/gtk/GdkGraphics object, not
a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that
contains the native_state field.
Since nobody seems to be listening, I'm going to check in the
attached patch. This will cause all programs that use the GTK
peer to crash with an assertion failure. Sorry! The code
is broken but I don't know how to fix it. At least now we get
an assertion failure instead of random memory corruption.
You have been warned :-)
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: native/jni/classpath/native_state.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/classpath/native_state.c,v
retrieving revision 1.11
diff -u -r1.11 native_state.c
--- native/jni/classpath/native_state.c 14 Jul 2005 22:07:02 - 1.11
+++ native/jni/classpath/native_state.c 23 Jul 2005 19:30:28 -
@@ -36,6 +36,7 @@
exception statement from your version. */
#include stdlib.h
+#include assert.h
#include jni.h
#include native_state.h
@@ -214,6 +215,10 @@
cp_gtk_set_state (JNIEnv * env, jobject obj, struct state_table *table, void
*state)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -227,6 +232,10 @@
cp_gtk_get_state (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
@@ -239,6 +248,10 @@
cp_gtk_remove_state_slot (JNIEnv * env, jobject obj, struct state_table *table)
{
jint obj_id;
+
+ assert ((*env)-IsAssignableFrom(env,
+(*env)-GetObjectClass(env, obj), table-clazz));
+
obj_id = (*env)-GetIntField (env, obj, table-hash);
if ((*env)-ExceptionOccurred (env) != NULL)
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: hasClassInitializer and exception
Nicolas Geoffray wrote: there is something that might be wrong in the implementation of VMObjectStreamClass.hasClassInitializer (native/jni/java-io/java_io_VMObjectStreamClass.c). It uses GetStaticMethodID and tests if an exception occured to see if the clinit method exists. The thing is, in the spec, GetStaticMethodID has to clinit the class. Imagine there is a clinit and the clinit raises and exception, the result of hasClassInitializer would be false. How about this: add this line to ObjectStreamClass before calling VMObjectStreamClass.hasClassInitializer to force class initialization ahead of time: Class.forName(cl.getName(), true, cl.getClassLoader()); Then we'll know that any exception thrown in the JNI code is not an initializer exception. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [cp-patches] RFC: misc NIO fixes
Casey Marshall wrote:
Attached is a patch I'd like to get some comments on, before I check it
in, especially if anyone can spot holes in my C. This patch
+ /* FIXME: I'd bet dollars for donuts the compiler optimizes this
+ away. How can we load memory into core??? */
+ for (i = 0; i size; i += pagesize)
+{
+ foo += ((int *) address)[i];
+}
}
You can force the memory to be accessed e.g. like this:
for (i = 0; ... )
*((volatile int *)address + i;
Otherwise looks good after a quick scan.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: String.equals optimisation
Simon Kitching wrote: * Class.getName returns strings that have been interned. I don't think this is explicitly required by the java specs but is certainly true for Sun's JVM and seems likely to be done by any sensible JVM. You definitely make some good arguments, but this one is not neccesarily true. In fact, I'd argue a JVM that interns every class' name (even if only on demand) is potentially wasting a bunch of heap space. I'm assuming that the Class object would contain a reference to the interned string, so there is only one copy of the string, ie somewhere Not a valid assumtion.. in JC no String is associated with Class objects. VMClass.getName() is native and the returned String is created on demand, based on the UTF-8 name stored internally in memory. In fact, one could argue that storing class names in any other way than in their native UTF-8 form is a big waste of memory. E.g., for loaded classes... If the VM can find it's UTF-8 name and create a String dynamically: Then also storing the class name persistently as a String is a 200% increase in memory (a char[] array is twice as big as UTF-8) Else: The VM must store the class name as a String, which is a 100% increase in memory vs. storing it as UTF-8 The extra space used for interning is therefore just a single extra reference (as a reference to the string is contained in both the Class object and the String class internal pool). Yes that is a little space wasted, but not a bunch. Right, the wasted space is not much.. at first I was forgetting that intern'd strings are stored with weak keys and will get flushed out after they're no longer referenced (just like normal Strings)... replace big waste of memory with waste of memory :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String class: hack for ORP 1.0.9
David P Grove wrote: So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the method larger, and thus a slightly less attractive candidate for inlining), but if it actually buys you any measurable speedup on a high performance VM, then you should really take a hard look at your VM/JIT and find out why they didn't do a good job on the unoptimized version in the first place. clone() on an array is just a short hand for a new followed by an arraycopy, and the new followed by arraycopy idiom shows up all over the place so you need to do a good job on it. Not all VM's are high performance I guess :-) [I'm sure you know all this already but here goes..] E.g., on many VM's VMSystem.arraycopy() is a native method, and they can't optimize into that method. So all the normal type checking, array bounds checking, and array compatibility checking will be done by that native code in all cases, even though in this case we know it's not necessary. With array clone(), also typically a native method, none of that checking is ever needed. This is a good example of the advandages of a JVM written in Java (a coincidence? :-) There is no optimization barrier into native code like System.arraycopy(). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: regression in logger?
David P Grove wrote: This started showing up in regression tests of Jikes RVM with classpath cvs head recently. I haven't dug deeply, so it could be a latent problem in Jikes RVM that was exposed by a classpath change, rather than a real classpath bug, but might still be worth mentioning. The failing program is SPECjbb2000. --dave Exception in thread main: java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0 at java.util.logging.Logger.getCallerStackFrame(Logger.java:1173) Looks like this can only happen if the VM doesn't return Throwable stack traces. Is this with 0.16? There were recent changes in the VMThrowable class (see NEWS) that might need to be followed in Jikes RVM. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: String.equals optimisation
Simon Kitching wrote:.
* Class.getName returns strings that have been interned. I don't
think this is explicitly required by the java specs but is
certainly true for Sun's JVM and seems likely to be done by
any sensible JVM.
You definitely make some good arguments, but this one is not
neccesarily true. In fact, I'd argue a JVM that interns every
class' name (even if only on demand) is potentially wasting
a bunch of heap space.
I.e., is there something special about class names which means
they should be treated differently from any other String randomly
created and used in a Java application? (rhetorical question)
Otherwise, why not intern all Strings? Etc.
In any case, to provide two concrete counter-examples:
$ cat zz.java
public class zz {
public static void main(String[] args) {
zz z = new zz();
System.out.println(z.getClass().getName() == zz);
}
}
$ javac zz.java
$ java zz
true
$ jc -Xint zz
false
$ jamvm zz
false
On the other hand, comparing reference equality is very low cost,
so it seems like adding == to equals() might make good sense.
Of course, the real answer lies in empirical testing (something
I can't claim to have done).
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: String class: hack for ORP 1.0.9
Simon Kitching wrote:
public char[] toCharArray()
{
// XXX ORP 1.0.9 crashes on (char[]) clone() during bootstrap, so we
// omit this optimization for now.
// if (count == value.length)
// return (char[]) value.clone();
char[] copy = new char[count];
VMSystem.arraycopy(value, offset, copy, 0, count);
return copy;
}
I just wondered if it was time to remove this hack...
Sounds good to me... and in any case, ORP should be doing it's
own disoptimization for VM-specific issues like this rather than
forcing it on all Classpath users.
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: JNI assertion failure
Archie Cobbs wrote: With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 Hmm, no response.. can anyone else confirm this problem?? It looks like this code is completely broken, because it's trying to save a pointer in a field that doesn't exist. Line 154 of gnu_java_awt_peer_gtk_GdkGraphics.c says: NSA_SET_PTR (env, obj, g) but obj is a gnu/java/awt/peer/gtk/GdkGraphics object, not a gnu/java/awt/peer/gtk/GtkGenericPeer object, the class that contains the native_state field. I'm not familiar with this code so I could be completely misunderstanding something. But it seems obviously wrong, and on VM's that don't check proper JNI usage will result in random memory corruption. I'd appreciate a quick confirmation from another set of eyes... Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fix for java/net/URLClassLoader
This patch (checked in) fixes two Mauve tests and removes some
obsolete code.
2005-07-09 Archie Cobbs [EMAIL PROTECTED]
* java/net/URLClassLoader.java: disallow directories as resources
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
--- java/net/URLClassLoader.java.orig 2005-07-09 15:07:42.0 -0500
+++ java/net/URLClassLoader.java2005-07-09 15:06:06.0 -0500
@@ -536,7 +536,7 @@
Resource getResource(String name)
{
File file = new File(dir, name);
- if (file.exists())
+ if (file.exists() !file.isDirectory())
return new FileResource(this, name, file);
return null;
}
@@ -554,36 +554,11 @@
InputStream getInputStream() throws IOException
{
- // Delegate to the URL content handler mechanism to retrieve an
- // HTML representation of the directory listing if a directory
- if (file.isDirectory())
-{
- URL url = getURL();
- return url.openStream();
-}
- // Otherwise simply return a FileInputStream
return new FileInputStream(file);
}
public int getLength()
{
- // Delegate to the URL content handler mechanism to retrieve the
- // length of the HTML representation of the directory listing if
- // a directory, or -1 if an exception occurs opening the directory.
- if (file.isDirectory())
-{
- URL url = getURL();
- try
-{
- URLConnection connection = url.openConnection();
- return connection.getContentLength();
-}
- catch (IOException e)
-{
- return -1;
-}
-}
- // Otherwise simply return the file length
return (int) file.length();
}
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog java/net/URLClassLoader.java
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Archie Cobbs [EMAIL PROTECTED]05/07/09 20:12:00 Modified files: . : ChangeLog java/net : URLClassLoader.java Log message: * java/net/URLClassLoader.java: disallow directories as resources CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4036tr2=1.4037r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/net/URLClassLoader.java.diff?tr1=1.31tr2=1.32r1=textr2=text ___ Commit-classpath mailing list Commit-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/commit-classpath
JNI assertion failure
With Classpath 0.16, trying to run a very simple Swing demo under JCVM, I get a JNI assertion failure in a call to GetIntField(), because the object type and the fieldID are not compatible: gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of gnu/java/awt/peer/gtk/GtkGenericPeer Here is the relevant stack trace snippet: #4 0x282d6c1b in abort () from /lib/libc.so.5 #5 0x280ae91d in GetIntField (jenv=0x107ed6a0, obj=0x29795698, field=0x107527c8) at jni_native.c:82 #6 0x29f99d72 in set_state (env=0x107ed6a0, obj=0x29795698, table=0x10471440, state=0x109ea4c0) at native_state.c:217 #7 0x29f862d7 in Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__Lgnu_java_awt_peer_gtk_GtkComponentPeer_2 (env=0x107ed6a0, obj=0x29795698, peer=0x2979569c) at gnu_java_awt_peer_gtk_GdkGraphics.c:154 #8 0x280d4289 in _jc_dynamic_invoke (func=0x29f86214, jcni=0, nparams=3, ptypes=0x2979562c \n\n\n\t, nwords=3, words=0x29795620, retval=0x107ed628) at arch/i386/arch_functions.c:336 #9 0x280aa802 in _jc_invoke_jni_a (env=0x107ed600, method=0x107f9d60, func=0x29f86214, obj=0x85e0308, params=0x29795754) at invoke.c:692 Could an AWT person take a look at the above trace and error? Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fix for configure test
2005-07-03 Archie Cobbs [EMAIL PROTECTED] * m4/acinclude.m4: fix broken expr(1) syntax -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: m4/acinclude.m4 === RCS file: /cvsroot/classpath/classpath/m4/acinclude.m4,v retrieving revision 1.4 diff -u -r1.4 acinclude.m4 --- m4/acinclude.m4 17 Jun 2005 19:32:13 - 1.4 +++ m4/acinclude.m4 3 Jul 2005 20:02:54 - @@ -147,7 +147,7 @@ JIKES_VERSION=`$JIKES --version | awk '/^Jikes Compiler/' | cut -d ' ' -f 5` JIKES_VERSION_MAJOR=`echo $JIKES_VERSION | cut -d '.' -f 1` JIKES_VERSION_MINOR=`echo $JIKES_VERSION | cut -d '.' -f 2` -if expr $JIKES_VERSION_MAJOR == 1 /dev/null; then +if expr $JIKES_VERSION_MAJOR = 1 /dev/null; then if expr $JIKES_VERSION_MINOR \ 19 /dev/null; then JIKES= fi ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[commit-cp] classpath ./ChangeLog m4/acinclude.m4
CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Archie Cobbs [EMAIL PROTECTED]05/07/03 20:06:15 Modified files: . : ChangeLog m4 : acinclude.m4 Log message: * m4/acinclude.m4: fix broken expr(1) syntax CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.3976tr2=1.3977r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/m4/acinclude.m4.diff?tr1=1.4tr2=1.5r1=textr2=text ___ Commit-classpath mailing list Commit-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/commit-classpath
Re: [cp-patches] [RFA/JDWP] IdManager
Keith Seitz wrote: + /* Mapping of class (Class) to IDs (ReferenceTypeId) for reference + types. Unlike other types, reference id types are NEVER released. */ + private Hashtable _classTable; What if a class(loader)s are garbage collected? Would this hash table then become a memory leak?gets Yes, but unfortunately, JDWP specifically says that reference type IDs are never reused, even if the classes are gc'd or unloaded. The same ID is valid for any reference type for the entirety of the debugging session. Or at least that's how I interpret this explanation of referenceTypeId: Uniquely identifies a reference type in the target VM. It should not be assumed that for a particular class, the classObjectID and the referenceTypeID are the same. A particular reference type will be identified by exactly one ID in JDWP commands and replies throughout its lifetime A referenceTypeID is not reused to identify a different reference type, regardless of whether the referenced class has been unloaded. This seems to only imply that whoever is creating ReferenceTypeID's must create a new and unique one every time, not that you need to cache them after the associated class has been unloaded... ? In any case, how is a class ever going to be unloaded if your Hashtable is referencing it? :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [RFA/JDWP] ReferenceKey
Keith Seitz wrote: Okay, here'e where the weirdness starts. The ID manager (not yet submitted) keeps a table which map objects to IDs. This is used to quickly lookup Objects to see if they have an ID associated with them already. The ReferenceKey class is a SoftReference class with some logic to allow the ID manager to clean-up garbage-collected Objects and their ReferenceKeys. Coupla questions. Disclaimer: I haven't really been paying attention, so ignore me if these are stupid irrelevant.. - Could java.util.WeakHashMap be used instead of writing your own? See java.lang.VMString.intern() for an example. - Do you mean to use hashCode()/equals() or System.identityHashCode()/==? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: How to handle properties file
Mark Wielaard wrote: Maybe we could actually provide the native glibj.zip file reading functionality completely in our vm reference code through zlib. That might not be such a bad idea since almost every runtime will need zlib to load the bootstrap classes and resources. The only trick is to make it flexible enough to be integrated into the various ways runtimes load classes. Archie, I believe you said you had such code for JCVM and that you would consider donating that to GNU Classpath for use with other runtimes. If you have and want to could you send that code to the (patches) list? Do other runtime implementers think they would adopt such shared bootstrap class loading code, or is that something that is too wired into the actual runtime to be easy to share in a generic way? The ZIP file reader in JC is welcome to anyone to use. It's fairly well self-contained in one file (zip.c) plus structure and macro definitions in structures.h and definitions.h. I believe SableVM is already using it. I'll happy re-license and/or donate to Classpath. However, it doesn't seem appropriate for it to go into Classpath, or at least I'm not sure I understand how it would work exactly, since there is the obvious bootstrap problem with Java binding. The relevant files for perusal... http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/zip.c http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/definitions.h http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/libjc/structures.h -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Tom Tromey wrote: Archie However, it doesn't seem appropriate for it to go into Classpath, Archie or at least I'm not sure I understand how it would work exactly, Archie since there is the obvious bootstrap problem with Java binding. I think if we have pieces of code that are usable by a number of VMs, Classpath would make a good clearinghouse for them, whether they are written in C or Java or whatever. Perhaps we can install a /usr/local/lib/classpath/libzipjar.so or whatever shared library. Then VM's can link to it (or dlopen() it) if they please... we'll also need a header file. I don't have time to do this right now (I'm slow when it comes to automake, etc.) but can help get the source files ready for import, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
API cleanup
I committed the API cleanup patch. * NEWS: document VM interface changes. * java/lang/ClassLoader.java: (vmdata): add * vm/reference/java/lang/VMClass.java: (getModifiers()): add new parameter ignoreInnerClassesAttrib * vm/reference/java/lang/VMClassLoader.java: (defineClass()): remove deprecated version (getPrimitiveClass(String)): remove (getPrimitiveClass(char)): make native (loadClass()): make native * vm/reference/java/lang/VMThread.java: (vmdata): add (countStackFrames()): make native * vm/reference/java/lang/VMThrowable.java: (vmdata): add (fillInStackTrace()): make native (getStackTrace()): make native * vm/reference/java/lang/reflect/Constructor.java: (parameterTypes, exceptionTypes): remove (getParameterTypes(), getExceptionTypes()): make native -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: How to handle properties file
Michael Koch wrote: I didn't know that function. Powerfull! So then, shouldn't the function readConfiguration from LogManager make a call like LogManager.class.getResourceAsStream(java/util/logging/logging.properties); to have an InputStream instead of looking for system properties? Use java.util.Properties.load(InputStream) with it. I think people are missing Nicolas' point here. The class LogManager is broken, because it is looking in the wrong place for the properties file. Does anyone know what the correct behavior is supposed to be? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
