Skip to main content

Please

Posted by editor on July 3, 2008 at 6:11 AM PDT


Can we have a competent filesystem API in Java 7?

Take a look at Bug 4032604: Copy method in class java.io.File, filed in February, 1997. It's pretty self-explanatory: provide a one-line method call to copy files. Now look at the typically smug and dismissive evaluation: it's easy enough to do yourself (that's right, Sun wants everyone writing the same boiler-plate file copy implementation over and over again), and it's behavior would vary across platform (so does the DIY version: based on the host OS, the copied file loses ownership and permissions metadata, TYPE/CREA and resource fork on the classic Mac OS, etc.).

Not for nothing have a lot of us hated -- I mean really hated -- java.io.File over the years. Scroll down to the comments and notice something interesting. The first comment, filed in 1997 and supporting the bug, is from well-known Java author Elliotte Rusty Harold. The second, written in 1999, is from me.

So it's a fascinating coincidence that Elliotte and I should happen to come together on this point nearly a decade later. As part of his continuing series, The Open Road, which looks at features tracking for likely inclusion in Java 7, he's investigating JSR 203, which could drag Java's filesystem support into the modern era:

However, finally in Java 7, it looks like there's at least a 50-50 chance we'll get a filesystem API that's more powerful than the clunky old java.io.File that was thrown together twelve years ago to push Java 1.0 out the door. Sun, IBM, Oracle, Intel, HP, Google, NTT, and Doug Lea are working on JSR 203 to create "More New I/O APIs for the Java Platform ('NIO.2')". Don't hold your breath yet, but do keep your fingers crossed. Maybe, just maybe, we'll finally be able to copy files in Java 7.

Will we get a copy method? Will we like it? Will the editor's "planet-melting hatred of java.io.File" be allayed? Find out in our Feature Article,
The Open Road: java.nio.file.


In Java Today,
an article on JavaLobby makes the case for migrating to GlassFish. In Tomcat Today, GlassFish Tomorrow?, Alexis MP writes "GlassFish has made a lot of efforts to appeal to developers. Its a single, small download of about 60MB, has auto-deploy capabilities, starts pretty fast for an application server with GlassFish v2 (probably the best full-blown application server startup time). To be fair to Tomcat or Jetty, they are still perceived by many as lighter- weight and faster to start. GlassFish v3 is all about being modular (based on OSGi), extensible and very developer friendly. The recently released TP2 (Tech Preview 2) starts in less than a second, starts/ stops containers and resources as needed and provides support for scripting technologies such as Rails, Groovy, PHP and more."

From The Aquarium: "Ed [Bratt] has
announced
the second Release Candidate for OpenMQ 4.2, now available at the
Downloads Page.
Features include:
• Performance Improvements,
• Multiple Destinations for a Publisher or Subscriber,
• Schema Validation of XML Payload Messages,
• C-API Support for Distributed Transactions,
• Support for MySQL Database,
• Installer Support for Sun Connection Registration. Full details at
Release Notes and 4.2 Highlights."

Time to really master java.util.concurrent? Intel Principal Engineer Anwar Ghuloum has posted some Unwelcome Advice for many developers: massively multi-core CPUs are the future, and developers need to adjust their thinking accordingly. "Ultimately, the advice I'll offer is that these developers should start thinking about tens, hundreds, and thousands of cores now in their algorithmic development and deployment pipeline."


In today's Forums,
mikeazzi reports some problems with JNLP in

Re: Launching Applets Through JNLP Link Has Got to Be Easier Than This.
"I see two problems here. First is the lousy, and ambiguous error messages from the new plugin. I really wish somebody would do something about them before FCS release. And quite honestly I really don't care whether these confusing error messages make sense technically speaking or not. This is not a philosophical exercise here, this is all about common sense and what makes the developer life a little easier. Second, I don't know whether you are using the netbeans JavaFX plugin to generate your.jnlp file or not. But that's where the second problem is. The netbeans jnlp generator produces invalid xml for the .jnlp that it generates."

rogyeu announces a chance to get your 6u10 questions answere in
Ask the Experts: Java SE 6 Update 10 Beta (July 7-11).
"Java SE 6 Update 10, currently available as a beta release, introduces many new features and enhancements that dramatically improve the developer and user experience. Some of the significant improvements in Java SE 6 result in faster and easier deployment of Java applications and applets, better performance, and an improved look and feel. Got a question about Java SE 6 Update 10? Post it from July 7 through July 11 on the Ask the Experts page and get answers from three key members of Sun's Java SE Platform team: Danny Coward, Ken Russell, and Richard Bair."

fatbatman posts
My feedback on Update 10 and wishlist for the future.
"Here is a list of my thoughts/questions/feedback on Java6u10 that I compiled for a scheduled conference call with Sun that didn't happen. Instead of wasting the notes I thought I'd post them here. All comments welcome."

cowwoc questions the real-world practicality of applets in
Re: Notewothy: Flash content now indexable.
"It would be really cool if we *could* do that though, because silly little things (like drop-down shadows) take forever to implement in HTML and almost no time in Java. The remaining question is why you'd want to consider implementing this in Java versus Flash. In my case the answer would be "because I know Java better than Flash" but this is a rather poor answer at this time. Yes, Applets run a lot faster than Flash once they load up but this doesn't matter for most usages."


Arun Gupta continues his tips series with a look at SQLite 3 in today's Weblogs. In TOTD #37: SQLite3 with Ruby-on-Rails on GlassFish Gem, he writes,
"the default database for Rails 2.0.x application is SQLite3. This database is bundled with Mac OSX Leopard and so makes it really easy to get started with Ruby-on-Rails. But it requires couple of additional steps if you are using JRuby."

Next, Jean-Francois Arcand has some advice for
Getting started with Comet and GlassFish v2.
"The Grizzly users lists is bombarded with questions about how to start with Comet and GlassFish v2. Here is a quick explanation..."


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.


Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

Can we have a competent filesystem API in Java 7?