- core-libs-dev - openjdk.org

Races between close() and other operations on file channels
by Florian Weimer 06 Aug '07

06 Aug '07

What mechanisms prevent reuse of a file descriptor between the time it is extracted from a FileDescriptor object and the actual UNIX system call? If there is any locking, it's not very apparent from the source code.

2 2

[PATCH] typos in sun/rmi/rmic/RemoteClass
by Christian Thalinger 05 Aug '07

05 Aug '07

Hi! This small patch fixes some typos: Index: j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java =================================================================== --- j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java (revision 246) +++ j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java (working copy) @@ -611,10 +611,10 @@ public class RemoteClass implements sun. } } catch (IOException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } catch (NoSuchAlgorithmException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } return hash; @@ -864,10 +864,10 @@ public class RemoteClass implements sun. } } catch (IOException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } catch (NoSuchAlgorithmException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } return hash; I've not signed the SCA yet, but the patch is really small and trivial. I'll send the SCA on monday anyways. - twisti

1 0

[DISCUSSION] Views of immutable objects.
by Paulo Levi 31 Jul '07

31 Jul '07

I'd like to ask if it would be possible to modify the classes of some primitive immutable types for returning immutable read only views. For example for strings, when using the document hierarchy, any insertString in the GapContent object invokes str.toCharArray(), that is implemented like this: public char[] toCharArray() { char result[] = new char[count]; getChars(0, count, result, 0); return result; } I'd like if the new didn't exist. Any attempt to use instead the getChars function + class char[] is even worse, since the local char [] becomes a memory leak. I think that if the char [] intrinsic classes had a immutable view where modifying the object was a nop it would eliminate this allocation and keep string immutable. Something like: public char[] toImmutableCharArray() { ichar result[] = new ichar[count]; getChars(0, count, result, 0); return result; } Preventively I'm going to say I'm not only worried about memory (that might or might not be later "fixed" by escape analisys stack allocation) but also about efficiency.

3 6

[DISCUSSION] LinkedHashMap iteration order.
by Paulo Levi 28 Jul '07

28 Jul '07

The LinkedHashMap seems like a nice class for implementing a LRU map, and it is. However when you try to use it to actually access the most recently used <key, value> with the appropriate constructor, its easy to see that the order of iteration is from the least recently used to the most recently used. To access the most recent item you must either iterate over n keys or toArray() (even worse). Is there another easy solution in java 1.5 (in the collections framework)?

1 1

6410729 Add BitSet.previousClearBit, previousSetBit
by Peter B. West 18 Jul '07

18 Jul '07

I had previously posted about this on the jdk-collaboration list without getting any responses. Attached is an implementation of BitSet.java which includes the previousClearBit and previousSetBit methods. It is in the form of a NetBeans project, including JUnit tests. The project is specified in a non-java package for testing. All up, there are 73 additional lines of code and docs in BitSet.java. No big deal. Also attached is a udiff against JDK build 15 of 5th July. I have been, on and off, roaming in the wilderness of JDK builds and jtreg testing since I first submitted the code on the 6th of May, without making much progress, and without getting any response. As far as I can tell, I have followed the recommended path for a submission. Obviously, there are flaws in either the documentation or the implementation. I have tried using the NetBeans build facilities to build and test a project consisting only of BitSet.java. While I can build it, I don't know how to run jtreg against it. I suspect I must have a full JDK build, which I have not been able to achieve on my SuSE 10.2 box. Note that I haven't actually written a jtreg test yet. I'll do that when I've been able to get one to run in the current environment. Anyway, what I'm after is some (hopefully simple) set of steps I can follow to get this trivial piece of code either accepted or rejected for, what, Java 8? Java 9? -- Peter B. West <http://cv.pbw.id.au/> Folio <http://defoe.sourceforge.net/folio/>

2 2

build j2se project in netbeans 5.5.1
by zhang Jackie 14 Jul '07

14 Jul '07

hi,everyone I hava downloaded the latest version openjdk, follow the instruction of http://nb-openjdk.netbeans.org/get-and-build.html. (1)But all project name is ???, even if it became ??? again after I changed it. (1) when I build the j2se project , warnings such as follows always exists. *Warning: falling back to building against /usr/local/jdk1.6.0 Please define bootstrap.jdk=.../recent/jdk7/snapshot in /home/jackie/.openjdk/build.properties or /home/jackie/netbeansWorkSpace/openjdk/j2se/make/netbeans/j2se_J/nbproject/private/build.properties Entering directory `/home/jackie/netbeansWorkSpace/openjdk/j2se/make'* (3) when build j2se, Bootstrap Settings are as follows: *Bootstrap Settings: BOOTDIR = /NO_BOOTDIR ALT_BOOTDIR = BOOT_VER = /bin/sh: /NO_BOOTDIR/bin/java: No such file or directory [requires at least 1.5] OUTPUTDIR = ./../build/linux-i586 ALT_OUTPUTDIR = ABS_OUTPUTDIR = /home/jackie/netbeansWorkSpace/openjdk/j2se/build/linux-i586* how can I change *BOOTDIR ?* ** ** Do someone can fix my problems? thanks.

4 3

Patch to fix BufferedInputStream.skip and bug 4254082
by Bill Pugh 12 Jul '07

12 Jul '07

I'd like to submit a patch to fix BufferedInputStream.skip. This will fix the bad behavior described in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4254082 although it doesn't fix the spec problem for InputStream.skip. As described in our Java Puzzlers talk at JavaOne, BufferedInputStream.skip has a particularly unexpected behavior: if skipping a sequence of bytes requires both skipping some buffered bytes and some bytes in the underlying input stream, it will only skip the buffered bytes, returning a value that indicates that the method call only skipped those bytes. Unfortunately, that return value is usually ignored, including most of the times skip is invoked in Sun's code base. I propose the following: * Rename the existing skip method to be a private method named skip1. * Define a new public synchronized skip method that uses a loop to invoke skip1 until either all the requested bytes are skipped, or skip1 returns 0, and returns the total of all the calls to skip1. I could factor out some of the simple cases into the new skip method, but I'm not sure that would buy any performance improvements except for microbenchmarks, and it would avoid duplicating any logic. Sound good? Let me know and if this sounds acceptable I'll submit the patch. Bill

5 8

[PATH] bug 4254082 & 4479751 draft
by Pascal S. de Kloe 12 Jul '07

12 Jul '07

The patch seems to solve both bugs while doing the right thing. It hasn't been tested well though and the last thing I want is new bugs. Does anybody have or know a application which utilises the BufferedInputReader with marks? If it works I'll finish it. The read(byte[]) method doesn't work correct anymore now that read(byte[],int,int) has been fixed.

2 6

Re: [PATH] bug 4254082 & 4479751 & 6192696 draft 2
by Pascal S. de Kloe 08 Jul '07

08 Jul '07

On Sunday 08 July 2007 19:45:05 you wrote: > Speed of patch generation is not a priority when changing the > behavior of a core Java library. > > Frankly, the quality of your patches convinces me that you shouldn't > be submitting patches to > the core Java libraries. The reason why I post those early drafts is to get feedback before the polishing. Maybe some experienced developer can tell if I'm on the right track or not until one day I can see it myself. > Among other problems, your most recent patch changed the behavior > when skip is called on a closed BufferedInputStream. Rather than > throwing IOException, you changed the behavior so that it now throws > a NullPointerException. That's exactly the kind of feedback we need. :) Note the first line of skip "verifyNotClose();". That method throws a IOException if the stream was closed, i.e., if close() was called. > I discourage you from submitting more patches. Your eagerness exceeds > your proficiency. I'm not convinced that I'm that bad yet...

1 0

Closeable and Socket, ZipFile
by Andreas Sterbenz 06 Jul '07

06 Jul '07

Hi, elsewhere it came up that the java.io.Closeable interface is implemented by InputStream, OutputStream, Reader, Writer, SocketChannel, etc. but not by classes such as Socket, ServerSocket, ZipFile, etc. Is that intentional or a bug? Andreas.

3 3