Committed.
Fix for PR 48131.
Handle empty tree.
Index: InflaterHuffmanTree.java
===
RCS file: /cvsroot/classpath/classpath/java/util/zip/InflaterHuffmanTree.java,v
retrieving revision 1.8
diff -u -r1.8 InflaterHuffmanTree.java
---
Hello Ivan,
The JDK also fails to open zip files that contain encrypted entries.
Regards,
Jeroen
-Original Message-
From: Ivan Maidanski [mailto:iv...@mail.ru]
Sent: Wednesday, July 14, 2010 7:56 AM
To: Andrew John Hughes
Cc: classpath-patches; Daniel Noll; Jeroen Frijters
Subject
Hello,
I've committed the patch below and closed the bug.
Regards,
Jeroen
Index: InflaterHuffmanTree.java
===
RCS file: /cvsroot/classpath/classpath/java/util/zip/InflaterHuffmanTree.java,v
retrieving revision 1.7
diff -u -r1.7
Hello,
I've committed the patch below.
When a zip file contains an encrypted entry, we should throw a ZipException (as
the JDK does) while reading the zip file directory.
This has been in IKVM.NET's ZipFile implementation (which is a fork of GNU
Classpath's) for a while.
Regards,
Jeroen
Andrew Haley wrote:
It's not just static compilation: if you look at
VMThread.currentThread() you'll probably see something like
extern DWORD _Jv_ThreadKey;
return (java::lang::Thread *) TlsGetValue(_Jv_ThreadKey);
or
extern pthread_key_t _Jv_ThreadKey;
return
Andrew Haley wrote:
Why? If you're going to call pthread_getspecific() to get the current
thread, you might as well call it to get the thread-local variable.
That remains true regardless of GC, TL inheritance, or anything else.
PTHREAD_KEYS_MAX is very low on some OSes compared with the needs
Ian Rogers wrote:
the attached patch stops the lazy initialization of a Calendar object
in ZipEntry and instead uses a static final one. It also modifies the
clone method to instead of using Object.clone to use the ZipEntry's own
copy constructor.
ZipEntry isn't final, so you must use
Hi,
I committed the rather obvious fix below.
Regards,
Jeroen
2008-01-07 Jeroen Frijters [EMAIL PROTECTED]
* java/awt/image/Raster.java
(createInterleavedRaster): Fixed ComponentSampleModel constructor
argument order.
Index: Raster.java
Hi,
Committed.
Regards,
Jeroen
2007-11-08 Jeroen Frijters [EMAIL PROTECTED]
* java/util/Locale.java
(Locale): Always intern strings.
Index: Locale.java
===
RCS file: /cvsroot/classpath/classpath/java/util
Christian Thalinger wrote:
On Tue, 2007-09-18 at 06:47 +0200, Jeroen Frijters wrote:
I believe you are correct that Classpath doesn't currently support
the
system assertions boolean. I believe you are also correct in assuming
that noone cares ;-)
Does the Classpath code even have any
Christian Thalinger wrote:
On Tue, 2007-09-04 at 10:25 +0200, Christian Thalinger wrote:
OK, this email was a bit short without much explanation. We're
currently implementing assertion support in CACAO (means the -ea/-da
command line switches) and Gregor, our student doing this, noticed
Ian Rogers wrote:
Thanks Jeroen, it's clear now. The problem with a phantom reference is
that when we collect the thread local we should also really make
collectable all of the values set to thread locals. A phantom reference
won't do this and so introduces a memory leak until something can
Ian Rogers wrote:
the attached patch modifies ThreadLocal to use an array of Objects hung
off Thread rather than a weak hash map hung off Thread. On DaCapo's
Jython benchmark this can improve the performance of the Jikes RVM by
more than 10%. It also improves other DaCapo benchmark
Ian Rogers wrote:
One bug in the current implementation is that if the thread local
overrides hashcode and/or equal it can be made to collide with other
thread locals.
No, it uses an Weak*Identity*HashMap.
Regards,
Jeroen
Ian Rogers wrote:
here is the revised patch.
+ int arraySize = group.activeCount();
+ Thread[] threadList = new Thread[arraySize];
+ int filled = group.enumerate(threadList);
+ while (filled == arraySize)
+ {
+arraySize *= 2;
+threadList = new
Ian Rogers wrote:
How can then the thread local be resurrected after the finalizer is
run?
All the references in ThreadLocal and InheritableThreadLocal are weak
and will be atomically cleared prior to the finalizer being run. All
other references must be dead for the finalizer to have been
Ian Rogers wrote:
Anyway, this design decision seems to hang off how weak references are
finalized. If they are finalized on their own finalizer thread then the
final local index design is fine and preferable imo to the volatile
design or a weak identity hash map (however cached or stream
Hi,
Committed.
Regards,
Jeroen
2007-06-21 Jeroen Frijters [EMAIL PROTECTED]
* java/io/ObjectStreamClass.java (getClassUID): Return 0L for
enums and proxies.
Index: ObjectStreamClass.java
===
RCS file: /cvsroot
Hi,
I committed the patch below. It fixes a bug when the passed in service or
algorithm aren't in the correct case (the initial lookup is case insenstive,
but later on provider.getProperty() was called with the incorrectly cased key).
Regards,
Jeroen
2007-06-21 Jeroen Frijters [EMAIL
Hi,
Committed.
Regards,
Jeroen
2007-06-21 Jeroen Frijters [EMAIL PROTECTED]
Fixes #32356
* java/lang/reflect/Array.java
(newInstance(Class,int[])): Call createMultiArray correctly.
(createMultiArray): Fixed dimensions processing order.
Index: java/lang
Hi,
Committed.
Regards,
Jeroen
2007-05-23 Jeroen Frijters [EMAIL PROTECTED]
* java/util/Arrays.java
(copyOfRange(T,int,int)): Fixed to instantiate right array type.
Index: Arrays.java
===
RCS file: /cvsroot
Hi,
While merging in the Sun double/float toString/parsing in IKVM, I found that
the Float/VMFloat interface wasn't properly factored to support this. This
patch (already committed) fixes that.
Regards,
Jeroen
2007-05-11 Jeroen Frijters [EMAIL PROTECTED]
* java/lang/Float.java
Hi,
Committed. Mark, please consider applying to 0.95 as well.
Regards,
Jeroen
2007-04-23 Jeroen Frijters [EMAIL PROTECTED]
PR classpath/31646:
* java/util/Arrays.java (qsort): Corrected initial median calculation.
Index: Arrays.java
Hi,
Committed.
Regards,
Jeroen
2007-03-31 Jeroen Frijters [EMAIL PROTECTED]
PR classpath/31402:
* java/util/concurrent/CopyOnWriteArrayList.java
(remove): Fixed ArrayIndexOutOfBoundsException when index == 0.
Index: CopyOnWriteArrayList.java
Hi,
My previous Socket patch broke ServerSocket. This fixes it again. Sorry for the
inconvenience.
Regards,
Jeroen
2007-03-23 Jeroen Frijters [EMAIL PROTECTED]
* java/net/ServerSocket.java (implAccept): set implCreated flag on
socket.
* java/net/Socket.java
Hi,
I committed the attached patch.
Regards,
Jeroen
2007-03-19 Jeroen Frijters [EMAIL PROTECTED]
* java/net/Socket.java
(implCreated): New field.
(getImpl): Call impl.create() if it hasn't been called yet.
(bind): Removed explicit impl.create() call.
Index
Hi,
I think we need the patch below to fix the following case:
Socket sock = new Socket();
sock.setKeepAlive(false);
Currently this throws a NullPointerException (on IKVM at least), because the
impl.create() hasn't been called yet.
Any comments?
Regards,
Jeroen
Index: java/net/Socket.java
David Daney wrote:
Jeroen Frijters wrote:
Hi,
I think we need the patch below to fix the following case:
Socket sock = new Socket();
sock.setKeepAlive(false);
Currently this throws a NullPointerException (on IKVM at least),
because the impl.create() hasn't been called yet
Hi,
I committed the attached patch.
Regards,
Jeroen
2007-02-04 Jeroen Frijters [EMAIL PROTECTED]
Fix for #30693
* gnu/java/nio/charset/ByteCharset.java
(ByteCharset.Decoder.decodeLoop): Reset input buffer position if
the byte read was unmappable.
Index: gnu
Hi,
I committed the attached patch.
Regards,
Jeroen
2007-02-04 Jeroen Frijters [EMAIL PROTECTED]
* java/lang/Class.java
(newInstance): Moved setAccessible call to helper method.
(getEnumConstants): Call new helper method to allow values method to be
called
David Daney wrote:
Jeroen Frijters wrote:
throw new RuntimeException(error instantiating default
socket factory:
- + ex.toString());
That sounds more like an InternalError than the super-generic
RuntimeException.
Possibly. I don't
David Daney wrote:
Jeroen Frijters wrote:
David Daney wrote:
Jeroen Frijters wrote:
throw new RuntimeException(error
instantiating default
socket factory:
- + ex.toString());
That sounds more like
Casey Marshall wrote:
Really? That seems like worse behavior than just giving up when
trying to create the factory. Just delaying exceptions like that
seems like it will just hide bugs, instead of forcing you to deal
with them up front.
Well, given that this method is currently used
Chris Burdess wrote:
Besides, I don't see how you can validate an anyURI, since it can be
absolute or relative.
According to the XML namespaces spec
http://www.w3.org/TR/xml-names/#iri-use
http://www.w3.org/2000/09/xppa
you cannot use relative URIs in XML namespace references.
Chris Burdess wrote:
I'd like some feedback on a change I'd like to make to a small part
of the JAXP implementation.
[...]
Note that this is contentious, because Sun's QName *doesn't do any
validation* of its input. However, I still think it's the
right thing to do, and I'm not alone:
Hi,
I committed the attached patch to make it compile (and work) on
platforms where JNIEXPORT and JNICALL actually mean something.
Regards,
Jeroen
2006-10-17 Jeroen Frijters [EMAIL PROTECTED]
* native/jni/classpath/jcl.c
(JNI_OnLoad): Corrected calling convention.
Index
To: classpath-patches@gnu.org
Subject: [cp-patches] RFC: PR Classpath/28664 - GNU MP based
BigIntegertake2 (compressed)
hello all,
the attached proposed patch addresses the above and
incorporates Jeroen
Frijters pattern for native implementation using native memory.
the related ChangeLog
Tom Tromey wrote:
I'm not checking this in yet, I'd like some comments first.
Thanks. I like this change a lot, but I have one small comment. In the
documentation of Map.Entry.hashCode() it is sort of implied that a null
reference returns a 0 hash code. Both the RI and our current
implementation
Hi,
Committed. The spec says that implCloseChannel should cancel all keys
associated with the channel.
Regards,
Jeroen
2006-09-24 Jeroen Frijters [EMAIL PROTECTED]
* java/nio/channels/spi/AbstractSelectableChannel.java
(implCloseChannel): Cancel all keys after closing
Hi,
Committed. This fixes several bugs in ServerSocket.bind().
Regards,
Jeroen
2006-09-24 Jeroen Frijters [EMAIL PROTECTED]
* java/net/ServerSocket.java
(bind(SocketAddress,int)): Added support for null address.
Throw proper exception if already bound.
Handle
Hi,
Committed. This fixes the bug that when a key was already registered it
would not get the new interest ops and the attachment wouldn't be
cleared if the value value was null.
Regards,
Jeroen
2006-09-24 Jeroen Frijters [EMAIL PROTECTED]
* java/nio/channels/spi
Hi Casey,
I would like to remove the dependence on VMChannel from Socket and
ServerSocket (as this breaks the layering). Do you agree with this
patch?
Thanks,
Jeroen
Index: gnu/java/nio/SocketChannelImpl.java
===
RCS file:
Casey Marshall wrote:
Jeroen Frijters wrote:
Hi Casey,
I would like to remove the dependence on VMChannel from Socket and
ServerSocket (as this breaks the layering). Do you agree with this
patch?
I think this should be OK. Refresh my memory, though: in ServerSocket
and Socket
Hi,
I committed the previously discussed patch (minus the SocketChannelImpl
import that I accidentally removed).
Regards,
Jeroen
2006-09-19 Jeroen Frijters [EMAIL PROTECTED]
* gnu/java/nio/SocketChannelImpl.java: Removed unused import.
* java/net/ServerSocket.java
Hi,
Committed.
Regards,
Jeroen
2006-09-14 Jeroen Frijters [EMAIL PROTECTED]
PR classpath/28984
* java/io/InputStreamReader.java
(read(char[],int,int)): Fixed bug.
Index: java/io/InputStreamReader.java
Hi,
Committed. This fix isn't perfect, but it's better than the current
code.
Regards,
Jeroen
2006-09-14 Jeroen Frijters [EMAIL PROTECTED]
* gnu/java/rmi/server/ActivatableRef.java
(readExternal, writeExternal): Partial fix for serialization
format.
Index: gnu/java/rmi/server
Hi Audrius,
Can you please take a look at this patch?
The current ActivatableRef (de)serialization code is wrong (the format
is documented here [1]) and I fixed the common case, but I don't
understand what a null nested remote reference is.
Thanks,
Jeroen
[1]
Raif S. Naffah wrote;
i followed the advice given in [1] and synchronized the code
in the BigInteger finalize() method which now looks like so:
This is not yet sufficient. *All* native method calls that use the
native_ptr need to be synchronized.
It is also not very good practice to
Raif S. Naffah wrote:
On Monday 04 September 2006 20:40, Jeroen Frijters wrote:
...
...*All* native method calls that use the
native_ptr need to be synchronized.
i'm sorry but it is still not obvious to me why this should
be so. every instance of a BigInteger has its own value
Raif S. Naffah wrote:
the attached patch adds support for GNU MP in BigInteger
if/when configured.
How/why is the native version better? Is it really worthwhile to
complicate the code this way? Where are the benchmarks that prove the
native code is faster?
I assume it is already widely know
Raif S. Naffah wrote:
the attractiveness of the native code is performance. to
quickly see how the
new methods improve for example RSA key generation, one can
modify the code
in TestOfRSAKeyGeneration (Mauve) to call the generate()
method N times and
print the duration --on my
Hi,
Committed.
Regards,
Jeroen
2006-08-24 Jeroen Frijters [EMAIL PROTECTED]
* java/security/SecureClassLoader.java
(protectionDomainCache): Changed to HashMap.
(SecureClassLoader): Removed redundant security check.
(defineClass(String,byte[],int,int,CodeSource
Roman Kennke wrote:
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it
creates a
new instance of the system class loader), but apart from
that comparing
Roman Kennke wrote:
What about this pending patch?
I certainly would like to see it go.
Regards,
Jeroen
Jeroen Frijters [EMAIL PROTECTED]
* java/io/File.java (normalizePath): Fixed handling of // and
\\.
Index: java/io/File.java
===
RCS file: /cvsroot/classpath/classpath/java/io/File.java,v
retrieving revision 1.66
diff -u -r1.66
Jeroen Frijters wrote:
Archie Cobbs wrote:
Dumb question.. why wouldn't it work to just use a
WeakHashMap instead of a HashMap in all those places?
Not a dumb question at all. That *would* work. The problem
is that (at least on some runtimes) WeakHashMap is much more
expensive than
Casey Marshall wrote:
What I'd like people to look at and comment on specifically are the
changes to gnu.java.nio.VMChannel and gnu.java.net.VMPlainSocketImpl,
for opinions on how well these classes (the public methods) help
abstract away platform-specific code.
Thanks. I like the idea of the
Casey Marshall wrote:
- Instead of changing
FileInputStream/FileOutputStream/RandomAccessFile,
FileChannelImpl should accommodate them.
I'm not sure what you mean by this.
It just looked like unnecessary code duplication. If
FileChannelImpl.create throws the right exception, the others
Mark Wielaard wrote:
Could you add a little note about this to the NEWS and/or the
vmintegration guide? VMStackWalker.firstNonNullClassLoader() is a new
method that runtimes should implement (an optimized version of).
Ah, yes, thanks for reminding me.
Regards,
Jeroen
2006-08-21 Jeroen
Hi,
I committed my RMI class loading patch.
Regards,
Jeroen
2006-08-17 Jeroen Frijters [EMAIL PROTECTED]
* gnu/java/rmi/server/RMIClassLoaderImpl.java
(loadClass): Rewritten to use getClassLoader.
(loadProxyClass): Implemented.
(getClassLoader): Fixed support
= path.getParent();
Why do we have crap like this in cvs? There's really no excuse for code
this badly written.
Regards,
Jeroen
2006-08-17 Jeroen Frijters [EMAIL PROTECTED]
* javax/swing/filechooser/FileSystemView.java
(getFileSystemView): Always return UnixFileSystemView, since
Casey Marshall wrote:
Tom Tromey wrote:
It seems to me that this is an area we haven't handled very
well: this
isn't really a VM thing per se -- the code could very well be
written in pure java -- but rather a platform thing.
I agree that adding special cases in File just makes the
Hi Casey,
I just about exploded when I read the first part of your message ;-) But
at the end of your message I discovered that we completely misunderstood
each other and that we agree much more than we disagree.
With that in mind, here are my responses including to the parts that I
initially
Roman Kennke wrote:
Here comes a significant performance improvement for Zipfile, done by
Ingo. It avoids expensive UTF8 decoding when possible (most
cases, for ASCII) and optimizes readLeShort() and readLeInt() for the
case when the buffer has enough bytes. Mauve shows no regressions.
Roman Kennke wrote:
Friedjof hacked up the Object de-/serialization code for improved
performance. It is now an order of magnitude faster.
Thanks. Most of it looks good. A few comments:
This looks funny:
+ {System.err.println(1);
I think this is bad style:
+catch
Hi Roman,
The attached patch file is empty.
Regards,
Jeroen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roman Kennke
Sent: Tuesday, August 15, 2006 17:31
To: Roman Kennke
Cc: classpath-patches@gnu.org
Subject: Re: [cp-patches] RFC:
Roman Kennke wrote:
This test is wrong:
+ || (l.getClass().getClassLoader() == null /*
application loader
*/);
If an application instantiates URLClassLoader, it should still be
garbage collectable.
I think that he should consider using a cache that uses
weak references
Roman Kennke wrote:
Jeroen Frijters schrieb:
Hi Roman,
The attached patch file is empty.
Ugh. My bad. Here it is.
Thanks. Looks like a good change to me.
Regards,
Jeroen
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it creates a
new instance of the system class loader), but apart from that comparing
against the system class loader would work, but I'd much
Audrius Meskauskas wrote:
In the case when the thread is created and started inside the
bootstrap classes, it may be no any user class on the stack.
Without using thread context class loader, it may not be possible
to locate any class of the user application that is currently
running (the
Hi,
I did some RMI debugging and I found that we're using the wrong class
loader in a couple of cases. The attached patch cleans up the code a
little and uses the caller's class loader instead of the thread's
context class loader in a couple of places.
I would appreciate it if someone with more
unused, so I did not change it's behavior unintentionally.
Regards,
Jeroen
2006-08-11 Jeroen Frijters [EMAIL PROTECTED]
* java/io/ObjectInputStream.java (readClassDescriptor):
Use class's class loader to resolve field types.
* java/io/ObjectStreamField.java
Tom Tromey wrote:
Casey - Adds a NativeFD interface to all our Channel
implementations that
Casey returns the native file descriptor integer. The plan
here would be that
Casey a Selector implementation could work generically given
that you register
Casey a Channel that implements
Casey Marshall wrote:
On reflection, it actually seems like a better idea to
augment VMChannel
for this purpose (and refactor VMPlainSocketImpl) instead. Right now
VMChannel takes a Channel object, and extracts the native file
descriptor integer, and uses it internally. Instead, each
Lillian Angel wrote:
On Sat, 2006-08-05 at 11:28 +0200, Jeroen Frijters wrote:
Hi,
I commented out the GTK specific code in java/awt/Component.java.
Component cannot have dependencies on any specific type of peer.
Lillian could you please find a generic way to do what is required
Jeroen Frijters wrote:
Lillian Angel wrote:
On Sat, 2006-08-05 at 11:28 +0200, Jeroen Frijters wrote:
Hi,
I commented out the GTK specific code in java/awt/Component.java.
Component cannot have dependencies on any specific type of peer.
Lillian could you please find
Hi,
I commented out the GTK specific code in java/awt/Component.java.
Component cannot have dependencies on any specific type of peer.
Lillian could you please find a generic way to do what is required?
Regards,
Jeroen
2006-08-05 Jeroen Frijters [EMAIL PROTECTED]
* java/awt
Mario Torre wrote:
This patch makes the gconf backend the default.
The configure part of the patch is the same as the one
discussed early, but now the backend name is stored under
META-INF and loaded at runtime using ServiceFactory.
A new file is introduced in the META-INF directory that
Mario Torre wrote:
Ops, this had to be System.get(...)
Rereading the code, this (few lines later) makes more sense:
String className =
System.getProperty(java.util.prefs.PreferencesFactory,
+
Configuration.DEFAULT_PREFS_PEER);
OK. I see what you mean now.
I would expect that to be
Hi,
I added a helper method to ThreadGroup that the VM can use to
(relativelyly) efficiently resolve a thread id into a Thread object.
Regards,
Jeroen
2006-07-01 Jeroen Frijters [EMAIL PROTECTED]
* java/lang/ThreadGroup.java
(getThreadFromId, getThreadFromIdImpl): New methods
Andrew John Hughes wrote:
This patch puts a bit more into thread state handling.
I apologize for being blunt, but this patch is unacceptable. It doesn't
cover all cases, it's incorrect and inefficient.
I really think it's best to leave determining the thread state up to
VMThread, except of
Andrew John Hughes wrote:
Based on your comments, it seems you agree with my original intuition
of making this a native VM call (by default) in the majority of
cases, but efficiency would seem to be fairly VM specific.
Sure, but Thread.getState() is unlikely to be used very often and should
Hi,
Now that builder is using a new version of ecj, the generics branch no
longer compiled due to a cast bug. I checked in a fix.
Regards,
Jeroen
2006-06-21 Jeroen Frijters [EMAIL PROTECTED]
* java/util/Collections (entrySet): Fixed compile error.
Index: java/util/Collections.java
Hi,
I committed the file as in the previous RFC.
Regards,
Jeroen
2006-06-09 Jeroen Frijters [EMAIL PROTECTED]
* sun/reflect/annotation/AnnotationInvocationHandler.java:
New file.
Hi,
While trying to get True Type font rendering to work I ran into a
missing instruction. Fortunately it was a trivial one, so I implemented
it.
Regards,
Jeroen
2006-06-09 Jeroen Frijters [EMAIL PROTECTED]
* gnu/java/awt/font/opentype/truetype/VirtualMachine.java
Tom Tromey wrote:
Jeroen Tom Tromey wrote:
* A sanitize-jsr166 script which is run on a pristine download in
order to remove copyrighted code and to change sun.* references to
the appropriate gnu.* references.
Jeroen Is there a (legal?) reason why we can't keep the
sun.* references?
Hi,
As promised here is my cleaned up version of
AnnotationInvocationHandler. I intend to check this into the trunk.
Regards,
Jeroen
AnnotationInvocationHandler.java
Description: AnnotationInvocationHandler.java
Michael Koch wrote:
On Thu, Jun 08, 2006 at 11:05:53AM +0200, Jeroen Frijters wrote:
Hi,
As promised here is my cleaned up version of
AnnotationInvocationHandler. I intend to check this into the trunk.
Thanks.
Please use a Unix file encoding when checking it in (line endings).
I'm
Tom Tromey wrote:
(It is kind of lame to have INIT_LOAD_LIBRARY
floating around just for libgcj... but I suppose it isn't a very big
maintenance burden. Or does IKVM use it too?)
IKVM doesn't use it, because it replaces all VM classes that have native
methods. As a long term goal, I'd still
Tom Tromey wrote:
* A sanitize-jsr166 script which is run on a pristine download in
order to remove copyrighted code and to change sun.* references to
the appropriate gnu.* references.
Is there a (legal?) reason why we can't keep the sun.* references?
Regards,
Jeroen
Hi,
Since nobody complained about my context class loader fix, I'm checking
it in. I also made the generation of anonymous thread names thread safe
and corrected the security check in getContextClassLoader.
Regards,
Jeroen
2006-05-19 Jeroen Frijters [EMAIL PROTECTED]
* java/lang
Jeroen Frijters [EMAIL PROTECTED]
* gnu/java/net/loader/JarURLLoader.java
(JarURLLoader): Use a slightly more efficient URL constructor.
Index: gnu/java/net/loader/JarURLLoader.java
===
RCS file: /cvsroot/classpath
Thread.currentThread().
I can also fix this in IKVM specific code, but that would be uglier and
I believe that other VMs will also benefit from this change (at the
small cost of an extra boolean in each Thread instance).
Any comments?
Regards,
Jeroen
2006-05-17 Jeroen Frijters [EMAIL PROTECTED
Archie Cobbs wrote:
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
Tom Tromey wrote:
I'm posting this for comments.
In libgcj we have a divergence in URLClassLoader, because we have
other ways to load classes. In particular we can extract classes
from shared libraries via 'gcjlib' URLs, and URLClassLoader knows
about this.
I'd like to re-merge here so
Hi Chris,
I know nothing about the XML APIs, so I hope this isn't a dumb question
but I just debugged some code from a user of IKVM and it did the
following:
SAXTransformerFactory factory =
(SAXTransformerFactory)TransformerFactory.newInstance();
On the JDK this works. Now obviously the
Hi,
As reported by Edwin Steiner, StringBuilder used System.arraycopy
instead of VMSystem.arraycopy and that causes bootstrap issues. I
committed the attached patch to fix this.
Regards,
Jeroen
2006-04-28 Jeroen Frijters [EMAIL PROTECTED]
* java/lang/StringBuilder.java
[EMAIL PROTECTED] wrote:
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark It would be a good point to declare the vm classes interface
Mark frozen for now and work towards a new snapshot release that
Mark includes them.
Actually I would like to make one more change before 0.91. This
. If you're a VM maintainer and you use a custom version of
VMClassLoader, this is a breaking change and your version of
VMClassLoader will have to be updated as well.
I will shortly merge these changes with the trunk.
Regards,
Jeroen
2006-04-21 Jeroen Frijters [EMAIL PROTECTED]
* java/lang
(simply add an extra null
parameter to the Package constructor).
Regards,
Jeroen
2006-04-23 Jeroen Frijters [EMAIL PROTECTED]
* java/lang/ClassLoader.java (definePackage): Added argument to
Package constructor.
* java/lang/Package.java (Package): Added ClassLoader argument
1 - 100 of 232 matches
Mail list logo
