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
>>
>