From alexdmiller at yahoo.com  Mon Oct  6 05:24:00 2008
From: alexdmiller at yahoo.com (Alex Miller)
Date: Mon, 6 Oct 2008 05:24:00 -0700 (PDT)
Subject: What does Path.iterator() iterate over?
Message-ID: <286715.37362.qm@web32105.mail.mud.yahoo.com>

I notice Path implements Iterable<Path>.  What does Path.iterator() iterate over?  

The two possibilities I thought of were:
1) The hierarchical Paths that make up the Path
2) The contents of the Path if Path is a directory

The javadoc is absent for this method so maybe if that was added, it could spell it out.


Thanks,
Alex Miller


From Alan.Bateman at Sun.COM  Mon Oct  6 06:10:37 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 06 Oct 2008 14:10:37 +0100
Subject: What does Path.iterator() iterate over?
In-Reply-To: <286715.37362.qm@web32105.mail.mud.yahoo.com>
References: <286715.37362.qm@web32105.mail.mud.yahoo.com>
Message-ID: <48EA0E4D.1080901@sun.com>

Alex Miller wrote:
> I notice Path implements Iterable<Path>.  What does Path.iterator() iterate over?  
>
> The two possibilities I thought of were:
> 1) The hierarchical Paths that make up the Path
> 2) The contents of the Path if Path is a directory
>
> The javadoc is absent for this method so maybe if that was added, it could spell it out.
>
>   
It is indeed missing - thanks! It returns an iterator over the name 
elements of the Path. I'll make sure this is fixed for the next build.

-Alan.



From crodster2k at yahoo.com  Mon Oct  6 06:24:19 2008
From: crodster2k at yahoo.com (Rob Butler)
Date: Mon, 6 Oct 2008 06:24:19 -0700 (PDT)
Subject: What does Path.iterator() iterate over?
Message-ID: <690220.78214.qm@web54005.mail.re2.yahoo.com>

Please also indicate which order elements are iterated in.  I.E. from start to end of path (left to right) or from end to start (right to left, or bottom up).

Thanks
Rob



----- Original Message ----
> From: Alan Bateman <Alan.Bateman at Sun.COM>
> To: Alex Miller <alexdmiller at yahoo.com>
> Cc: nio-discuss at openjdk.java.net
> Sent: Monday, October 6, 2008 9:10:37 AM
> Subject: Re: What does Path.iterator() iterate over?
> 
> Alex Miller wrote:
> > I notice Path implements Iterable.  What does Path.iterator() iterate 
> over?  
> >
> > The two possibilities I thought of were:
> > 1) The hierarchical Paths that make up the Path
> > 2) The contents of the Path if Path is a directory
> >
> > The javadoc is absent for this method so maybe if that was added, it could 
> spell it out.
> >
> >  
> It is indeed missing - thanks! It returns an iterator over the name 
> elements of the Path. I'll make sure this is fixed for the next build.
> 
> -Alan.



      


From elharo at metalab.unc.edu  Mon Oct  6 06:43:39 2008
From: elharo at metalab.unc.edu (Elliotte Harold)
Date: Mon, 06 Oct 2008 06:43:39 -0700
Subject: Eliminate ByteBuffers
Message-ID: <48EA160B.7080504@metalab.unc.edu>

Well, not everywhere. :-) However I do wonder about the use of 
ByteBuffers in what amount to maps such as NamedAttributeView.

int write(String name, ByteBuffer src) throws IOException

Why not just simple getAttribute and setAttribute methods? We have them but

Object getAttribute(String attribute)
                     throws IOException

     Reads the value of an attribute.

     In this release, this method may not be used to read the value of a 
named attribute. Consequently this method will return null.

and

NamedAttributeView setAttribute(String attribute,
                                 Object value)
                                 throws IOException

     Writes the value of an named attribute from a buffer.

     The value parameter is a ByteBuffer and this method writes the 
value of the attribute from the buffer as if by invoking the write method.

This is so weird I'm not sure where to start. The object passed to 
setAttribute is always a ByteBuffer, but it's declared as an Object? 
Why? getAttribute always returns null?

This is improving, but it's still very strange and hard to follow.

I think named attributes need to be reduced to a simple String name and 
an Object or String (probably Object) value. ByteBuffers simply should 
not be in the picture here. I guess you have ByteBuffers on the brain 
because of all the other work you're doing with them, but they're  not a 
common or comfortable API for this sort of work. Nor are they necessary. 
  I think if you treat the NamedAttributeView as a map, it will be much 
simpler, cleaner, and more effective.


-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA


From mthornton at optrak.co.uk  Mon Oct  6 06:48:50 2008
From: mthornton at optrak.co.uk (Mark Thornton)
Date: Mon, 06 Oct 2008 14:48:50 +0100
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA160B.7080504@metalab.unc.edu>
References: <48EA160B.7080504@metalab.unc.edu>
Message-ID: <48EA1742.4080005@optrak.co.uk>

Elliotte Harold wrote:
>
>
> I think named attributes need to be reduced to a simple String name 
> and an Object or String (probably Object) value. ByteBuffers simply 
> should not be in the picture here. I guess you have ByteBuffers on the 
> brain because of all the other work you're doing with them, but 
> they're  not a common or comfortable API for this sort of work. Nor 
> are they necessary.  I think if you treat the NamedAttributeView as a 
> map, it will be much simpler, cleaner, and more effective.
>
>
What sort of data do you expect to find in named attributes? NTFS 
alternate data streams could contain anything and would usually be binary.

Mark Thornton




From Alan.Bateman at Sun.COM  Mon Oct  6 07:50:12 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 06 Oct 2008 15:50:12 +0100
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA160B.7080504@metalab.unc.edu>
References: <48EA160B.7080504@metalab.unc.edu>
Message-ID: <48EA25A4.1060203@sun.com>

Elliotte Harold wrote:
> Well, not everywhere. :-) However I do wonder about the use of 
> ByteBuffers in what amount to maps such as NamedAttributeView.
>
> :
>
> I think named attributes need to be reduced to a simple String name 
> and an Object or String (probably Object) value. ByteBuffers simply 
> should not be in the picture here. I guess you have ByteBuffers on the 
> brain because of all the other work you're doing with them, but 
> they're  not a common or comfortable API for this sort of work. Nor 
> are they necessary.  I think if you treat the NamedAttributeView as a 
> map, it will be much simpler, cleaner, and more effective.
>
>
I suspect we have a mis-understanding here. The NamedAttributeView 
provides a view of a file's "named attributes" which are typically used 
to store meta data that is not meaningful to the file system -- ie: this 
is not your usual file size, time stamps, file permissions, etc. This is 
application defined meta-data that can only be treated as binary blobs 
by the file system and API. The blobs are named and the read/write 
methods are used for transferring the bits (hence the buffers). The 
terminology varies by operating system and file system but think 
extended attributes or named streams.  In our implementation it maps to 
NTFS Alternative Data Streams, ext3 extended attributes, or zfs extended 
attributes. In the samples directory you will find the Xdd sample that 
may be useful to try.

As regards the javadoc you cited - the FileAttributeViews provide for 
both typesafe and "dynamic access" to the attributes that they support. 
For dynamic access, which I think is what you are looking for, you use 
the Attributes class and the getAttribute/setAttribute/readAttributes 
methods to read or update the attributes you require. The readAttributes 
methods returns a map of the requested attributes.

I hope this helps,

-Alan.




From elharo at metalab.unc.edu  Mon Oct  6 08:07:14 2008
From: elharo at metalab.unc.edu (Elliotte Harold)
Date: Mon, 06 Oct 2008 08:07:14 -0700
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA1742.4080005@optrak.co.uk>
References: <48EA160B.7080504@metalab.unc.edu> <48EA1742.4080005@optrak.co.uk>
Message-ID: <48EA29A2.4000300@metalab.unc.edu>

Mark Thornton wrote:

> What sort of data do you expect to find in named attributes? NTFS 
> alternate data streams could contain anything and would usually be binary.

An object would be preferable. Allow file system specific 
implementations to return whatever type make most sense for them.

Less optimally make it a byte array.

But whatever you do, ByteBuffer does not belong here. Most use cases for 
working with file system attributes will not need or want to use 
ByteBuffers. This coupling needs to be broken.

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA


From elharo at metalab.unc.edu  Mon Oct  6 08:15:02 2008
From: elharo at metalab.unc.edu (Elliotte Harold)
Date: Mon, 06 Oct 2008 08:15:02 -0700
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA25A4.1060203@sun.com>
References: <48EA160B.7080504@metalab.unc.edu> <48EA25A4.1060203@sun.com>
Message-ID: <48EA2B76.7080501@metalab.unc.edu>

Alan Bateman wrote:

> I suspect we have a mis-understanding here. The NamedAttributeView 
> provides a view of a file's "named attributes" which are typically used 
> to store meta data that is not meaningful to the file system -- ie: this 
> is not your usual file size, time stamps, file permissions, etc. This is 
> application defined meta-data that can only be treated as binary blobs 
> by the file system and API. The blobs are named and the read/write 
> methods are used for transferring the bits (hence the buffers). The 
> terminology varies by operating system and file system but think 
> extended attributes or named streams.  In our implementation it maps to 
> NTFS Alternative Data Streams, ext3 extended attributes, or zfs extended 
> attributes. In the samples directory you will find the Xdd sample that 
> may be useful to try.
> 

I do understand, but I still don't think ByteBuffers have any business 
in this API. I do not believe client programmers want to transfer binary 
blobs of metadata using ByteBuffers. I am not convinced these are quite 
the opaque blobs you prefer; but if opaque blobs they must be, then they 
should be byte arrays, not byte buffers.


> As regards the javadoc you cited - the FileAttributeViews provide for 
> both typesafe and "dynamic access" to the attributes that they support. 
> For dynamic access, which I think is what you are looking for, you use 
> the Attributes class and the getAttribute/setAttribute/readAttributes 
> methods to read or update the attributes you require. The readAttributes 
> methods returns a map of the requested attributes.
> 

Methods that always return null (getAttribute), or an empty Map 
(readAttributes) and methods that take only a subset of the declared 
argument type (setAttribute), indicate a failure of inheritance and 
polymorphism. The design simply doesn't work. The subinterface is 
violating the contract of the superinterface. NIO.2 needs to either make 
these methods work, or reorganize the inheritance hierarchy so that 
NamedAttributeView does not extend AttributeView.

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA


From Alan.Bateman at Sun.COM  Mon Oct  6 09:01:52 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 06 Oct 2008 17:01:52 +0100
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA2B76.7080501@metalab.unc.edu>
References: <48EA160B.7080504@metalab.unc.edu> <48EA25A4.1060203@sun.com>
	<48EA2B76.7080501@metalab.unc.edu>
Message-ID: <48EA3670.4040707@sun.com>

Elliotte Harold wrote:
> :
> I do understand, but I still don't think ByteBuffers have any business 
> in this API. I do not believe client programmers want to transfer 
> binary blobs of metadata using ByteBuffers. I am not convinced these 
> are quite the opaque blobs you prefer; but if opaque blobs they must 
> be, then they should be byte arrays, not byte buffers.
It is bytes because we can't interpret the value.

>
> :
> Methods that always return null (getAttribute), or an empty Map 
> (readAttributes) and methods that take only a subset of the declared 
> argument type (setAttribute), indicate a failure of inheritance and 
> polymorphism. The design simply doesn't work. The subinterface is 
> violating the contract of the superinterface. NIO.2 needs to either 
> make these methods work, or reorganize the inheritance hierarchy so 
> that NamedAttributeView does not extend AttributeView.
The getAttribute/readAttributes is currently a temporary restriction 
because of concerns with huge values. I'll see if I can resolve this for 
the next build. The setAttribute method doesn't have a problem and 
throws CCE as required when you invoke it with a type that it does not 
understand (a buffer in this case). This is no different that say trying 
to set the file owner to something that isn't a UserPrincipal for 
example. Usually you will use the setOwner method and you will get type 
checking at compile method but if invoke setAttribute and try to set the 
"owner" to some arbitrary object then it will fail at runtime.

-Alan.



From kpauls at acm.org  Mon Oct  6 11:40:50 2008
From: kpauls at acm.org (Outside - Karl's ACM)
Date: Mon, 6 Oct 2008 11:40:50 -0700
Subject: Eliminate ByteBuffers
In-Reply-To: <48EA29A2.4000300@metalab.unc.edu>
References: <48EA160B.7080504@metalab.unc.edu>
	<48EA1742.4080005@optrak.co.uk> <48EA29A2.4000300@metalab.unc.edu>
Message-ID: <A7CC499CF05307438D4B8EC3A159FA0C01CF5963A3@postoffice.corp.trigeo.com>

If it's possible to port the new APIs in question to J2ME or other limited Java profiles then I would see the point of an interface which replaced all "ByteBuffer src" parameters with "byte[] src, int off, int len". Please do not allocate byte arrays inside these methods so that static-memory systems do not have to avoid them.

I think the ability to pass straight Object types back and forth opens up the ability for the file system implementers to create exact attribute to object mappings. I do not see that solely as an advantage, but also as a possible dependency on platform-specific libraries.


> -----Original Message-----
> From: nio-discuss-bounces at openjdk.java.net [mailto:nio-discuss-
> bounces at openjdk.java.net] On Behalf Of Elliotte Harold
> Sent: Monday, October 06, 2008 8:07 AM
> Subject: Re: Eliminate ByteBuffers
>
> Mark Thornton wrote:
>
> > What sort of data do you expect to find in named attributes? NTFS
> > alternate data streams could contain anything and would usually be
> binary.
>
> An object would be preferable. Allow file system specific
> implementations to return whatever type make most sense for them.
>
> Less optimally make it a byte array.


From Alan.Bateman at Sun.COM  Mon Oct  6 13:27:20 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 06 Oct 2008 21:27:20 +0100
Subject: Eliminate ByteBuffers
In-Reply-To: <A7CC499CF05307438D4B8EC3A159FA0C01CF5963A3@postoffice.corp.trigeo.com>
References: <48EA160B.7080504@metalab.unc.edu> <48EA1742.4080005@optrak.co.uk>
	<48EA29A2.4000300@metalab.unc.edu>
	<A7CC499CF05307438D4B8EC3A159FA0C01CF5963A3@postoffice.corp.trigeo.com>
Message-ID: <48EA74A8.6090302@sun.com>

Outside - Karl's ACM wrote:
> If it's possible to port the new APIs in question to J2ME or other limited Java profiles then I would see the point of an interface which replaced all "ByteBuffer src" parameters with "byte[] src, int off, int len". Please do not allocate byte arrays inside these methods so that static-memory systems do not have to avoid them.
>
> I think the ability to pass straight Object types back and forth opens up the ability for the file system implementers to create exact attribute to object mappings. I do not see that solely as an advantage, but also as a possible dependency on platform-specific libraries.
>   
It is impossible to predict the areas of Java SE that might go into 
future J2ME profiles. Buffers are core to NIO and are used in the 
channels and charset APIs. Aside from channel I/O, the only usage in the 
file system API is in NamedAttributeView for reading/writing the bits. 
NamedAttributeView is for somewhat niche requirements but there's no 
harm looking at it again to see if byte[] would be easier (if you want 
byte[] now then use ByteBuffer.wrap or else copy to/from the buffer).

I'm not sure that I understood your second paragraph. When developing a 
file system provider, the implementer defines the mapping between Java 
representation and whatever file attributes the file system supports.

-Alan.


From hjort.dennis at gmail.com  Fri Oct 31 13:57:57 2008
From: hjort.dennis at gmail.com (Dennis Hjort)
Date: Fri, 31 Oct 2008 21:57:57 +0100
Subject: Java API for SCTP
Message-ID: <514a207b0810311357u7f81ff9es24b1c842be5025e3@mail.gmail.com>

Hi,

I am writing to find out the current status on the support for SCTP in java.
When I googled around, I found the posts made by Christopher Hegarty [1]
which is a pretty recent post, and wanted to express my interest in what I
hope is a open support for SCTP, as the project I'm currently working in
today has to rely on the Java SCTP API offered by Ivan Skytte J?rgensen [2],
which is a JNI package which does not have all functionality that the SCTP
socket draft specifies.

Our project (which is a telecom project) needs the SCTP support to be able
to communicat with the system under test, and a native Java support would be
great. We would like to have non-blocking SCTP instead of our current
implementation which has to support the blocking SCTP read/write the JNI
library implements, which creates the need for a pretty advanced handling.

I see that the draft for SCTP currently lies in com.sun.nio.sctp [3], so it
has not reached the general audience yet, and I hope I can show that there
exists interest for it.

Also, please send contact me if I can help in any way for it to get into the
JDK release 7.

[1]
http://mail.openjdk.java.net/pipermail/nio-discuss/2008-September/000083.html
[2] http://i1.dk/JavaSCTP/
[3] http://openjdk.java.net/projects/nio/sctp/javadoc/
-- 
Dennis Hjort
http://hack.org/dennis/
Home machine (IPv6 only, when in *nix mode): http://fc.hack.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20081031/30ace542/attachment.html