DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Some More JSR 203 Examples

Some More JSR 203 Examples

Alex Miller user avatar by
Alex Miller
·
Oct. 28, 08 · Java Zone · Interview
Like (1)
Save
Tweet
9.01K Views

Join the DZone community and get the full member experience.

Join For Free

My examples for JSR 203 were focused on the basics but I was really just skimming the surface of a pretty large set of classes. I’ve had some follow up discussions with Alan Bateman, the spec lead for JSR 203, since my post this week and he called out a list of features that may also be of interest if you want to go deeper. It seemed like a great list so I’m reposting here with his permission:

  • Support for symbolic links. Believe or not, this has an implication for every method that accesses the file system.
  • Files#probeContentType to get the MIME type. This is integrated with the platform MIME database (GNOME, the registry, etc.).
  • The attribute package is a talk on its own but one useful thing to try out is creating a file with initial permissions (to avoid the window that otherwise arises when creating a file and immediately setting its permissions). There are lot of other security features in this API as well.
  • Some of the open options may be interesting. For example, the DELETE_ON_CLOSE option is going to be useful to some people.
  • A Path preserves the platform representation of the platform (for example on Linux or Unix this means bytes). Create files in a directory when under a different locale and you may find that you can’t access them with java.io.File. However, iterate over the directory with Path#newDirectoryStream and you should see that you can access the files (because the byte representation is preserved; in java.io.File it gets lost when converting the file name to a String).
  • For random access to files then it may be good to point out SeekableByteChannel. For concurrent access to files then AsynchronousFileChannel may be interesting (this is in the channels package but the factory for AsynchronousFileChannels is the FileSystemProvider).
  • One other thing that is probably worth pointing out is the File#toPath method. This allows you to get an object in the new API from existing code that is using java.io.File. For
    example, suppose you have code that does f.delete(). You can change this to f.toPath.delete() so that you get a reasonable exception when the delete fails.

I should also mention that the new file system API is actually only part of what’s covered in JSR 203. Additionally, there’s a completion of many of the APIs started in the prior incarnation of NIO, with full support for multicast, and support for asynchronous I/O on both sockets and files.

From http://tech.puredanger.com

File system

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Properly Format SQL Code
  • Datafaker: An Alternative to Using Production Data
  • Troubleshooting Memory Leaks With Heap Profilers
  • How to Determine if Microservices Architecture Is Right for Your Business

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo