Re: network tests
Joe Darcy wrote: Greetings. Recently Mark Wielaard started an effort to run the regression tests on OpenJDK builds and publish the results (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-May/001921.html). Certain tests in the nio and networking area assume Sun-internal hosts like javaweb are available; the shell test test/java/net/InetAddress/ptr/lookup.sh has a string for javaweb and test/java/nio/channels/TestUtil.java has the following constants used by other tests: // Test hosts used by the channels tests - change these when // executing in a different network. public static final String HOST = "javaweb.sfbay.sun.com"; public static final String REFUSING_HOST = "jano.sfbay.sun.com"; public static final String FAR_HOST = "theclub.ireland.sun.com"; public static final String UNRESOLVABLE_HOST = "blah-blah.blah-blah.blah"; Mark observed these three hosts are needed: With daytime and echo available. The only wrinkle is that some tests expect to be able to use quick timeouts from HOST, but to need long timeouts from FAR_HOST. I think we could provide something public for this. But I might have missed some tests that need other services. Do you have a full overview? (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-May/001972.html) First, is this all the networking configuration information that is used in the regression tests? For the tests in the java/nio and sun/nio tree then the dependencies are centralized in TestUtil.java. When we moved these tests from closed->open we did talk about moving this configuration into a properties/configuration file but figured there wasn't much difference between editing a config file vs. a source file. For the classic networking, the dependencies are scattered. I believe some of the tests weren't moved from closed->open for this reason. Some of the tests uses an embedded HTTP or FTP server but there are others that depend on DNS, proxy, etc. Michael or Jessie may have more to say on this. BTW: I briefly scanned the summary and most of the java/nio failures appear to be *HOST related. Now that folks are running these tests outside Sun it is time to own up to a few intermittent/timing related failures with 4 or 5 of these tests. I've been meaning to fix these test issues for a while but I haven't had the cycles. I'll dig up my notes on these. One other thing - I notice test/java/nio/channels/DatagramChannel/NotBound.java on the list - that test is failing because it is missing the public modifier. The test is bogus anyway so it might be best to just remove this test from jdk6 and open6. For jdk7/OpenJDK I have spec clarification in the works to fix the spec hole and as part of that work the test will be replaced (see 6621689). Second, it would be helpful is this host information could be configured without changing the sources of the test each time. I've spoken briefly to Jon about ways this kind of information can be passed into a jtreg run. Environment variables can be used, as can system properties. A system property could also be used to specify a file from which the information was read. With a bit of jtreg hacking, it is feasible portions of the jtharness interview procedure could be exposed to configure information that way too. I would be concerned with a solution that requires environment variables or jtreg requiring configuration from somewhere other than the test suite. At least in Sun (sorry for being selfish), these tests are run by various teams on hundreds of machines. I don't think we'd want to require the javatest interview be run or have .jti files stored in various places with configuration information that will quickly go stale. If you mean that the configuration can be overridden via some input to jtreg that might be okay but would require the distributions and others to maintain that configuration. Anyway, I'm interested to hear the outcome of the discussion. -Alan.
A proposal for a FTP client API
Hello, I have posted an entry in my blog about the current status of the FTP client API. It contains a quick description of the project as well as a link to the current draft of the API. So if you're interested in that topic go take a look at http://blogs.sun.com/jcc/ As mentioned in the post, feedback is very strongly encouraged.
Re: A proposal for a FTP client API
boolean login(String user, String password) boolean login(String user, String password, String account) Normally we use char[] to represent a password so that it can zeroed out afterward. List listFiles(String path) If a FTP directory is huge, listing the files will cost a very long time. I'll be very glad to see this method returns immediately and fetching the information while user iterate through the output. Is this implementation possible with this API? Thanks Max On May 23, 2008, at 11:20 PM, Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. It contains a quick description of the project as well as a link to the current draft of the API. So if you're interested in that topic go take a look at http://blogs.sun.com/jcc/ As mentioned in the post, feedback is very strongly encouraged.
Re: A proposal for a FTP client API
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. It contains a quick description of the project as well as a link to the current draft of the API. So if you're interested in that topic go take a look at http://blogs.sun.com/jcc/ As mentioned in the post, feedback is very strongly encouraged. This is going into the java.net package - is there/will there be a JSR for this effort? - DML
Re: A proposal for a FTP client API
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. [..] As mentioned in the post, feedback is very strongly encouraged. Some technical feedback: 1) FtpClient should implement java.io.Closeable in my opinion. 2) I also feel that listFiles should stream output. How about returning Iterable instead? It could return a one-time-use Iterator, allowing users to use the extended for-loop syntax if they wish. 3) If this is going into JDK 7 - is there any way to reuse any of the FileSystem stuff from JSR-203? I'm thinking specifically of the way they handle file permissions with FileAttributeViews and so forth, but perhaps there's things which can be reused as well. Guess that's all I've got for now. - DML
Re: A proposal for a FTP client API
Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. It contains a quick description of the project as well as a link to the current draft of the API. So if you're interested in that topic go take a look at http://blogs.sun.com/jcc/ As mentioned in the post, feedback is very strongly encouraged. I'm interested in reviewing this. From an initial glance this is ftp and ftps - are you also thinking about sftp? Some initial comments from a first pass: It would be better to use a static factory method rather than public constructors. For one thing, there are a slew of ftp clients about and you'll likely get requests for a provider interface so that alternative implementations can be used. The client has state (not connected, connected, logged, etc.) and you might want to introduce a few specific exceptions for this. For example, what does connect throw if you are already connected, what do the other methods throw when you aren't connected, etc. In current draft there are quite a few methods that return a boolean and throw IOException. It's not clear to me what what failure means - do these methods return false or do they throw an I/O exception? How is this used with the getLastReplyCode method or should the exception have a method to return the reply code? The listFiles returns a List and isn't going to scale with large directories (you'll have to fetch the entire directory from the server for this method to return). It would be better to return something that implements Iterable and Closeable. I'm curious about FtpFile. My memory of the ftp protocol is hazy but I thought that commands such as LIST or NLIST didn't specify the format of the file attributes. There was a IEFT WG working on defining these but I don't see this in the references. Do you have a pointer to that? I see that the getModificationTime returns a Date. Care to revise your statement sir :-) You've got a number of setter methods that return void. It might be nicer for them to return this so as to facilitate invocation chaining. Should the members of the TransferMode enum be in uppercase? Do you really need the ability to set/get the connect timeout and allow it be overridden by the connect method? That's it for a first pass. -Alan.
