gnu.java.awt.font

Hi all, I've put a new snapshot of a prospective gnu.java.awt.font package at the following address: http://www.dandelis.ch/development/fonts/#Implementation There also now is an interactive test program, and the page has some screen shots which show that the quality is surprisingly good with

bug fix for java.io.InputReaderStream.close andjava.util.zip.InflaterInputStream.close

Appended is a patch to avoid a NullPointerException if close is called multiple times. This matches the logic that is already in java.io.BufferedReader. Could someone please apply it? Since preparations for classpath 0.06 are underway, I'm increasing the scope of the nightly regression tests we

Avoiding locks

Hi all, vaguely related to the current thread about Thread/VMThread proposal on the Classpath discussion list, I would like to ask whether the following pattern is correct with respect to the Java memory model. I believe so, but I would like to be sure. // foo is initially null; only set by

Re: Avoiding locks

On Tue, 29 Jul 2003, Sascha Brawer wrote: vaguely related to the current thread about Thread/VMThread proposal on the Classpath discussion list, I would like to ask whether the following pattern is correct with respect to the Java memory model. I believe so, but I would like to be sure. This

Re: Avoiding locks

Jeff Sturm [EMAIL PROTECTED] wrote on Tue, 29 Jul 2003 14:10:11 -0400: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Thanks for the great reference. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/

BoF: Graphics in GNU Classpath

Hi all, during our meeting in Karlsruhe, some of you said that they will come to LinuxKongress, which will take place from October 14-16 in Saarbrücken/ Germany. In previous years, there apparently was an opportunity for so-called Birds-of-a-Feather (BoF) Sessions. In my understanding, this is

RE: Avoiding locks

As I understand it, if the proposal in JSR 133 is adopted, it will be sufficient to declare the result field volatile for conforming VMs. No the result field is just a local variable - declaring it volatile won't do anything. Sascha's code correctly defined foo as volatile. There is actually

RE: Thread/VMThread proposal

You may wish to check that a stillborn thread has a null thread group after stop() has been called. I did confirm already that threads that run and are stopped are seen to have a null thread group. A thread is removed from its threadgroup only when the thread terminates. If stop() is invoked

Re: Thread/VMThread proposal

David Holmes [EMAIL PROTECTED] writes: You may wish to check that a stillborn thread has a null thread group after stop() has been called. I did confirm already that threads that run and are stopped are seen to have a null thread group. A thread is removed from its threadgroup only