From Alan.Bateman at oracle.com Thu Jul 1 02:06:03 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Jul 2010 10:06:03 +0100 Subject: FileStore... getRootPath() ? In-Reply-To: <4C2BBA85.7030801@xs4all.nl> References: <4C2B6A37.10802@xs4all.nl> <4C2BADA6.9090009@oracle.com> <4C2BBA85.7030801@xs4all.nl> Message-ID: <4C2C5A7B.3010502@oracle.com> John Hendrikx wrote: > Well, the filtering would simply do the following (for Linux, Windows > does not need any filtering, although applying the same filter would > not adversely affect the result): > > 1) spaceAttribs.totalSpace() != 0; (eliminates /proc, /sys, etc..) > 2) fileStore.type() != "tmpfs"; (eliminates /dev, /dev/shm, etc..) > > And although this is a bit of a kludge, on my test systems that leaves > me with only the mountpoints, ie.: > > / (/dev/hda2) > /data (/dev/md0) > /raid1 (/dev/mapper/raid1) > /raid2 (/dev/mapper/raid2) > /temp (/dev/mapper/temp) > > Those are then easy to present in a multi-column list with total size > and free space information. > > Reasons for needing such a list: > > 1) Allowing the user to select an entire volume (for backup, or > (restore) destination) for example. > 2) Giving the user a start point for navigating the directory tree (on > Windows the drive letters work, although My Computer would be better. > On Linux "/" works, but is clumsy... most native apps will have a list > of mount points somewhere). > 3) Informational. Free and Total space shown in a monitoring > application or perhaps to select a suitable location to install > something big (with sufficient free space) :) > > I realize what I'm trying to do is probably a bit beyond NIO2's scope > -- but providing the user with a fully functional view of the > filesystems on a (any?) system is now close to possible (hence why I'm > trying this). Providing access to the file system hierarchy makes sense for this API but I can't really offer any advice on how this should be filtered for the end-user. The above will help but likely be too fragile for the number of possible file systems that your code might encounter. It might be that you really just want to give the user the choice of a couple of locations, saying the user's home directory, devices, and perhaps other machines on the network. There is an opportunity for someone to develop a "desktop" file system provider that understand desktop concepts. It could be layered over the default provider and would make it easy to develop applications like the Nautilus file manager. -Alan. From Alan.Bateman at oracle.com Mon Jul 19 07:00:33 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jul 2010 15:00:33 +0100 Subject: 6963907: (so) Socket adapter need to implement sendUrgentData Message-ID: <4C445A81.60202@oracle.com> Some limited support for sending out of band/TCP urgent data was added in jdk1.4 to java.net.Socket. This was never implemented by SocketChannel's socket adapter but as TCP urgent data isn't used by many protocols, it just hasn't been a problem. It turns out that at least two SQL protocols do use TCP urgent data and JDBC drivers using NIO do need this implemented. I've put the webrev here: http://cr.openjdk.java.net/~alanb/6963907/webrev The main thing is that sendUrgentData is only usable when the socket channel is configured blocking as it cannot complete successfully having written zero bytes (throwing IllegalBlockingModeException is consistent with other socket adapter methods). -Alan. From Alan.Bateman at oracle.com Mon Jul 19 07:08:39 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jul 2010 15:08:39 +0100 Subject: Files.walkFileTree Message-ID: <4C445C67.1080707@oracle.com> Files.walkFileTree has accumulated a few issues that I plan to fix soon. Earlier this year R?mi observed that the FileVisitor methods can't throw a IOException and jave propagate it to the caller of Files.walkFileTree. John Hendrikx pointed out that the preVisitDirectory should be invoked with the attributes of the directory. The other one is Jon Gibbon's observation that using the maxDepth parameter requires opening the directory at maxDepth+1. All of these issues require updating the javadoc so I'd like to do them in one batch. Does anyone have any other issues with Files.walkFileTree/FileVisitor that need to be fixed while in the area? Thanks, -Alan. From lists at laerad.com Mon Jul 19 07:31:08 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Mon, 19 Jul 2010 15:31:08 +0100 Subject: Files.walkFileTree In-Reply-To: <4C445C67.1080707@oracle.com> References: <4C445C67.1080707@oracle.com> Message-ID: For very large directories it is useful to be able to perform a walk with multiple threads - i abandoned this API in a project recently for that very reason. Obviously a File.walkFileTreeConcurrently() (or similar) method would have to error if any method result was SKIP_SIBLINGS, and accept that TERMINATE would not effect an immediate stop. Not sure if you're desperately keen to add such functionality, but it might be worth considering while you're looking at it. On 19 July 2010 15:08, Alan Bateman wrote: > > Files.walkFileTree has accumulated a few issues that I plan to fix soon. > Earlier this year R?mi observed that the FileVisitor methods can't throw a > IOException and jave propagate it to the caller of Files.walkFileTree. John > Hendrikx pointed out that the preVisitDirectory should be invoked with the > attributes of the directory. The other one is Jon Gibbon's observation that > using the maxDepth parameter requires opening the directory at maxDepth+1. > All of these issues require updating the javadoc so I'd like to do them in > one batch. Does anyone have any other issues with > Files.walkFileTree/FileVisitor that need to be fixed while in the area? > > Thanks, > > -Alan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100719/638ae025/attachment.html From chris.hegarty at oracle.com Mon Jul 19 08:50:02 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 Jul 2010 16:50:02 +0100 Subject: 6963907: (so) Socket adapter need to implement sendUrgentData In-Reply-To: <4C445A81.60202@oracle.com> References: <4C445A81.60202@oracle.com> Message-ID: <4C44742A.4030909@oracle.com> The change looks fine. One minor comment about the test, @library -> @bug -Chris. On 07/19/10 15:00, Alan Bateman wrote: > > Some limited support for sending out of band/TCP urgent data was added > in jdk1.4 to java.net.Socket. This was never implemented by > SocketChannel's socket adapter but as TCP urgent data isn't used by many > protocols, it just hasn't been a problem. It turns out that at least two > SQL protocols do use TCP urgent data and JDBC drivers using NIO do need > this implemented. I've put the webrev here: > http://cr.openjdk.java.net/~alanb/6963907/webrev > > The main thing is that sendUrgentData is only usable when the socket > channel is configured blocking as it cannot complete successfully having > written zero bytes (throwing IllegalBlockingModeException is consistent > with other socket adapter methods). > > -Alan. > From Alan.Bateman at oracle.com Mon Jul 19 10:05:40 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jul 2010 18:05:40 +0100 Subject: Files.walkFileTree In-Reply-To: References: <4C445C67.1080707@oracle.com> Message-ID: <4C4485E4.1020804@oracle.com> Benedict Elliott Smith wrote: > For very large directories it is useful to be able to perform a walk > with multiple threads - i abandoned this API in a project recently for > that very reason. Obviously a File.walkFileTreeConcurrently() (or > similar) method would have to error if any method result was > SKIP_SIBLINGS, and accept that TERMINATE would not effect an immediate > stop. > > Not sure if you're desperately keen to add such functionality, but it > might be worth considering while you're looking at it. > I'm just fixing up issues with the current walkFileTree method. A concurrent implementation would be a fun project and clearly an area to research more before thinking about adding to the Files class. You probably know this already, but Files.walkFileTree is independent of any provider and so you should be able to write your own file tree walk without requiring additional support. It interesting to compare against using walkFileTree with a single thread that queues tasks to a work queue. -Alan. From Alan.Bateman at oracle.com Mon Jul 19 11:00:29 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jul 2010 19:00:29 +0100 Subject: 6963907: (so) Socket adapter need to implement sendUrgentData In-Reply-To: <4C44742A.4030909@oracle.com> References: <4C445A81.60202@oracle.com> <4C44742A.4030909@oracle.com> Message-ID: <4C4492BD.2050505@oracle.com> Chris Hegarty wrote: > The change looks fine. > > One minor comment about the test, @library -> @bug Thanks for catching this. -Alan From Alan.Bateman at oracle.com Wed Jul 21 07:36:37 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 21 Jul 2010 15:36:37 +0100 Subject: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated Message-ID: <4C4705F5.7060206@oracle.com> If the file underlying a mapped byte buffer is truncated then it's possible that invoking the MappedByteBuffer's load method will SIGBUS. The reason is that the load touches each page in a native method and the VM's handler cannot deal with the fault. A second and related issue (6799037) is that same native code is reading an int from each page without taking alignment into consideration or the possibility that it might read beyond the end of the mapping. Yet another issue, is that isLoaded fails with an IOException for the case that the mapping doesn't start on a multiple of the page size. The load method has a similar problem but it doesn't throw IOException because it is ignoring the return value from madvise(3C). The webrev with the proposed changes to fix these issues is here: http://cr.openjdk.java.net/~alanb/6934977/webrev The main change is that load is changed to touch the pages via Unsafe and so uses the existing handler. -Alan. From chris.hegarty at oracle.com Mon Jul 26 05:29:09 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 26 Jul 2010 13:29:09 +0100 Subject: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated In-Reply-To: <4C4705F5.7060206@oracle.com> References: <4C4705F5.7060206@oracle.com> Message-ID: <4C4D7F95.8000806@oracle.com> Alan - The changes looks great. -Chris. On 07/21/10 15:36, Alan Bateman wrote: > > If the file underlying a mapped byte buffer is truncated then it's > possible that invoking the MappedByteBuffer's load method will SIGBUS. > The reason is that the load touches each page in a native method and the > VM's handler cannot deal with the fault. A second and related issue > (6799037) is that same native code is reading an int from each page > without taking alignment into consideration or the possibility that it > might read beyond the end of the mapping. Yet another issue, is that > isLoaded fails with an IOException for the case that the mapping doesn't > start on a multiple of the page size. The load method has a similar > problem but it doesn't throw IOException because it is ignoring the > return value from madvise(3C). > > The webrev with the proposed changes to fix these issues is here: > http://cr.openjdk.java.net/~alanb/6934977/webrev > > The main change is that load is changed to touch the pages via Unsafe > and so uses the existing handler. > > -Alan. From forax at univ-mlv.fr Mon Jul 26 06:43:16 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 26 Jul 2010 15:43:16 +0200 Subject: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated In-Reply-To: <4C4D7F95.8000806@oracle.com> References: <4C4705F5.7060206@oracle.com> <4C4D7F95.8000806@oracle.com> Message-ID: <4C4D90F4.7020803@univ-mlv.fr> Hi Alan, in MappedBytBuffer: pagePosition() should return a long, this will avoid most of the casts. mappedPageCount() should take the value of mappedLength() as parameter and mappedAddress() and mappedLength() should take the value of pagePosition() as parameter to avoid to calculate pagePosition() more than once. In load, you store the pageSize() in ps but doesn't use it after, I suppose that your intention was to use it in the loop. for (int i=0; i Alan - The changes looks great. > > -Chris. > > On 07/21/10 15:36, Alan Bateman wrote: >> >> If the file underlying a mapped byte buffer is truncated then it's >> possible that invoking the MappedByteBuffer's load method will SIGBUS. >> The reason is that the load touches each page in a native method and the >> VM's handler cannot deal with the fault. A second and related issue >> (6799037) is that same native code is reading an int from each page >> without taking alignment into consideration or the possibility that it >> might read beyond the end of the mapping. Yet another issue, is that >> isLoaded fails with an IOException for the case that the mapping doesn't >> start on a multiple of the page size. The load method has a similar >> problem but it doesn't throw IOException because it is ignoring the >> return value from madvise(3C). >> >> The webrev with the proposed changes to fix these issues is here: >> http://cr.openjdk.java.net/~alanb/6934977/webrev >> >> The main change is that load is changed to touch the pages via Unsafe >> and so uses the existing handler. >> >> -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100726/ce32286e/attachment.html From Alan.Bateman at oracle.com Mon Jul 26 11:26:59 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jul 2010 19:26:59 +0100 Subject: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated In-Reply-To: <4C4D90F4.7020803@univ-mlv.fr> References: <4C4705F5.7060206@oracle.com> <4C4D7F95.8000806@oracle.com> <4C4D90F4.7020803@univ-mlv.fr> Message-ID: <4C4DD373.2020207@oracle.com> R?mi Forax wrote: > Hi Alan, > in MappedBytBuffer: > pagePosition() should return a long, this will avoid most of the casts. > mappedPageCount() should take the value of mappedLength() as parameter > and mappedAddress() and mappedLength() should take the value of > pagePosition() as parameter to avoid to calculate pagePosition() more > than once. Thanks R?mi, these are good idea (these operations are rarely used but it was a stupid of me to re-calculate the offset more than once). > > In load, you store the pageSize() in ps but doesn't use it after, > I suppose that your intention was to use it in the loop. > for (int i=0; i unsafe.getByte(a); > a += ps; > } > otherwise, it looks fine. You have 20/20 vision - the intention was to use ps in the loop. I've put an updated webrev here: http://cr.openjdk.java.net/~alanb/6934977/webrev.2/ -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100726/ea8bd4ed/attachment.html From Alan.Bateman at oracle.com Mon Jul 26 12:20:07 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jul 2010 20:20:07 +0100 Subject: 6916202: (so) improve scatter/gather implementation Message-ID: <4C4DDFE7.20405@oracle.com> The scatter/gather operations have always been slower than they should have been. The changes proposed here fix a couple of issues. The main one is that each scatter/gather operation was allocating and freeing a native iovec area. The second issue is that the implementation copied or iterated over the array of buffers several times. The third issue arose with applications invoking these methods with more than 3 buffers backed by arrays in the heap as this exceeded the capacity of the per thread buffer pool. The webrev with changes to fix these issues is here: http://cr.openjdk.java.net/~alanb/6916202/webrev/ Thanks, Alan. From chris.hegarty at oracle.com Tue Jul 27 07:51:46 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 27 Jul 2010 15:51:46 +0100 Subject: 6916202: (so) improve scatter/gather implementation In-Reply-To: <4C4EDC26.9040705@oracle.com> References: <4C4DDFE7.20405@oracle.com> <4C4ED9EB.6020501@oracle.com> <4C4EDC26.9040705@oracle.com> Message-ID: <4C4EF282.4040608@oracle.com> Alan, To clarify ( sent in a private mail ), the bug number is 6971825 and the webrev is: http://cr.openjdk.java.net/~alanb/6971825/webrev Comments: Util.getTemporaryDirectBuffer. If reading/writing in non scattering/gathering it looks like a new buffer will be created every time. Should L64 be i <= count? Indentation for "throw new IndexOutOfBoundsException();" in DatagramChannelImpl and FileChannelImpl seems to be only three spaces. The temporary buffer cache is no longer SoftRefs. Do you see any potential side effect of this? Is this deliberate? IOUtil.write/read. Releasing the shadow buffer and clearing the vec refs could just be done in the finally block with need for completed. But then your committing to a second loop, where as with what you have the second loop is only necessary if there is a failure, right? It looks like now you can only read/write with a limit of 8 buffers, where as before it just spilled over to creating short lived direct buffers. I think this should be sufficient, just an observation that we don't spill anymore. -Chris. Alan Bateman wrote: > Chris Hegarty wrote: >> I think you used the wrong bug number, 6971825 right? >> >> -Chris. > 6916202 was one I was looked at with Vinnie last night :-) > > Here's the webrev: > http://cr.openjdk.java.net/~alanb/6971825/webrev/ > > Just so you know, this one is for 6u22m but I want to get it into jdk7 > and let it bake for a bit first. I've asked Sherman to review it too > (the more eyes the better as the changes are tricky). From forax at univ-mlv.fr Tue Jul 27 08:11:49 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 27 Jul 2010 17:11:49 +0200 Subject: 6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated In-Reply-To: <4C4DD373.2020207@oracle.com> References: <4C4705F5.7060206@oracle.com> <4C4D7F95.8000806@oracle.com> <4C4D90F4.7020803@univ-mlv.fr> <4C4DD373.2020207@oracle.com> Message-ID: <4C4EF735.80505@univ-mlv.fr> Le 26/07/2010 20:26, Alan Bateman a ?crit : > R?mi Forax wrote: >> Hi Alan, >> in MappedBytBuffer: >> pagePosition() should return a long, this will avoid most of the casts. >> mappedPageCount() should take the value of mappedLength() as parameter >> and mappedAddress() and mappedLength() should take the value of >> pagePosition() as parameter to avoid to calculate pagePosition() more >> than once. > Thanks R?mi, these are good idea (these operations are rarely used but > it was a stupid of me to re-calculate the offset more than once). > >> >> In load, you store the pageSize() in ps but doesn't use it after, >> I suppose that your intention was to use it in the loop. >> for (int i=0; i> unsafe.getByte(a); >> a += ps; >> } >> otherwise, it looks fine. > You have 20/20 vision - the intention was to use ps in the loop. > > I've put an updated webrev here: > http://cr.openjdk.java.net/~alanb/6934977/webrev.2/ > > -Alan. Ok, looks fine. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100727/cd8c2264/attachment.html From Alan.Bateman at oracle.com Tue Jul 27 08:35:38 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Jul 2010 16:35:38 +0100 Subject: 6916202: (so) improve scatter/gather implementation In-Reply-To: <4C4EF282.4040608@oracle.com> References: <4C4DDFE7.20405@oracle.com> <4C4ED9EB.6020501@oracle.com> <4C4EDC26.9040705@oracle.com> <4C4EF282.4040608@oracle.com> Message-ID: <4C4EFCCA.2020305@oracle.com> Chris Hegarty wrote: > Alan, > > To clarify ( sent in a private mail ), the bug number is 6971825 and > the webrev is: > http://cr.openjdk.java.net/~alanb/6971825/webrev Thanks for looking at this one. Sorry about the bugID, I did indeed get that wrong in the mail. > > Comments: > > Util.getTemporaryDirectBuffer. If reading/writing in non > scattering/gathering it looks like a new buffer will be created every > time. Should L64 be i <= count? The buffers are 0..count-1 so I think this is okay. > > Indentation for "throw new IndexOutOfBoundsException();" in > DatagramChannelImpl and FileChannelImpl seems to be only three spaces. I'll fix that (I just moved the check and it looks like the indentation has always been wrong). > > The temporary buffer cache is no longer SoftRefs. Do you see any > potential side effect of this? Is this deliberate? A soft reference works well for caches in the java heap but it hasn't worked well for direct buffers (that are allocated outside of the java heap). > > IOUtil.write/read. Releasing the shadow buffer and clearing the vec > refs could just be done in the finally block with need for completed. > But then your committing to a second loop, where as with what you have > the second loop is only necessary if there is a failure, right? It could be done this way except that there is potential for a runtime exception when notifying the buffers - for example buggy code that modifies the position or limit while an I/O operation is done on the buffer (it has a happened a few times, and very difficult to diagnose). > > It looks like now you can only read/write with a limit of 8 buffers, > where as before it just spilled over to creating short lived direct > buffers. I think this should be sufficient, just an observation that > we don't spill anymore. Yes, once warmed up then we shouldn't seen any malloc/free going on, even for applications using a huge number of buffers. Most applications using this API don't use scatter/gather and the main difference for these cases is that we're caching at most 1 buffer per thread whereas it was caching up to 3 buffers per thread, which didn't make sense. -Alan. From ichaehoi at gmail.com Thu Jul 29 11:49:44 2010 From: ichaehoi at gmail.com (ibrahim CHAEHOI) Date: Thu, 29 Jul 2010 20:49:44 +0200 Subject: Use StringBuilder in java.util.Matcher Message-ID: Hi all, I'm not sure if it's the right mailing list to post this question, if it's not the case please let me know what is the proper mailing list to post this question. I just would like to know if there is any reason why the appendReplacement method in java.util.Matcher API is only using StringBuffer. Would it be possible to add 2 new methods appendReplacement and appendTail which use a StringBuilder instead of a StringBuffer? public Matcher appendReplacement(StringBuilder sb, String replacement); public StringBuilder appendTail(StringBuilder sb, String replacement); The StringBuilder was introduce in Java 5 as an optimized version of the StringBuffer, when the synchronization is not necessary, and I'm a bit surprised that the Matcher API doesn't provide a method which use a StringBuilder. Cheers, From dmdabbs at gmail.com Thu Jul 29 12:20:12 2010 From: dmdabbs at gmail.com (David Dabbs) Date: Thu, 29 Jul 2010 14:20:12 -0500 Subject: Use StringBuilder in java.util.Matcher In-Reply-To: References: Message-ID: <00d201cb2f53$19f77570$4de66050$@com> Changing the signature to AbstractStringBuilder would make it compatible with both. abstract class: AbstractStringBuilder [javadoc | source] java.lang.Object java.lang.AbstractStringBuilder Direct Known Subclasses: StringBuilder, StringBuffer since: 1.5 Best, David -----Original Message----- From: nio-dev-bounces at openjdk.java.net [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of ibrahim CHAEHOI Sent: Thursday, July 29, 2010 1:50 PM To: nio-dev at openjdk.java.net Subject: Use StringBuilder in java.util.Matcher Hi all, I'm not sure if it's the right mailing list to post this question, if it's not the case please let me know what is the proper mailing list to post this question. I just would like to know if there is any reason why the appendReplacement method in java.util.Matcher API is only using StringBuffer. Would it be possible to add 2 new methods appendReplacement and appendTail which use a StringBuilder instead of a StringBuffer? public Matcher appendReplacement(StringBuilder sb, String replacement); public StringBuilder appendTail(StringBuilder sb, String replacement); The StringBuilder was introduce in Java 5 as an optimized version of the StringBuffer, when the synchronization is not necessary, and I'm a bit surprised that the Matcher API doesn't provide a method which use a StringBuilder. Cheers, No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3035 - Release Date: 07/29/10 01:34:00 From xueming.shen at oracle.com Thu Jul 29 12:33:17 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 29 Jul 2010 12:33:17 -0700 Subject: Use StringBuilder in java.util.Matcher In-Reply-To: <00d201cb2f53$19f77570$4de66050$@com> References: <00d201cb2f53$19f77570$4de66050$@com> Message-ID: <4C51D77D.5000501@oracle.com> There is a webrev from Martin at google to add the support of using StringBuilder for better performance (I need go back to my old Sun mailbox to dig it out) and there is the RFE 5066679: java.util.regex.Matcher should make more use of Appendable which might provide a better approach, and an incomplete webrev can be found at http://cr.openjdk.java.net/~sherman/regex_replace/webrev The only issue left is how to appropriately deal with a possible IOE from Appendable interface. -Sherman David Dabbs wrote: > Changing the signature to AbstractStringBuilder would make it compatible > with both. > > > abstract class: AbstractStringBuilder [javadoc | source] > > java.lang.Object > java.lang.AbstractStringBuilder > > Direct Known Subclasses: > StringBuilder, StringBuffer > > since: 1.5 > > > > > Best, > > David > > > -----Original Message----- > From: nio-dev-bounces at openjdk.java.net > [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of ibrahim CHAEHOI > Sent: Thursday, July 29, 2010 1:50 PM > To: nio-dev at openjdk.java.net > Subject: Use StringBuilder in java.util.Matcher > > Hi all, > > I'm not sure if it's the right mailing list to post this question, > if it's not the case please let me know what is the proper mailing > list to post this question. > > I just would like to know if there is any reason why the > appendReplacement method in java.util.Matcher API is only using > StringBuffer. > Would it be possible to add 2 new methods appendReplacement and > appendTail which use a StringBuilder instead of a StringBuffer? > > public Matcher appendReplacement(StringBuilder sb, String replacement); > > public StringBuilder appendTail(StringBuilder sb, String replacement); > > The StringBuilder was introduce in Java 5 as an optimized version of > the StringBuffer, when the synchronization is not necessary, > and I'm a bit surprised that the Matcher API doesn't provide a method > which use a StringBuilder. > > Cheers, > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.851 / Virus Database: 271.1.1/3035 - Release Date: 07/29/10 > 01:34:00 > > From forax at univ-mlv.fr Fri Jul 30 09:02:32 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 30 Jul 2010 18:02:32 +0200 Subject: Use StringBuilder in java.util.Matcher In-Reply-To: <4C51D77D.5000501@oracle.com> References: <00d201cb2f53$19f77570$4de66050$@com> <4C51D77D.5000501@oracle.com> Message-ID: <4C52F798.1030504@univ-mlv.fr> Le 29/07/2010 21:33, Xueming Shen a ?crit : > There is a webrev from Martin at google to add the support of using > StringBuilder for better > performance (I need go back to my old Sun mailbox to dig it out) and > there is the RFE > > 5066679: java.util.regex.Matcher should make more use of Appendable > > which might provide a better approach, and an incomplete webrev can be > found at > http://cr.openjdk.java.net/~sherman/regex_replace/webrev > > The only issue left is how to appropriately deal with a possible IOE > from Appendable > interface. The only reasonable way is to propagate IOEs to the user and let the user figure out what to do with them. > > -Sherman R?mi > > David Dabbs wrote: >> Changing the signature to AbstractStringBuilder would make it compatible >> with both. >> >> >> abstract class: AbstractStringBuilder [javadoc | source] >> >> java.lang.Object >> java.lang.AbstractStringBuilder >> >> Direct Known Subclasses: >> StringBuilder, StringBuffer >> >> since: 1.5 >> >> >> >> >> Best, >> >> David >> >> >> -----Original Message----- >> From: nio-dev-bounces at openjdk.java.net >> [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of ibrahim CHAEHOI >> Sent: Thursday, July 29, 2010 1:50 PM >> To: nio-dev at openjdk.java.net >> Subject: Use StringBuilder in java.util.Matcher >> >> Hi all, >> >> I'm not sure if it's the right mailing list to post this question, >> if it's not the case please let me know what is the proper mailing >> list to post this question. >> >> I just would like to know if there is any reason why the >> appendReplacement method in java.util.Matcher API is only using >> StringBuffer. >> Would it be possible to add 2 new methods appendReplacement and >> appendTail which use a StringBuilder instead of a StringBuffer? >> >> public Matcher appendReplacement(StringBuilder sb, String replacement); >> >> public StringBuilder appendTail(StringBuilder sb, String replacement); >> >> The StringBuilder was introduce in Java 5 as an optimized version of >> the StringBuffer, when the synchronization is not necessary, >> and I'm a bit surprised that the Matcher API doesn't provide a method >> which use a StringBuilder. >> >> Cheers, >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: >> 271.1.1/3035 - Release Date: 07/29/10 >> 01:34:00 >> >