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
--- In
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;
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
Inde
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 Infl
Hi,
It's been a while, so I hope I remember the protocols :-)
2010-01-11 Jeroen Frijters
* java/util/zip/Inflater. java (inflate(byte[],int,int)): Fix for
#41696.
Besides the fix for the bug mentioned, this also fixes the checksum check,
which previously wouldn't occur
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 nee
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 (java::la
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 Obje
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: Raste
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/jav
ocale. I'm a
bit surprised that this hasn't been caught earlier though, so I'm wondering if
there is something I'm missing.
Anyway, attached is a patch that fixes this. If nobody objects I will commit
this.
Regards,
Jeroen
2007-11-08 Jeroen Frijters <[EMAIL PROT
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 ;-)
&g
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, noti
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:
> 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 l
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 b
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 Thread[arra
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:
> 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 performa
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: /c
ed on OpenJDK.
Regards,
Jeroen
2007-06-21 Jeroen Frijters <[EMAIL PROTECTED]>
* java/net/URLClassLoader.java
(URLClassLoader(URL[],ClassLoader,URLStreamHandlerFactory):
Add factory to cache before calling addURLS.
(run): Don't call initCause() on ClassN
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: jav
Hi,
I committed the patches below to fix some compilation errors when mixing this
code with OpenJDK code.
Regards,
Jeroen
2007-06-21 Jeroen Frijters <[EMAIL PROTECTED]>
* gnu/java/net/loader/URLLoader.java
(URLLoader(URLClassLoader,URLStreamHandle
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 &l
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: /c
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
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: Array
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: CopyOnWriteArrayLis
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/Socke
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()
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
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
=
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
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.
Inde
Casey Marshall wrote:
> Also, in JCL_malloc and JCL_realloc we throw OutOfMemoryExceptions if
> the native calls return NULL. It doesn't seem like this will work
> (though, if there is an explanation of why it will always work, I'll
> listen), so I've also modified this to allocate a static
> OutOf
the exception (this is specified in the spec, but
the exception type isn't, so we may still be incompatible there.)
Regards,
Jeroen
2006-12-28 Jeroen Frijters <[EMAIL PROTECTED]>
* javax/net/ssl/SSLServerSocketFactory.java:
(getDefault): Return inoperative factory
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
David Daney wrote:
> Jeroen Frijters wrote:
> > David Daney wrote:
> >
> >> Jeroen Frijters wrote:
> >>
> >>> throw new RuntimeException("error
> instantiating default
> >>> socket facto
David Daney wrote:
> Jeroen Frijters wrote:
> > throw new RuntimeException("error instantiating default
> > socket factory: "
> > - + ex.toString());
> >
> That sounds more like an InternalError th
Hi,
Committed.
Regards,
Jeroen
2006-12-11 Jeroen Frijters <[EMAIL PROTECTED]>
* javax/net/ssl/SSLSocketFactory.java (getDefault):
Chain exception cause.
Index: javax/net/ssl/SSLSocketFactory.java
===
RC
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 refe
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.
y, October 08, 2006 11:34
> 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
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. 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/c
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
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 closi
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/ServerSocke
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 O
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: /cvsroot/c
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.
Ind
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/InputStreamReade
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]
http://java.sun.com/j2se/1.5.0/do
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 i
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 synchron
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
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
ReferenceQueue lock will be taken by the GC when it enqueues
a Reference).
Regards,
Jeroen
2006-08-24 Jeroen Frijters <[EMAIL PROTECTED]>
* java/lang/ref/Reference.java
(queue, nextOnQueue): Made volatile.
(enqueue): Made thread safe.
* java/la
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[],i
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
Archie Cobbs wrote:
> 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
> &
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
retrie
Hi,
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 f
Roman Kennke wrote:
> What about this pending patch?
I certainly would like to see it go.
Regards,
Jeroen
Roman Kennke wrote:
> Jeroen Frijters schrieb:
> > Roman Kennke wrote:
> >> What about
> >>
> >> || (l == VMClassLoader.getSystemClassLoader())
> >>
> >> instead ?
> >
> > You shouldn't call VMClassLoader.getSystemClassLoad
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-2
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 ot
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
parentPath = 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 Unix
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):
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 fou
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 jus
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
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:
> > 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
>
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: Fi
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 (Ill
Roman Kennke wrote:
> - Creates a local copy of the channels field in
> FileDescriptor.valid() to improve threading safety.
Why is this necessary? channel is final so it can never become null
after it has been checked.
Regards,
Jeroen
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.
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 (t
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 R
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/Object
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
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 y
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
>
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 implem
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]>
* ja
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 director
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
Mario Torre wrote:
> This patch makes gconf the default backend.
>
> The patch works adding a new configure option that let the user to
> specify a default implementation (like FileBased or GConfBased ones).
>
> If the user does not provides this option, than the preference backend
> is FileBased
Andrew John Hughes wrote:
> No problem; the new name makes things a bit clearer too. Really,
> though, according to the specification, the ids should be reused after
> the thread terminates (which both Tom's original solution and
> this patch don't handle). I don't know how necessary this is tho
checked in my slightly more efficient fix.
This way Thread doesn't need to have a static initializer method.
Regards,
Jeroen
2006-07-01 Jeroen Frijters <[EMAIL PROTECTED]>
* java/lang/Thread.java:
Make thread IDs start from 1 in a more efficient way.
Ind
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
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 shoul
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 cour
Andrew John Hughes wrote:
> The attached patch adds the two missing stack trace methods to
> Thread. Currently, they are untested, as nothing yet implements
> the new VM method for thread stacktraces.
Thanks! It doesn't yet work, as ManagementFactory.getThreadMXBean() is
currently still unimpleme
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/Collection
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/VirtualMachin
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.
1 - 100 of 299 matches
Mail list logo
