From pascal at quies.net Tue Jul 3 00:16:11 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 3 Jul 2007 02:16:11 +0200 Subject: [PATCH] BigInteger - minor performance & cleanup Message-ID: <200707030216.17557.pascal@quies.net> The patch introduces arraycopy and a little cleanup in BigInteger#add(int[], int[]). I started reading the source today with BigInteger and this was the first thing I noticed. Would you be interested in more of these very small patches? Cheers, Pascal -------------- next part -------------- A non-text attachment was scrubbed... Name: BigInteger.patch Type: text/x-diff Size: 1818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Tue Jul 3 00:21:11 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 3 Jul 2007 02:21:11 +0200 Subject: [PATCH] BigInteger - minor performance & cleanup In-Reply-To: <200707030216.17557.pascal@quies.net> References: <200707030216.17557.pascal@quies.net> Message-ID: <200707030221.12428.pascal@quies.net> On Tuesday 03 July 2007 02:16:11 Pascal S. de Kloe wrote: > The patch introduces arraycopy and a little cleanup in > BigInteger#add(int[], int[]). > > I started reading the source today with BigInteger and this was the > first thing I noticed. Would you be interested in more of these very > small patches? > > Cheers, > > Pascal Sorry, wrong attachment. It's getting late. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: BigInteger.patch Type: text/x-diff Size: 1823 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Tue Jul 3 01:16:05 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 3 Jul 2007 03:16:05 +0200 Subject: [PATCH] BigInteger - minor performance & cleanup In-Reply-To: <200707030221.12428.pascal@quies.net> References: <200707030216.17557.pascal@quies.net> <200707030221.12428.pascal@quies.net> Message-ID: <200707030316.10500.pascal@quies.net> On Tuesday 03 July 2007 02:21:11 Pascal S. de Kloe wrote: > On Tuesday 03 July 2007 02:16:11 Pascal S. de Kloe wrote: > > The patch introduces arraycopy and a little cleanup in > > BigInteger#add(int[], int[]). > > > > I started reading the source today with BigInteger and this was the > > first thing I noticed. Would you be interested in more of these > > very small patches? > > > > Cheers, > > > > Pascal > > Sorry, wrong attachment. It's getting late. ;) Once more. -------------- next part -------------- A non-text attachment was scrubbed... Name: BigInteger.patch Type: text/x-diff Size: 1823 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Wed Jul 4 13:26:17 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 4 Jul 2007 15:26:17 +0200 Subject: [PATCH] BigInteger - minor performance & cleanup In-Reply-To: <200707030316.10500.pascal@quies.net> References: <200707030216.17557.pascal@quies.net> <200707030221.12428.pascal@quies.net> <200707030316.10500.pascal@quies.net> Message-ID: <200707041526.24384.pascal@quies.net> I couldn't sleep last night so I decided to read the Java source. Sending a patch that very evening was a *bad* idea. Sorry about that. The arraycopy method did not improve things at all. However, the minor changes actually do work. The attachments original.log and patched.log each contain 5 results of Benchmark.java. OpenJDK Runtime Environment (build 1.7.0-internal-pascal_03_jul_2007_21_30-b00) Java flags: "-server -Xnoclassgc" Happy ending after all? -------------- next part -------------- A non-text attachment was scrubbed... Name: BigInteger.patch Type: text/x-diff Size: 1336 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: original.log Type: text/x-log Size: 600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patched.log Type: text/x-log Size: 600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Benchmark.java Type: text/x-java Size: 1600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pugh at cs.umd.edu Thu Jul 5 16:25:53 2007 From: pugh at cs.umd.edu (Bill Pugh) Date: Thu, 5 Jul 2007 09:25:53 -0700 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 Message-ID: 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 From Andreas.Sterbenz at Sun.COM Fri Jul 6 00:02:21 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 05 Jul 2007 17:02:21 -0700 Subject: Closeable and Socket, ZipFile Message-ID: <468D868D.7020202@sun.com> 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. From pascal at quies.net Fri Jul 6 13:13:58 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 6 Jul 2007 15:13:58 +0200 Subject: Closeable and Socket, ZipFile In-Reply-To: <468D868D.7020202@sun.com> References: <468D868D.7020202@sun.com> Message-ID: <200707061514.04373.pascal@quies.net> On Friday 06 July 2007 02:02:21 Andreas Sterbenz wrote: > 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. A bug means that the software does not work as intended. Socket, ServerSocket and ZipFile all have a close() method which closes the respective streams so what's the problem? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From Andreas.Sterbenz at Sun.COM Fri Jul 6 17:10:41 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Fri, 06 Jul 2007 10:10:41 -0700 Subject: Closeable and Socket, ZipFile In-Reply-To: <200707061514.04373.pascal@quies.net> References: <468D868D.7020202@sun.com> <200707061514.04373.pascal@quies.net> Message-ID: <468E7791.8030200@sun.com> Pascal S. de Kloe wrote: > > Socket, ServerSocket and ZipFile all have a close() method which closes > the respective streams so what's the problem? As I said, those classes do not implement the java.io.Closeable interfance. Andreas. From iag at ribbit.SFBay.Sun.COM Fri Jul 6 19:00:59 2007 From: iag at ribbit.SFBay.Sun.COM (Iris Garcia) Date: Fri, 6 Jul 2007 12:00:59 -0700 (PDT) Subject: Closeable and Socket, ZipFile In-Reply-To: <468E7791.8030200@sun.com> (message from Andreas Sterbenz on Fri, 06 Jul 2007 10:10:41 -0700) Message-ID: <200707061900.l66J0xp2005858@ribbit.SFBay.Sun.COM> Hi. > Pascal S. de Kloe wrote: > > > > Socket, ServerSocket and ZipFile all have a close() method which closes > > the respective streams so what's the problem? > > As I said, those classes do not implement the java.io.Closeable interfance. java.io.Closeable was added semi-late into jdk5.0 to support java.util.Formatter. In that same release it also became useful for java.util.Scanner. At that time there was need (and to a certain extent time) for us to identify those classes which closely interacted with one of those two features (primarily classes in java.io java.nio, and java.nio.channels), so that's all that we took care of. Assuming they follow the specification, it would be perfectly reasonable for any class to declare that they implement Closeable. Here's the status for the specific classes mentioned: java.net.Socket: 6499348: java.net socket classes should implement java.io.Closeable - fixed in jdk7, b06 java.nio.SocketChannel: 4926319: java.util.Scanner needs a close method - fixed in jdk5.0-beta (b26) java.util.zip.ZipFile: 6389768: ZipFile should implement java.io.Closeable - currently unresolved RFE Thanks, iris From Martin.Buchholz at Sun.COM Sun Jul 8 03:07:18 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Sat, 07 Jul 2007 20:07:18 -0700 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: References: Message-ID: <469054E6.6060706@sun.com> Bug 4254082: java.io.BufferedInputStream.skip has unexpected results was closed Will Not Fix back in 2002. Offhand, I can't think of any reason not to fix this as Bill suggests, but I'm pretty sure that there is some history with this bug, and I don't know what it is. Perhaps madbot remembers? Of course, the proposed change is an incompatible change, but then every bug fix is an incompatible change. Hmmmm...... wait.... let's search bug database... Some people were complaining about the opposite problem, namely that the Buffered stream tries to read too far on the underlying stream. 6192696: BufferedInputStream.read(byte[], int, int) can block if the entire buffer can't be filled http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 4850305: BufferedReader.skip(long) blocks when it could return some data http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4850305 Chris, could you comment? Martin Bill Pugh wrote: > 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 > From pugh at cs.umd.edu Sun Jul 8 06:08:26 2007 From: pugh at cs.umd.edu (Bill Pugh) Date: Sat, 7 Jul 2007 23:08:26 -0700 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <469054E6.6060706@sun.com> References: <469054E6.6060706@sun.com> Message-ID: <1F65F54B-33C0-4FA3-B083-20456AAF4ADA@cs.umd.edu> Looking through the JDK 1.7.0-b13 code base, at uses of skip and skipBytes, the return value of skip and skipBytes is almost universally ignored. The main exception is when implementing a decorator for an inputstream and implmenting skip or skipBytes, in which case the value returned depends on the value returned by the call to the skip method of the decorated stream. There are three other places where the value of skip is used. In two of them, the code will go into a CPU hungry infinite loop if an unexpected EOF occurs: com.sun.java.util.jar.pack.ClassReader, line 85 sun.net.www.http.KeepAliveStream, line 94 The _only_ place where I've seen skip invoked correctly, other than in an implementation of skip, is in sun.net.www.http.KeepAliveStreamCleaner, line 115 Thus, I think there is a strong argument for making skip methods try to skip all of the requested bytes, even at the cost of blocking. With a partial read, there is often something useful you can do with a partial read. There isn't much of anything useful you can do with a partial skip. Bill On Jul 7, 2007, at 8:07 PM, Martin Buchholz wrote: > Bug > 4254082: java.io.BufferedInputStream.skip has unexpected results > was closed Will Not Fix back in 2002. > > Offhand, I can't think of any reason not to fix this as Bill suggests, > but I'm pretty sure that there is some history with this bug, > and I don't know what it is. Perhaps madbot remembers? > > Of course, the proposed change is an incompatible change, > but then every bug fix is an incompatible change. > > Hmmmm...... wait.... let's search bug database... > > Some people were complaining about the opposite problem, > namely that the Buffered stream tries to read too far on the > underlying > stream. > > 6192696: BufferedInputStream.read(byte[], int, int) can block if the > entire buffer can't be filled > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 > > 4850305: BufferedReader.skip(long) blocks when it could return some > data > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4850305 > > Chris, could you comment? > > Martin > > Bill Pugh wrote: >> 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 >> From pascal at quies.net Sun Jul 8 12:00:18 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 14:00:18 +0200 Subject: [PATH] bug 4254082 & 4479751 draft Message-ID: <200707081400.25957.pascal@quies.net> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferedInputStream.patch Type: text/x-diff Size: 11331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Sun Jul 8 12:41:53 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 14:41:53 +0200 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <469054E6.6060706@sun.com> References: <469054E6.6060706@sun.com> Message-ID: <200707081441.59779.pascal@quies.net> Hello Martin, > 6192696: BufferedInputStream.read(byte[], int, int) can block if the > entire buffer can't be filled > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 The problem is fill(). It doesn't check available(). The patch on this mailing list is supposed to fix that too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Sun Jul 8 12:59:41 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 14:59:41 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 draft 2 In-Reply-To: <200707081400.25957.pascal@quies.net> References: <200707081400.25957.pascal@quies.net> Message-ID: <200707081459.46537.pascal@quies.net> On Sunday 08 July 2007 14:00:18 Pascal S. de Kloe wrote: > 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. Fixed a little mistake. Fixes 6192696 now too. -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferedInputStream.patch Type: text/x-diff Size: 11360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pugh at cs.umd.edu Sun Jul 8 14:19:57 2007 From: pugh at cs.umd.edu (Bill Pugh) Date: Sun, 8 Jul 2007 07:19:57 -0700 Subject: [PATH] bug 4254082 & 4479751 & 6192696 draft 2 In-Reply-To: <200707081459.46537.pascal@quies.net> References: <200707081400.25957.pascal@quies.net> <200707081459.46537.pascal@quies.net> Message-ID: <13CCA62A-C7F7-4CFF-9121-BDFBFD8DDE07@cs.umd.edu> Please hold off on this. This patch doesn't solve the fundamental problem I've raised, and submitting a patch before we've finished discussing the desired behavior is premature. Bill P.S. One problem with the patch is that skip can still return a short skip in situations other than being at end of file. On Jul 8, 2007, at 5:59 AM, Pascal S. de Kloe wrote: > On Sunday 08 July 2007 14:00:18 Pascal S. de Kloe wrote: >> 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. > > Fixed a little mistake. Fixes 6192696 now > too. From pascal at quies.net Sun Jul 8 14:31:36 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 16:31:36 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 draft 2 In-Reply-To: <13CCA62A-C7F7-4CFF-9121-BDFBFD8DDE07@cs.umd.edu> References: <200707081400.25957.pascal@quies.net> <200707081459.46537.pascal@quies.net> <13CCA62A-C7F7-4CFF-9121-BDFBFD8DDE07@cs.umd.edu> Message-ID: <200707081631.36708.pascal@quies.net> On Sunday 08 July 2007 16:19:57 you wrote: > Please hold off on this. This patch doesn't solve the fundamental > problem I've raised, and submitting a patch before we've finished > discussing the desired behavior is premature. I wanted to discuss it with you but you didn't respond anymore. > P.S. One problem with the patch is that skip can still return a short > skip in situations other than being at end of file. That is up to the implementation of the protected InputStream #in but the BufferedInputStream does all it can, right? A final patch is coming within an hour and then I'll shut up, OK? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Sun Jul 8 15:56:32 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 17:56:32 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 draft 2 In-Reply-To: <200707081631.36708.pascal@quies.net> References: <200707081400.25957.pascal@quies.net> <13CCA62A-C7F7-4CFF-9121-BDFBFD8DDE07@cs.umd.edu> <200707081631.36708.pascal@quies.net> Message-ID: <200707081756.37260.pascal@quies.net> More fixes and implements read(byte[]) too. As promissed, I'll stop flooding this mailinglist for a while and see what happens... -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferedInputStream.patch Type: text/x-diff Size: 12313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Sun Jul 8 18:00:42 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 8 Jul 2007 20:00:42 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 draft 2 In-Reply-To: <12FD6803-E4DB-45BB-86F7-BDE03AC30E00@cs.umd.edu> References: <200707081400.25957.pascal@quies.net> <200707081630.14828.pascal@quies.net> <12FD6803-E4DB-45BB-86F7-BDE03AC30E00@cs.umd.edu> Message-ID: <200707082000.49307.pascal@quies.net> 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... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Tue Jul 10 15:23:58 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 10 Jul 2007 17:23:58 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 & 6557791 rc In-Reply-To: <200707081756.37260.pascal@quies.net> References: <200707081400.25957.pascal@quies.net> <200707081631.36708.pascal@quies.net> <200707081756.37260.pascal@quies.net> Message-ID: <200707101724.04474.pascal@quies.net> The patch is supposed to fix at least the following bugs. bug 4254082: Marked as "Closed, will not be fixed" for no good reason. The new skip(long) implementation discards as much as possible from the buffer and requests in.skip(long) to do the rest if necessary. The test case works correct now. bug 4401235: Marked as "Closed, not a bug" for no good reason. The updated read(byte[], int, int) does no longer block as it is documented not to do so. The test case works correct now. bug 4479751 & 6192696: Falsely marked as "Closed, fixed" and so are their "Related Bugs". The updated fill() uses available(). The test case works correct now. bug 6557791: With 6192696 fixed, read(byte[]) had to be implemented to make sure it works as described in InputStream.read(byte[]). The new implementation also fixes this bug. The test case works correct now. I think the patch is ready. Any success/failure reports or comments/critics are more than welcome. Cheers, Pascal -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferedInputStream.patch Type: text/x-diff Size: 12744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pugh at cs.umd.edu Tue Jul 10 22:50:22 2007 From: pugh at cs.umd.edu (Bill Pugh) Date: Tue, 10 Jul 2007 15:50:22 -0700 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <4694099D.2040905@sun.com> References: <469054E6.6060706@sun.com> <200707081441.59779.pascal@quies.net> <4694099D.2040905@sun.com> Message-ID: The proposed change is that BufferedInputStream skip should not skip less bytes than requested unless there are no buffered bytes and a call to skip on the wrapped input stream returns 0. Since the return value of skip is rarely checked, a short skip will almost certainly result in program failure. As a consequence of this change, skip may block in situations where it could avoid blocking by performing a short skip. Since I believe that a short skip is likely to result in program failure, and blocking is better than failure, I believe this is an acceptable change. Bill On Jul 10, 2007, at 3:35 PM, Christopher Hegarty - Sun Microsystems wrote: > Hi Pascal, Bill, et al, > > I was responsible for integrating the contributed fix for 6192696. > The problem with it was that it relied on a 'good' implementation > of the available method. By 'good' I mean that it actually returns > the amount of data that can be read without blocking, and not > simply 1. ZipInputStream.available simply returns 1 (if there is > any data available) as it is difficult to determine the amount of > available data when dynamically uncompressing a data stream. > > Now, using available to try and fill as much of > BufferedInputStream's internal buffer without blocking may result > in reading only 1 byte at a time from the underlying stream, > creating a performance degradation. See > 6409506 and 6411870. > > I'm not sure what exactly is being proposed here, but if available > is going to be used to optimize the amount of data actually > skipped, be aware of the limitation of ZipInputStream.available and > other 'bad' available implementations. > > -Chris. > > Pascal S. de Kloe wrote: >> Hello Martin, >>> 6192696: BufferedInputStream.read(byte[], int, int) can block if the >>> entire buffer can't be filled >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 >> The problem is fill(). It doesn't check available(). The patch on >> this mailing list is supposed to fix that too. From Christopher.Hegarty at Sun.COM Tue Jul 10 22:35:09 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems) Date: Tue, 10 Jul 2007 23:35:09 +0100 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <200707081441.59779.pascal@quies.net> References: <469054E6.6060706@sun.com> <200707081441.59779.pascal@quies.net> Message-ID: <4694099D.2040905@sun.com> Hi Pascal, Bill, et al, I was responsible for integrating the contributed fix for 6192696. The problem with it was that it relied on a 'good' implementation of the available method. By 'good' I mean that it actually returns the amount of data that can be read without blocking, and not simply 1. ZipInputStream.available simply returns 1 (if there is any data available) as it is difficult to determine the amount of available data when dynamically uncompressing a data stream. Now, using available to try and fill as much of BufferedInputStream's internal buffer without blocking may result in reading only 1 byte at a time from the underlying stream, creating a performance degradation. See 6409506 and 6411870. I'm not sure what exactly is being proposed here, but if available is going to be used to optimize the amount of data actually skipped, be aware of the limitation of ZipInputStream.available and other 'bad' available implementations. -Chris. Pascal S. de Kloe wrote: > Hello Martin, > >> 6192696: BufferedInputStream.read(byte[], int, int) can block if the >> entire buffer can't be filled >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 > > The problem is fill(). It doesn't check available(). The patch on this > mailing list is supposed to fix that too. From jackieict at gmail.com Thu Jul 12 07:16:01 2007 From: jackieict at gmail.com (zhang Jackie) Date: Thu, 12 Jul 2007 15:16:01 +0800 Subject: build j2se project in netbeans 5.5.1 Message-ID: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.Petrov at Sun.COM Thu Jul 12 08:00:17 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 12 Jul 2007 12:00:17 +0400 Subject: build j2se project in netbeans 5.5.1 In-Reply-To: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> References: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> Message-ID: <4695DF91.8000306@sun.com> Hi Zhang, First of all, I believe that the nb-projects-dev@ mailing list is more appropriate for such questions. AFAIK the NetBeans projects are currently supported by the NetBeans 6 beta only. They might not work in the current stable versions of the NetBeans. Please install the latest beta version of the NetBeans 6 and try again. -- best regards, Anthony On 07/12/2007 11:16 AM zhang Jackie wrote: > 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. > From pascal at quies.net Thu Jul 12 14:39:33 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 12 Jul 2007 16:39:33 +0200 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <4694099D.2040905@sun.com> References: <200707081441.59779.pascal@quies.net> <4694099D.2040905@sun.com> Message-ID: <200707121639.41366.pascal@quies.net> Hello Christopher, Thank you for this information. :) Would you happen to know if somebody even tried to make a better available() for ZipInputStream? For instance, the manual of gzip(1) notes that the compressed data can only be a 5B larger per 32KB block than the original in the worst case scenario. The current BufferedInputStream is known not to work in various situations and with various other streams. I'd say that the correctness of operation is more important than performance problems. Besides, buffering a ZIP stream is weird, isn't it? Is documenting this limitation a option? For the specific patch posted earlier that day skip() should be fine but read() and read(byte[], int, int) will be affected. On Wednesday 11 July 2007 00:35:09 you wrote: > Hi Pascal, Bill, et al, > > I was responsible for integrating the contributed fix for 6192696. > The problem with it was that it relied on a 'good' implementation of > the available method. By 'good' I mean that it actually returns the > amount of data that can be read without blocking, and not simply 1. > ZipInputStream.available simply returns 1 (if there is any data > available) as it is difficult to determine the amount of available > data when dynamically uncompressing a data stream. > > Now, using available to try and fill as much of BufferedInputStream's > internal buffer without blocking may result in reading only 1 byte at > a time from the underlying stream, creating a performance > degradation. See 6409506 and 6411870. > > I'm not sure what exactly is being proposed here, but if available is > going to be used to optimize the amount of data actually skipped, be > aware of the limitation of ZipInputStream.available and other 'bad' > available implementations. > > -Chris. > > Pascal S. de Kloe wrote: > > Hello Martin, > > > >> 6192696: BufferedInputStream.read(byte[], int, int) can block if > >> the entire buffer can't be filled > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 > > > > The problem is fill(). It doesn't check available(). The patch on > > this mailing list is supposed to fix that too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Thu Jul 12 14:43:11 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 12 Jul 2007 16:43:11 +0200 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: References: <4694099D.2040905@sun.com> Message-ID: <200707121643.12638.pascal@quies.net> Hello Bill, This may cause dead-locks. Do you really want such a bug because some people may not have gotten the API right? On Wednesday 11 July 2007 00:50:22 you wrote: > The proposed change is that BufferedInputStream skip should not skip > less bytes than requested unless there are no buffered bytes and a > call to skip on the wrapped input stream returns 0. > > Since the return value of skip is rarely checked, a short skip will > almost certainly result in program failure. > > As a consequence of this change, skip may block in situations where > it could avoid blocking by performing a short skip. Since I believe > that a short skip is likely to result in program failure, and > blocking is better than failure, I believe this is an acceptable > change. > > Bill > > > On Jul 10, 2007, at 3:35 PM, Christopher Hegarty - Sun Microsystems > > wrote: > > Hi Pascal, Bill, et al, > > > > I was responsible for integrating the contributed fix for 6192696. > > The problem with it was that it relied on a 'good' implementation > > of the available method. By 'good' I mean that it actually returns > > the amount of data that can be read without blocking, and not > > simply 1. ZipInputStream.available simply returns 1 (if there is > > any data available) as it is difficult to determine the amount of > > available data when dynamically uncompressing a data stream. > > > > Now, using available to try and fill as much of > > BufferedInputStream's internal buffer without blocking may result > > in reading only 1 byte at a time from the underlying stream, > > creating a performance degradation. See > > 6409506 and 6411870. > > > > I'm not sure what exactly is being proposed here, but if available > > is going to be used to optimize the amount of data actually > > skipped, be aware of the limitation of ZipInputStream.available and > > other 'bad' available implementations. > > > > -Chris. > > > > Pascal S. de Kloe wrote: > >> Hello Martin, > >> > >>> 6192696: BufferedInputStream.read(byte[], int, int) can block if > >>> the entire buffer can't be filled > >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 > >> > >> The problem is fill(). It doesn't check available(). The patch on > >> this mailing list is supposed to fix that too. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pascal at quies.net Thu Jul 12 16:37:38 2007 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 12 Jul 2007 18:37:38 +0200 Subject: [PATH] bug 4254082 & 4479751 & 6192696 & 6557791 rc2 In-Reply-To: <200707101724.04474.pascal@quies.net> References: <200707081400.25957.pascal@quies.net> <200707081756.37260.pascal@quies.net> <200707101724.04474.pascal@quies.net> Message-ID: <200707121837.43417.pascal@quies.net> The attachment contains the latest patch with two (embarrassing stupid) fixes. The good news is that the few testers did have good results including little performance gains. The bad news is that many (all?) streams do not include EOF in the available() so that read(byte[], int, int) keeps returning 0. Any opinions on that? -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferedInputStream.patch Type: text/x-diff Size: 12677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From David.Bristor at Sun.COM Thu Jul 12 16:41:06 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Thu, 12 Jul 2007 09:41:06 -0700 Subject: Patch to fix BufferedInputStream.skip and bug 4254082 In-Reply-To: <200707121639.41366.pascal@quies.net> References: <200707081441.59779.pascal@quies.net> <4694099D.2040905@sun.com> <200707121639.41366.pascal@quies.net> Message-ID: <469659A2.80600@sun.com> Hi Pascal, Pascal S. de Kloe wrote: > Hello Christopher, > > Thank you for this information. :) > > Would you happen to know if somebody even tried to make a better > available() for ZipInputStream? > For instance, the manual of gzip(1) notes that the compressed data can > only be a 5B larger per 32KB block than the original in the worst case > scenario. While such a change might be desirable, it would be an incompatible change, as ZipInputStream.available() has been defined to return 0 or 1 since it was first introduced in 1998 (ditto for base class InflaterInputStream.available()). By now it is possible that some code is depending on this behavior. Sad but true, and so we are loathe to change it. Thanks, Dave > > The current BufferedInputStream is known not to work in various > situations and with various other streams. I'd say that the correctness > of operation is more important than performance problems. Besides, > buffering a ZIP stream is weird, isn't it? Is documenting this > limitation a option? > > For the specific patch posted earlier that day skip() should be fine but > read() and read(byte[], int, int) will be affected. > > > On Wednesday 11 July 2007 00:35:09 you wrote: > >>Hi Pascal, Bill, et al, >> >>I was responsible for integrating the contributed fix for 6192696. >>The problem with it was that it relied on a 'good' implementation of >>the available method. By 'good' I mean that it actually returns the >>amount of data that can be read without blocking, and not simply 1. >>ZipInputStream.available simply returns 1 (if there is any data >>available) as it is difficult to determine the amount of available >>data when dynamically uncompressing a data stream. >> >>Now, using available to try and fill as much of BufferedInputStream's >>internal buffer without blocking may result in reading only 1 byte at >>a time from the underlying stream, creating a performance >>degradation. See 6409506 and 6411870. >> >>I'm not sure what exactly is being proposed here, but if available is >>going to be used to optimize the amount of data actually skipped, be >>aware of the limitation of ZipInputStream.available and other 'bad' >>available implementations. >> >>-Chris. >> >>Pascal S. de Kloe wrote: >> >>>Hello Martin, >>> >>> >>>>6192696: BufferedInputStream.read(byte[], int, int) can block if >>>>the entire buffer can't be filled >>>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696 >>> >>>The problem is fill(). It doesn't check available(). The patch on >>>this mailing list is supposed to fix that too. > > > From Jonathan.Gibbons at Sun.COM Thu Jul 12 17:07:32 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 12 Jul 2007 10:07:32 -0700 Subject: build j2se project in netbeans 5.5.1 In-Reply-To: <4695DF91.8000306@sun.com> References: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> <4695DF91.8000306@sun.com> Message-ID: <2CC3B81C-B4A0-4C6A-96BA-938211B82360@sun.com> Zhang, As a general rule, to override the default value of a variable like BOOTDIR in the Makefiles, you should set the ALT_xxx environment variable before running make -- in this case, that would be ALT_BOOTDIR. -- Jon G. On Jul 12, 2007, at 1:00 AM, Anthony Petrov wrote: > Hi Zhang, > > First of all, I believe that the nb-projects-dev@ mailing list is > more appropriate for such questions. > > AFAIK the NetBeans projects are currently supported by the NetBeans > 6 beta only. They might not work in the current stable versions of > the NetBeans. Please install the latest beta version of the > NetBeans 6 and try again. > > -- > best regards, > Anthony > > > On 07/12/2007 11:16 AM zhang Jackie wrote: >> 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. >> From Kelly.Ohair at Sun.COM Sat Jul 14 00:19:01 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 13 Jul 2007 17:19:01 -0700 Subject: build j2se project in netbeans 5.5.1 In-Reply-To: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> References: <13432ab00707120016m67d90a6asd862f44807fdd236@mail.gmail.com> Message-ID: <46981675.7040702@sun.com> Please read: https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/README-builds.html -kto zhang Jackie wrote: > 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. > From i30817 at gmail.com Sat Jul 14 17:52:22 2007 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 14 Jul 2007 18:52:22 +0100 Subject: [DISCUSSION] Views of immutable objects. Message-ID: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman at kennke.org Mon Jul 16 17:51:16 2007 From: roman at kennke.org (Roman Kennke) Date: Mon, 16 Jul 2007 19:51:16 +0200 Subject: [DISCUSSION] Views of immutable objects. In-Reply-To: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com> References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com> Message-ID: <1184608276.6246.23.camel@mercury> Hi Paulo, Am Samstag, den 14.07.2007, 18:52 +0100 schrieb Paulo Levi: > 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. If you need a read-only view of String to avoid allocation, well, the String already is read-only. You can access the character data via the CharSequence interface. For Swing, there's javax.swing.text.Segment, which also implements this interface. However, as you noticed, the original char array needs to be copied (bad design decision if you ask me, but not a big issue either). Then there's java.nio.CharBuffer, which can create read-only views of CharSequences too. Depending on your needs, one of the above might help you or not. I don't think that a read-only primitive array is possible, and it probably won't help. If you have a memory leak, make sure you understand how Strings work and what you are doing. String are a little special in Java, wrt to memory usage and such, but nothing that can't be solved with existing features. /Roman -- http://kennke.org/blog/ From lists at pbw.id.au Wed Jul 18 08:09:17 2007 From: lists at pbw.id.au (Peter B. West) Date: Wed, 18 Jul 2007 18:09:17 +1000 Subject: 6410729 Add BitSet.previousClearBit, previousSetBit Message-ID: <469DCAAD.9000609@pbw.id.au> 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 Folio -------------- next part -------------- A non-text attachment was scrubbed... Name: BitSet.tgz Type: application/x-compressed-tar Size: 14784 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BitSet.java.diff Type: text/x-patch Size: 2793 bytes Desc: not available URL: From Martin.Buchholz at Sun.COM Wed Jul 18 08:16:02 2007 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Wed, 18 Jul 2007 01:16:02 -0700 Subject: 6410729 Add BitSet.previousClearBit, previousSetBit In-Reply-To: <469DCAAD.9000609@pbw.id.au> References: <469DCAAD.9000609@pbw.id.au> Message-ID: <469DCC42.4030606@sun.com> Peter, Thanks. I agree that previousClearBit, previousSetBit are worth adding to BitSet and intend to work on integrating your contribution soon. BitSet has not seen a lot of maintenance the past few years, but I have been involved with most of it. Martin Peter B. West wrote: > 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? > > > ------------------------------------------------------------------------ > > --- openjdk/j2se/src/share/classes/java/util/BitSet.java 2007-07-05 17:49:27.000000000 +1000 > +++ openjdk.mods/j2se/src/share/classes/java/util/BitSet.java 2007-07-18 16:16:59.000000000 +1000 > @@ -593,6 +593,81 @@ > } > > /** > + * Returns the index of the nearest bit that is set to true > + * that occurs on or before the specified starting index. If no such > + * bit exists then -1 is returned. > + * > + * To iterate over the true bits in a BitSet, > + * use the following loop: > + * > + * 
> +     * int i = bs.previousSetBit(bs.length);
> +     * while (i >= 0) {
> +     *     // operate on index i here
> +     *     if (--i < 0) {
> +     *          i = bs.previousSetBit(i);
> +     *     }
> +     * }
> +     * 
> +     * @param fromIndex the index to start checking from (inclusive).
> +     * @return the index of the previous set bit.
> +     * @throws IndexOutOfBoundsException if the specified index is negative.
> +     */
> +    public int previousSetBit(int fromIndex) {
> +	if (fromIndex < 0)
> +	    throw new IndexOutOfBoundsException("fromIndex < 0: " + fromIndex);
> +
> +	checkInvariants();
> +
> +        int u = wordIndex(fromIndex);
> +        if (u >= wordsInUse) {
> +            return length() - 1;
> +        }
> +            
> +        long mask = (WORD_MASK << fromIndex + 1) ^ WORD_MASK;
> +	long word = words[u] & ( mask != 0 ? mask : WORD_MASK );
> +
> +	while (true) {
> +	    if (word != 0)
> +		return (u * BITS_PER_WORD) + BIT_INDEX_MASK - Long.numberOfLeadingZeros(word);
> +	    if (u-- == 0)
> +		return -1;
> +	    word = words[u];
> +	}
> +    }
> +
> +    /**
> +     * Returns the index of the nearest bit that is set to false
> +     * that occurs on or before the specified starting index.
> +     *
> +     * @param   fromIndex the index to start checking from (inclusive).
> +     * @return  the index of the previous clear bit.
> +     * @throws  IndexOutOfBoundsException if the specified index is negative.
> +     */
> +    public int previousClearBit(int fromIndex) {
> +	if (fromIndex < 0)
> +	    throw new IndexOutOfBoundsException("fromIndex < 0: " + fromIndex);
> +
> +	checkInvariants();
> +
> +        int u = wordIndex(fromIndex);
> +        if (u >= wordsInUse) {
> +            return fromIndex;
> +        }
> +
> +        long mask = (WORD_MASK << fromIndex + 1) ^ WORD_MASK;
> +	long word = ~words[u] & ( mask != 0 ? mask : WORD_MASK );
> +
> +	while (true) {
> +	    if (word != 0)
> +		return (u * BITS_PER_WORD) + BIT_INDEX_MASK - Long.numberOfLeadingZeros(word);
> +	    if (u-- == 0)
> +		return -1;
> +	    word = ~words[u];
> +	}
> +    }
> +
> +    /**
>       * Returns the "logical size" of this BitSet: the index of
>       * the highest set bit in the BitSet plus one. Returns zero
>       * if the BitSet contains no set bits.


From lists at pbw.id.au  Wed Jul 18 13:58:45 2007
From: lists at pbw.id.au (Peter B. West)
Date: Wed, 18 Jul 2007 23:58:45 +1000
Subject: 6410729 Add BitSet.previousClearBit, previousSetBit
In-Reply-To: <469DCC42.4030606@sun.com>
References: <469DCAAD.9000609@pbw.id.au> <469DCC42.4030606@sun.com>
Message-ID: <469E1C95.3000208@pbw.id.au>

Martin Buchholz wrote:
> Peter,
> 
> Thanks.
> 
> I agree that previousClearBit, previousSetBit are worth
> adding to BitSet and intend to work on integrating your
> contribution soon.
> 
> BitSet has not seen a lot of maintenance the past few
> years, but I have been involved with most of it.
> 
> Martin
> 

Thanks Martin. There was a bug in the documentation. Here's an updated diff.

-- 
Peter B. West 
Folio 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BitSet.java.diff
Type: text/x-patch
Size: 2794 bytes
Desc: not available
URL: 

From i30817 at gmail.com  Wed Jul 25 18:29:08 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Wed, 25 Jul 2007 19:29:08 +0100
Subject: [DISCUSSION] LinkedHashMap iteration order.
Message-ID: <212322090707251129l4f502b3aoc9fbc3066242ab6a@mail.gmail.com>

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
 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)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From i30817 at gmail.com  Sun Jul 29 19:14:59 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Sun, 29 Jul 2007 20:14:59 +0100
Subject: [DISCUSSION] Views of immutable objects.
In-Reply-To: <1184608276.6246.23.camel@mercury>
References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com>
	<1184608276.6246.23.camel@mercury>
Message-ID: <212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>

What about adding a method to String complementing the call toCharArray(),
only it takes 3 arguments:
An char array, a position and a length, that inside uses System.arrayCopy.
This would create the possibility to eliminate news when we just want to
copy Strings, and still preserve immutability.
I'm asking this in string and not using the ChartAt interface for a simple
reason:
Abstraction leakage
The only way to copy a string into a char array is (currently) to transform
it into a char[] and copy it into the original o(2n) or to iterate over all
the chars with o(n* (1 + constantboundCheck)).
CharSequence does not assume that the underlying primitive representation is
a char [] so it does not have a method that takes one. Maybe it should,
maybe it shouldn't, but on the other hand i believe that at least string
should have a method like that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From i30817 at gmail.com  Sat Jul 28 17:41:55 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Sat, 28 Jul 2007 18:41:55 +0100
Subject: [DISCUSSION] LinkedHashMap iteration order.
In-Reply-To: <212322090707251129l4f502b3aoc9fbc3066242ab6a@mail.gmail.com>
References: <212322090707251129l4f502b3aoc9fbc3066242ab6a@mail.gmail.com>
Message-ID: <212322090707281041u4028a9e1hc06f2a82e93f2434@mail.gmail.com>

Well. I've solved it independently hacking a hashmap that also maintains its
access order in a LinkedList in the get, put and remove calls. A pity about
the remove being o(n) but i couldn't find a way to iterate over the
LinkedHashSet in reverse order (which was kinda the point anyway, since
LinkedHashMap is built on LinkedHashSet)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From i30817 at gmail.com  Sat Jul 28 17:47:36 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Sat, 28 Jul 2007 18:47:36 +0100
Subject: [DISCUSSION] Views of immutable objects.
In-Reply-To: <1184608276.6246.23.camel@mercury>
References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com>
	<1184608276.6246.23.camel@mercury>
Message-ID: <212322090707281047j39779d8fr194aac1cf644b106@mail.gmail.com>

What about adding a method to String complementing the call toCharArray(),
only it takes 3 arguments:
An char array, a position and a length, that inside uses System.arrayCopy.
This would create the possibility to eliminate news when we just want to
copy Strings, and still preserve immutability
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From news at jnana.de  Mon Jul 30 19:26:24 2007
From: news at jnana.de (Ralf Ullrich)
Date: Mon, 30 Jul 2007 19:26:24 +0000 (UTC)
Subject: [DISCUSSION] Views of immutable objects.
References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com>
	<1184608276.6246.23.camel@mercury>
	<212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>
Message-ID: 

Paulo Levi wrote:

>What about adding a method to String complementing the call toCharArray(),
>only it takes 3 arguments:
>An char array, a position and a length, that inside uses System.arrayCopy.

Isn't that exactly what

   String#getChars(0, length, charArray, dstpos)

does?

(see also 
http://java.sun.com/javase/6/docs/api/java/lang/String.html#getChars(int,%20int,%20char[],%20int) 
)

cu



From i30817 at gmail.com  Tue Jul 31 22:26:28 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Tue, 31 Jul 2007 23:26:28 +0100
Subject: [DISCUSSION] Views of immutable objects.
In-Reply-To: <212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>
References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com>
	<1184608276.6246.23.camel@mercury>
	<212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>
Message-ID: <212322090707311526u3354255y2f07090292f94c4d@mail.gmail.com>

You're right, that method does what i suggested. Unfortunately it doesn't
seem to help as i thought it would. I wanted to both eliminate the
allocation and any copying done before inserting the String on the Document.
I can eliminate the allocation keeping a buffer for a String bellow a
certain size (a leak prone technique this where many documents are
instantiated), but not the copying since the internal gapvector does not
allow subclasses to access the internal char [] a string insertion and use
getChars internally. It can only use a char array and then THAT means i must
copy, since there is no way to put the string char [] into the gapVector, or
to take the gapVector char[] and fill it with the string char[].

WARNING : shameless modification of jdk gpl'd code

An alternative, add one method to the package protected abstract class
GapVector:

protected void replace(int position, int rmSize, String addItems, int
addSize) {
    int addOffset = 0;
    if (addSize == 0) {
        close(position, rmSize);
        return;
    } else if (rmSize > addSize) {
        /* Shrink the end. */
        close(position+addSize, rmSize-addSize);
    } else {
        /* Grow the end, do two chunks. */
        //int endSize = addSize - rmSize;
        int end = open(position + rmSize, addSize - rmSize);
        //System.arraycopy(addItems, rmSize, array, end, endSize);
        addItems.getChars(rmSize, addSize, array, end);
        addSize = rmSize;
    }
    //System.arraycopy(addItems, addOffset, array, position, addSize);
    addItems.getChars(addOffset, addSize, array, position);
}

and change the GapContent subclass of gapVector insertString method to this:
public UndoableEdit insertString(int where, String str) throws
BadLocationException {
    if (where > length() || where < 0) {
        throw new BadLocationException("Invalid insert", length());
    }
    //char[] chars = str.toCharArray();
    //replace(where, 0, chars, chars.length);
    replace(where, 0, str, str.length() );
    return new InsertUndo(where, str.length());
}

Voila. If nothing is wrong in the first function, no copy needed in the
Document Hierarchy.
Only this doesn't help those of us using 1.5 even if it is accepted as a
contribution.

I think package protected is evil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From i30817 at gmail.com  Tue Jul 31 22:42:57 2007
From: i30817 at gmail.com (Paulo Levi)
Date: Tue, 31 Jul 2007 23:42:57 +0100
Subject: [DISCUSSION] Views of immutable objects.
In-Reply-To: <212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>
References: <212322090707141052i2c35c325v1965cfe235de1975@mail.gmail.com>
	<1184608276.6246.23.camel@mercury>
	<212322090707291214ya70a31bl60aa9ca7bd0bf4ed@mail.gmail.com>
Message-ID: <212322090707311542q5ea9501byc9351af976e3af89@mail.gmail.com>

Err. That is solves MY specific problem with char[]'s. If only impedance
mismatch wasn't such a problem with abstractions. I still think it would be
a good idea to get a read-only view of primitives, if it could be
implemented efficiently and transparently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: