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 reallyhated --
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.
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 v3is 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 atRelease 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."