From tiago.curyz at gmail.com  Wed Jan  7 07:44:15 2009
From: tiago.curyz at gmail.com (Tiago Cury)
Date: Wed, 7 Jan 2009 13:44:15 -0200
Subject: WatchService events
Message-ID: <948B1AAF-BFB5-4844-83F3-742C8B7EAF40@gmail.com>

Hi,

And about the MOVE_FROM, MOVE_IN events from Watch Service ?

regards,
Tiago



From tiago.cury at lanseti.com  Wed Jan  7 07:53:26 2009
From: tiago.cury at lanseti.com (Tiago Cury)
Date: Wed, 7 Jan 2009 13:53:26 -0200
Subject: WatchService events
In-Reply-To: <948B1AAF-BFB5-4844-83F3-742C8B7EAF40@gmail.com>
References: <948B1AAF-BFB5-4844-83F3-742C8B7EAF40@gmail.com>
Message-ID: <4769E4F7-52E9-45D8-92F1-D8337AFB38C0@lanseti.com>

Hi,

I saw the javadoc now.
ENTRY_CREATE - ... is queued when it is observed that an entry is  
created in the directory or renamed into the directory.

It answered my question. Thanks.
Tiago


On Jan 7, 2009, at 1:44 PM, Tiago Cury wrote:

> Hi,
>
> And about the MOVE_FROM, MOVE_IN events from Watch Service ?
>
> regards,
> Tiago
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090107/4c7a6001/attachment.html 

From tiago.curyz at gmail.com  Wed Jan  7 11:14:29 2009
From: tiago.curyz at gmail.com (Tiago Cury)
Date: Wed, 7 Jan 2009 17:14:29 -0200
Subject: NIO.2 on JDK6
Message-ID: <40500690-4E16-4E7D-AE06-EA52B2766736@gmail.com>

Hi,

Any chance to run NIO.2 on JDK5/6 ?

regards,
Tiago



From martinrb at google.com  Wed Jan  7 11:35:55 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 7 Jan 2009 11:35:55 -0800
Subject: NIO.2 on JDK6
In-Reply-To: <40500690-4E16-4E7D-AE06-EA52B2766736@gmail.com>
References: <40500690-4E16-4E7D-AE06-EA52B2766736@gmail.com>
Message-ID: <1ccfd1c10901071135m381d54a1o24dbc7a3dbf1e6c9@mail.gmail.com>

On Wed, Jan 7, 2009 at 11:14, Tiago Cury <tiago.curyz at gmail.com> wrote:
> Hi,
>
> Any chance to run NIO.2 on JDK5/6 ?

Not today, but I would like to work on a backport in the next few months.

Martin

>
> regards,
> Tiago
>
>


From leonfin at optonline.net  Fri Jan 16 10:09:31 2009
From: leonfin at optonline.net (Leon Finker)
Date: Fri, 16 Jan 2009 13:09:31 -0500
Subject: NIO.2 and GC activity
Message-ID: <000f01c97805$9473b3b0$bd5b1b10$@net>

Hi,

 

I would like to provide feedback on NIO.2 based on the specs, and what I've
been reading about the implementation. 

 

1.

I'm drawing from .Net experience here. We have encountered a bottleneck with
earlier .NET networking implementations,

 and I feel that NIO.2 is heading in the same direction. Please correct me
if I'm wrong. 

 

Proposed NIO.2:

Future<Integer> read(ByteBuffer dst, . CompletionHandler<Integer,? super A>
handler)

etc.

 

Earlier versions of .NET: 

IAsyncResult BeginReceive(byte[] buffer, ., AsyncCallback callback, .)

 

The problem is that too many temporary Future/IAsyncResult objects are
created and thrown away without ability to pool them, 

which puts unnecessary stress on the GC. Recent versions of .NET came out
with new much more optimal socket API which eliminates 

all the temporary object creations and therefore consuming minimum CPU due
to GC activity:

 

bool ReceiveAsync(SocketAsyncEventArgs e) and SocketAsyncEventArgs exposes
the Completed event for notification of the operation. 

 

This allows one to pool SocketAsyncEventArgs, those eliminating the
temporary object creations. It doesn't really matter how it's done. I just 

brought the example since it already exists in another framework. The main
point is to eliminate the enormous amount of Future and any dependant 

objects creation for async send/recv when dealing with thousands of
connections on a server. 

 

2. Is NIO.2 on windows based on IOCP?

 

Thank you

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090116/57f49ef5/attachment.html 

From mthornton at optrak.co.uk  Sat Jan 17 01:39:40 2009
From: mthornton at optrak.co.uk (Mark Thornton)
Date: Sat, 17 Jan 2009 09:39:40 +0000
Subject: NIO.2 and GC activity
In-Reply-To: <000f01c97805$9473b3b0$bd5b1b10$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net>
Message-ID: <4971A75C.7030108@optrak.co.uk>

Leon Finker wrote:
>
> Hi,
>
> I would like to provide feedback on NIO.2 based on the specs, and what 
> I?ve been reading about the implementation.
>
> 1.
>
> I?m drawing from .Net experience here. We have encountered a 
> bottleneck with earlier .NET networking implementations,
>
> and I feel that NIO.2 is heading in the same direction. Please correct 
> me if I?m wrong.
>
> Proposed NIO.2:
>
> Future<Integer> read(ByteBuffer dst, ? CompletionHandler<Integer,? 
> super A> handler)
>
> etc?
>
> Earlier versions of .NET:
>
> IAsyncResult BeginReceive(byte[] buffer, ?, AsyncCallback callback, ?)
>
> The problem is that too many temporary Future/IAsyncResult objects are 
> created and thrown away without ability to pool them,
>
> which puts unnecessary stress on the GC.
>
How does the .NET garbage collector compare with those available now in 
Java? I have piles of old code that worked around inadequacies in older 
garbage collectors (e.g. stuff from the 1.1 era). Today I am frequently 
amazed at how good GC is at coping with huge amounts of garbage. So does 
Java need this kind of optimization?

Mark Thornton



From crodster2k at yahoo.com  Sat Jan 17 06:15:53 2009
From: crodster2k at yahoo.com (Rob Butler)
Date: Sat, 17 Jan 2009 06:15:53 -0800 (PST)
Subject: NIO.2 and GC activity
References: <000f01c97805$9473b3b0$bd5b1b10$@net>
	<4971A75C.7030108@optrak.co.uk>
Message-ID: <813805.28704.qm@web54004.mail.re2.yahoo.com>

Speaking as someone who builds big server applications, GC is usually our biggest problem.  Anything that can be done to reduce GC pressure is worth at least looking into.  

Also, considering that in most cases the future isn't used and is immediately thrown away why bother creating it in the first place.  Perhaps another way to solve the same problem is have two methods.

Future read(...)

void readNoFuture(...)

This would be backwards compatible with the existing API.  But I'd prefer

void read(...)
Future readFuture(...)

These won't reduce GC when you need to use Future, but in most cases where it isn't needed you save a useless object creation. (Perhaps thousands per second.)

Rob

----- Original Message ----
> From: Mark Thornton <mthornton at optrak.co.uk>
> To: nio-discuss at openjdk.java.net
> Sent: Saturday, January 17, 2009 4:39:40 AM
> Subject: Re: NIO.2 and GC activity
> 
> Leon Finker wrote:
> > 
> > Hi,
> > 
> > I would like to provide feedback on NIO.2 based on the specs, and what I?ve 
> been reading about the implementation.
> > 
> > 1.
> > 
> > I?m drawing from .Net experience here. We have encountered a bottleneck with 
> earlier .NET networking implementations,
> > 
> > and I feel that NIO.2 is heading in the same direction. Please correct me if 
> I?m wrong.
> > 
> > Proposed NIO.2:
> > 
> > Futureread(ByteBuffer dst, ? CompletionHandler
> handler)
> > 
> > etc?
> > 
> > Earlier versions of .NET:
> > 
> > IAsyncResult BeginReceive(byte[] buffer, ?, AsyncCallback callback, ?)
> > 
> > The problem is that too many temporary Future/IAsyncResult objects are created 
> and thrown away without ability to pool them,
> > 
> > which puts unnecessary stress on the GC.
> > 
> How does the .NET garbage collector compare with those available now in Java? I 
> have piles of old code that worked around inadequacies in older garbage 
> collectors (e.g. stuff from the 1.1 era). Today I am frequently amazed at how 
> good GC is at coping with huge amounts of garbage. So does Java need this kind 
> of optimization?
> 
> Mark Thornton



      


From leonfin at optonline.net  Sat Jan 17 20:10:57 2009
From: leonfin at optonline.net (Leon Finker)
Date: Sat, 17 Jan 2009 23:10:57 -0500
Subject: NIO.2 and GC activity
In-Reply-To: <4971A75C.7030108@optrak.co.uk>
References: <000f01c97805$9473b3b0$bd5b1b10$@net>
	<4971A75C.7030108@optrak.co.uk>
Message-ID: <000001c97922$c38ce6d0$4aa6b470$@net>

I'm not familiar with any performance comparison between .NET and JAVA GC. I
personally experienced the issue in earlier versions of .NET (and even
latest versions when using original async result based API) so I can relate
there.

Logically it would make sense not to create something (in very large
quantities) that will be thrown away. It will only be needed if the
framework forces it on the developer as the only way to get the result back.
Even short lived objects must be processed by GC and therefore CPU time
consumed for this work instead of same CPU time given to the application's
work. It's not uncommon to have 10,000 and much more per second socket
operations done on a server. That would mean that many Future objects will
be created. It's also possible for some of these objects to be promoted from
young to old generation if things fall behind (depending on how developers
use the model). Since it's still early(?) days for NIO.2, it should be
possible to avoid these extra objects by simply extending the API to
accommodate.

-----Original Message-----
From: nio-discuss-bounces at openjdk.java.net
[mailto:nio-discuss-bounces at openjdk.java.net] On Behalf Of Mark Thornton
Sent: Saturday, January 17, 2009 4:40 AM
To: nio-discuss at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
>
> Hi,
>
> I would like to provide feedback on NIO.2 based on the specs, and what 
> I've been reading about the implementation.
>
> 1.
>
> I'm drawing from .Net experience here. We have encountered a 
> bottleneck with earlier .NET networking implementations,
>
> and I feel that NIO.2 is heading in the same direction. Please correct 
> me if I'm wrong.
>
> Proposed NIO.2:
>
> Future<Integer> read(ByteBuffer dst, . CompletionHandler<Integer,? 
> super A> handler)
>
> etc.
>
> Earlier versions of .NET:
>
> IAsyncResult BeginReceive(byte[] buffer, ., AsyncCallback callback, .)
>
> The problem is that too many temporary Future/IAsyncResult objects are 
> created and thrown away without ability to pool them,
>
> which puts unnecessary stress on the GC.
>
How does the .NET garbage collector compare with those available now in 
Java? I have piles of old code that worked around inadequacies in older 
garbage collectors (e.g. stuff from the 1.1 era). Today I am frequently 
amazed at how good GC is at coping with huge amounts of garbage. So does 
Java need this kind of optimization?

Mark Thornton



From Alan.Bateman at Sun.COM  Sun Jan 18 05:10:41 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 18 Jan 2009 13:10:41 +0000
Subject: NIO.2 and GC activity
In-Reply-To: <000f01c97805$9473b3b0$bd5b1b10$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net>
Message-ID: <49732A51.2080107@sun.com>

Leon Finker wrote:
>
> Hi,
>
> I would like to provide feedback on NIO.2 based on the specs, and what 
> I?ve been reading about the implementation.
>
> :
>
> The main point is to eliminate the enormous amount of Future and any 
> dependant
>
> objects creation for async send/recv when dealing with thousands of 
> connections on a server.
>
Whether the return should be void, this, or Future<V> is a reasonable 
question to ask. The reason it is currently Future<V> is mostly to allow 
for cancellation. In any case, where I/O operations do not complete 
immediately then the context must be recorded so that it can be used 
later when the I/O completes. Even if the signature had a void type then 
some objects are required (timers for example). This has not been a 
problem to date. I don't have much experience with .NET to comment on 
the problems you observed but HotSpot and other modern VMs use 
generational collectors that are specifically designed to work best when 
the majority of objects are short lived. A possible concern of course 
for asynchronous I/O is the case where I/O operations do not complete 
quickly, and any objects allocated to the context for the I/O (timers 
for example) survive just long enough to get promoted into the tenured 
generation. There are quite a few people trying out this API and it 
would be good to get feedback and other performance results to see 
whether GC is a problem or not.

> 2. Is NIO.2 on windows based on IOCP?
>
The AsynchronousChannel implementations (except 
AsynchronousDatagramChannel) and the WatchService implementation in the 
file system API use IOCP.

-Alan.


From leonfin at optonline.net  Sun Jan 18 08:11:28 2009
From: leonfin at optonline.net (Leon Finker)
Date: Sun, 18 Jan 2009 11:11:28 -0500
Subject: NIO.2 and GC activity
In-Reply-To: <49732A51.2080107@sun.com>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
Message-ID: <000901c97987$6bafa9b0$430efd10$@net>

I agree it would be great if someone could provide feedback on GC activity
under stress with NIO2. 

As for the cancelation, please correct me if I'm wrong, but I personally
have not seen a single case when Cancel would be used by developers to
cancel the recv/send requests on a socket. Usually the assumption is that
closing the sockets cancels any pending requests. The asynchronous model
lends itself to the following usage: schedule one or a few operations and
get completion callback, then schedule more. If developers normally split up
the data in fixed 2k/4k buffers, what would it mean to cancel the request?
What if some of the buffers (that makes up a fully formed message) already
went out... (again please correct me if I'm wrong) but I think cancel for
sockets is a luxury that probably will not be used by developers.

As for the context information recording the operation, it is possible for
NIO2 API to take this context instead of returning new one each time. Then
developers can reuse same context information per operation per connection.
Thank you for the feedback!

-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Sunday, January 18, 2009 8:11 AM
To: Leon Finker
Cc: nio-discuss at openjdk.java.net
Subject: Re: NIO.2 and GC activity

Leon Finker wrote:
>
> Hi,
>
> I would like to provide feedback on NIO.2 based on the specs, and what 
> I've been reading about the implementation.
>
> :
>
> The main point is to eliminate the enormous amount of Future and any 
> dependant
>
> objects creation for async send/recv when dealing with thousands of 
> connections on a server.
>
Whether the return should be void, this, or Future<V> is a reasonable 
question to ask. The reason it is currently Future<V> is mostly to allow 
for cancellation. In any case, where I/O operations do not complete 
immediately then the context must be recorded so that it can be used 
later when the I/O completes. Even if the signature had a void type then 
some objects are required (timers for example). This has not been a 
problem to date. I don't have much experience with .NET to comment on 
the problems you observed but HotSpot and other modern VMs use 
generational collectors that are specifically designed to work best when 
the majority of objects are short lived. A possible concern of course 
for asynchronous I/O is the case where I/O operations do not complete 
quickly, and any objects allocated to the context for the I/O (timers 
for example) survive just long enough to get promoted into the tenured 
generation. There are quite a few people trying out this API and it 
would be good to get feedback and other performance results to see 
whether GC is a problem or not.

> 2. Is NIO.2 on windows based on IOCP?
>
The AsynchronousChannel implementations (except 
AsynchronousDatagramChannel) and the WatchService implementation in the 
file system API use IOCP.

-Alan.



From leonfin at optonline.net  Sun Jan 18 09:30:03 2009
From: leonfin at optonline.net (Leon Finker)
Date: Sun, 18 Jan 2009 12:30:03 -0500
Subject: NIO.2 and GC fragmentation
In-Reply-To: <000901c97987$6bafa9b0$430efd10$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
Message-ID: <000201c97992$65d47ba0$317d72e0$@net>

Hi,

While at it, I decided to comment on the other half of the problem that
existed in early .NET versions and sockets API: GC fragmentation. When
calling out to OS native API, the buffers that we pass in from .NET world
are "pinned" and used directly by the underlying OS native API. What this
means is that GC is unable to move these buffers around in order to compact
the heap until native API returns to managed world. Since on a server
thousands of buffers can be pinned while waiting for I/O to happen this
caused a great deal of heap fragmentation. 

Is it correct to assume that Java in a sense also "pins" the Java direct
buffers that it uses in JNI and those prevents GC from moving these buffers
and compacting the heap until native API returns? Thank you in advance for
feedback



From mthornton at optrak.co.uk  Sun Jan 18 09:49:35 2009
From: mthornton at optrak.co.uk (Mark Thornton)
Date: Sun, 18 Jan 2009 17:49:35 +0000
Subject: NIO.2 and GC fragmentation
In-Reply-To: <000201c97992$65d47ba0$317d72e0$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net>
	<49732A51.2080107@sun.com>	<000901c97987$6bafa9b0$430efd10$@net>
	<000201c97992$65d47ba0$317d72e0$@net>
Message-ID: <49736BAF.4020205@optrak.co.uk>

Leon Finker wrote:
> Hi,
>
> While at it, I decided to comment on the other half of the problem that
> existed in early .NET versions and sockets API: GC fragmentation. When
> calling out to OS native API, the buffers that we pass in from .NET world
> are "pinned" and used directly by the underlying OS native API. What this
> means is that GC is unable to move these buffers around in order to compact
> the heap until native API returns to managed world. Since on a server
> thousands of buffers can be pinned while waiting for I/O to happen this
> caused a great deal of heap fragmentation. 
>
> Is it correct to assume that Java in a sense also "pins" the Java direct
> buffers that it uses in JNI and those prevents GC from moving these buffers
> and compacting the heap until native API returns? Thank you in advance for
> feedback
>
>   
Java direct buffers aren't allocated from the Java heap (the buffer 
itself that is, not the object which wraps it)! They are allocated using 
the OS runtime and don't affect the garbage collector. The JVM has limit 
(default 64MB I seem to recall) of total direct buffer allocation. What 
can be a problem is disposing of them --- the memory is released by a 
cleanup thread after the object has become unreachable. However you can 
run short of memory for direct or memory mapped buffers, while still 
having plenty of free space in the Java heap.

Mark Thornton



From Alan.Bateman at Sun.COM  Sun Jan 18 09:50:42 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 18 Jan 2009 17:50:42 +0000
Subject: NIO.2 and GC activity
In-Reply-To: <000901c97987$6bafa9b0$430efd10$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
Message-ID: <49736BF2.8030909@sun.com>

Leon Finker wrote:
> :
>
> As for the cancelation, please correct me if I'm wrong, but I personally
> have not seen a single case when Cancel would be used by developers to
> cancel the recv/send requests on a socket. 
That is a fair comment.

> Usually the assumption is that
> closing the sockets cancels any pending requests. 
In this API then all outstanding I/O operations are required to fail 
with AsynchronousCloseException when the channel is closed.

> The asynchronous model
> lends itself to the following usage: schedule one or a few operations and
> get completion callback, then schedule more. If developers normally split up
> the data in fixed 2k/4k buffers, what would it mean to cancel the request?
> What if some of the buffers (that makes up a fully formed message) already
> went out... 
In the javadoc you will see that if cancellation cannot guarantee that 
bytes have not been transferred then it is required to put the channel 
into an error state that prevents further I/O operations from being 
initiated on that channel. This is specifically aimed at stream based 
connections where cancellation may leave the underlying connection or 
the channel is an inconsistent state.

>
> As for the context information recording the operation, it is possible for
> NIO2 API to take this context instead of returning new one each time. Then
> developers can reuse same context information per operation per connection.
>   
There are no plans to do anything like this at this time.

-Alan.


From Alan.Bateman at Sun.COM  Sun Jan 18 09:51:28 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 18 Jan 2009 17:51:28 +0000
Subject: NIO.2 and GC fragmentation
In-Reply-To: <000201c97992$65d47ba0$317d72e0$@net>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
	<000201c97992$65d47ba0$317d72e0$@net>
Message-ID: <49736C20.8020106@sun.com>

Leon Finker wrote:
> Hi,
>
> While at it, I decided to comment on the other half of the problem that
> existed in early .NET versions and sockets API: GC fragmentation. When
> calling out to OS native API, the buffers that we pass in from .NET world
> are "pinned" and used directly by the underlying OS native API. What this
> means is that GC is unable to move these buffers around in order to compact
> the heap until native API returns to managed world. Since on a server
> thousands of buffers can be pinned while waiting for I/O to happen this
> caused a great deal of heap fragmentation. 
>
> Is it correct to assume that Java in a sense also "pins" the Java direct
> buffers that it uses in JNI and those prevents GC from moving these buffers
> and compacting the heap until native API returns? Thank you in advance for
> feedback
>   
There is no pinning as direct buffer reside outside of the java heap.

-Alan.


From Alan.Bateman at Sun.COM  Sun Jan 18 09:53:54 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 18 Jan 2009 17:53:54 +0000
Subject: NIO.2 and GC fragmentation
In-Reply-To: <49736BAF.4020205@optrak.co.uk>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
	<000201c97992$65d47ba0$317d72e0$@net>
	<49736BAF.4020205@optrak.co.uk>
Message-ID: <49736CB2.9090705@sun.com>

Mark Thornton wrote:
> Java direct buffers aren't allocated from the Java heap (the buffer 
> itself that is, not the object which wraps it)! They are allocated 
> using the OS runtime and don't affect the garbage collector. The JVM 
> has limit (default 64MB I seem to recall) of total direct buffer 
> allocation. What can be a problem is disposing of them --- the memory 
> is released by a cleanup thread after the object has become 
> unreachable. However you can run short of memory for direct or memory 
> mapped buffers, while still having plenty of free space in the Java heap.
That's right although the maximum is tied to the maximum size of the 
java heap (and may be configured via the -XX:MaxDirectMemorySize option).

-Alan.


From tiago.curyz at gmail.com  Tue Jan 20 19:32:06 2009
From: tiago.curyz at gmail.com (Tiago Cury)
Date: Wed, 21 Jan 2009 01:32:06 -0200
Subject: OpenJDK + NIO.2 + Mac OS X
In-Reply-To: <49736CB2.9090705@sun.com>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
	<000201c97992$65d47ba0$317d72e0$@net>
	<49736BAF.4020205@optrak.co.uk> <49736CB2.9090705@sun.com>
Message-ID: <B146FBD8-3E88-45A6-A62E-5B3B24092BBA@gmail.com>

Hi,

I will build openJDK in my Mac OS X using the BSD port.
Where can I download the nio.2 patch for the openJDK source code?

regards,
Tiago



From Alan.Bateman at Sun.COM  Wed Jan 21 02:31:42 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 21 Jan 2009 10:31:42 +0000
Subject: OpenJDK + NIO.2 + Mac OS X
In-Reply-To: <B146FBD8-3E88-45A6-A62E-5B3B24092BBA@gmail.com>
References: <000f01c97805$9473b3b0$bd5b1b10$@net> <49732A51.2080107@sun.com>
	<000901c97987$6bafa9b0$430efd10$@net>
	<000201c97992$65d47ba0$317d72e0$@net>
	<49736BAF.4020205@optrak.co.uk> <49736CB2.9090705@sun.com>
	<B146FBD8-3E88-45A6-A62E-5B3B24092BBA@gmail.com>
Message-ID: <4976F98E.2030705@sun.com>

Tiago Cury wrote:
> Hi,
>
> I will build openJDK in my Mac OS X using the BSD port.
> Where can I download the nio.2 patch for the openJDK source code?
>
> regards,
> Tiago
>
The code is in a mercurial forest [1]. You will probably just want the 
jdk repository. Note that this is a complete jdk7 forest rather than a 
patch (it currently has all changes to jdk7-b42). I haven't been 
tracking the BSD port but if the port is managed as patches then it 
might be easier to apply the patches to a clone of the nio/nio forest 
rather than the other way around. If you really need a patch file then 
let me know and I can probably conjure it up. I'm not aware of anyone 
attempting to port this to BSD yet. It will be non-trivial. It might be 
best to bring follow-up questions to nio-dev as there are folks on 
nio-discuss that have asked not to be exposed to code/implementation 
discussion.

-Alan.

[1] http://hg.openjdk.java.net/nio/nio







From per at bothner.com  Mon Jan 26 16:07:39 2009
From: per at bothner.com (Per Bothner)
Date: Mon, 26 Jan 2009 16:07:39 -0800
Subject: support for URL/URI Paths?
Message-ID: <497E504B.2060305@bothner.com>

For Kawa I implmented a Path class to abstract out the
differences between java.io.File, java.net.URL and java.net.URI,
and provide a common clean API for them:
http://www.gnu.org/software/kawa/api/gnu/text/Path.html

Others have done the same - both KDE and Gnome have a "virtual
file" abstraction, based on URLs.

It seems like java.nio.file.Path provides much of the needed
functionality, but it seems aimed mostly at traditional files.
It would be really nice if there were a way to create a Path
from an arbitrary URL,without first having to create and
register a FileSystem.  Lots of the hooks are there, but it
really would be nice if the functionality was provided.

Of course a URL in general doesn't support all the operations
one might expect from a File - for example you can seek it,
or list the entries in a directory.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/


From Alan.Bateman at Sun.COM  Tue Jan 27 06:42:41 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Tue, 27 Jan 2009 14:42:41 +0000
Subject: support for URL/URI Paths?
In-Reply-To: <497E504B.2060305@bothner.com>
References: <497E504B.2060305@bothner.com>
Message-ID: <497F1D61.90308@sun.com>

Per Bothner wrote:
> For Kawa I implmented a Path class to abstract out the
> differences between java.io.File, java.net.URL and java.net.URI,
> and provide a common clean API for them:
> http://www.gnu.org/software/kawa/api/gnu/text/Path.html
>
> Others have done the same - both KDE and Gnome have a "virtual
> file" abstraction, based on URLs.
>
> It seems like java.nio.file.Path provides much of the needed
> functionality, but it seems aimed mostly at traditional files.
> It would be really nice if there were a way to create a Path
> from an arbitrary URL,without first having to create and
> register a FileSystem.  Lots of the hooks are there, but it
> really would be nice if the functionality was provided.
>
> Of course a URL in general doesn't support all the operations
> one might expect from a File - for example you can seek it,
> or list the entries in a directory.
Yes, the API is focused on access to the file system and so is a bit 
lower level and less abstract than accessing a resource via a URL. The 
provider mechanism does allow a Path to be created from a URI but only 
if there is provider available that supports the URI scheme (the 
FileSystem could be created transparently by the provider). It's not too 
unlike requiring a stream protocol handler be available to access a 
resource via java.net.URL. It shouldn't be too difficult to create a 
generic provider that uses a stream protocol handler. It would have 
limitations but may indeed be useful to have.

-Alan.