Win a copy of Terraform in Action this week in the Cloud forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Legacy File Class - any excuse to use it besides laziness / letting sleeping legacy dogs lie?

 
Saloon Keeper
Posts: 1672
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am often surprised just how much material published in 2016 until even today still shows legacy File class usage exclusively, ignoring nio.2.

It is on the 819, and is out there in tons of tutorial material and hundreds of millions of lines of older code, so I am planning to continue learning/remembering the ins-and-outs of the legacy File class.

If I understand the Sybex 819 books correctly:

1. Using Path/Paths/Files yields better error reporting, works with SymLinks and remote file systems, and has richer functionality.
2. Using File class doesn't require people who learned Java in 2003 to learn anything new, and is handy in case you are writing Java 1.4 code for use somewhere that hasn't upgraded to Java 7 yet...

Is there ever a case besides laziness in learning or legacy compatibility with Java versions long out of support to stick with the File class?

It is not clear which parts of IOStreams are also considered legacy besides File itself.

I know "people didn't like nio much, and it is pretty much ignored, tho nio.2 is another story".

It gets a little confusing tho, because nio.2 isn't really in a separate namespace or package...

Of the following:
java.nio
Defines buffers, which are containers for data, and provides an overview of the other NIO packages.
java.nio.channels
Defines channels, which represent connections to entities that are capable of performing I/O operations, such as files and sockets; defines selectors, for multiplexed, non-blocking I/O operations.
java.nio.channels.spi
Service-provider classes for the java.nio.channels package.
java.nio.charset
Defines charsets, decoders, and encoders, for translating between bytes and Unicode characters.
java.nio.charset.spi
Service-provider classes for the java.nio.charset package.
java.nio.file
Defines interfaces and classes for the Java virtual machine to access files, file attributes, and file systems.
java.nio.file.attribute
Interfaces and classes providing access to file and file system attributes.
java.nio.file.spi
Service-provider classes for the java.nio.file package.


I infer from the allusions that nio.channels and nio.channels.spi are the stuff from "nio" that never caught on much and is outside the scope of the OCJP certifications, charset and file and file.attribute are very much part of modern Java best practices for IO and the .spi stuff is not relevant for "normal Java programmers" and should just be ignored by most.

Is that about right?

Also, except for the File class called out by name in the subject line, and the zoo of obscure, arcane Stream or Reader classes that hardly anyone used anyway, is there anything in common usage from java.io that should ideally not be used anymore (even tho it is)?  Right now, it seems to me the only part of java.io that should be much more ignored than it is would be File class itself?

Thanks, Y'all!
 
Marshal
Posts: 74392
335
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would say it is worth keeping File in legacy code but only on the basis that, “If it ain't broke, don't fix it.”
Remember you can introduce new errors by fixing something which “ain't broke”.
 
author & internet detective
Posts: 40847
829
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would argue that if NIO.2 can do something to not do it the I/O way. So if I'm reading a file, I'm using Files.lines() or Files.readAllLines() or Files.readString() rathe than a Reader.
 
Marshal
Posts: 26915
82
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Remember that laziness is a positive attribute for a programmer!

However: I went through the codebase for the application I use most and found that it had 30 instances of java.io.File. So I had a quick look at the first place that Eclipse showed me, and I was taken aback because it was used in the same line of code as java.nio.file.Path. So what was up with that? Why did I use java.io.File in this particular class? It didn't take long to find that my File came from a JFileChooser, whence the legacy aspect. In other words I had upgraded some of the code to java.nio versions but I was still stuck with legacy File.

I could improve things by taking the java.io.File that I get from the JFileChooser and immediately converting it to a java.nio.file.Path, thus restricting the legacy code as far as possible. Ring-fencing it as they say in Britain.

Other places where I used java.io.File are in programs which I haven't used for several years and I'm not going to use in the future. Programs to fix a specific issue. Those I don't usually bother to mess with unless there are errors or warnings which arise from upgrading to new Java versions.

Generally I try to bring my code up to current standards, e.g. by rewriting loops to use streams and functional programming, but not everybody has the luxury of being able to do that.
 
Campbell Ritchie
Marshal
Posts: 74392
335
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I get the impression that Swing components still use legacy code and haven't been updated properly. You are stuck with the legacy classes but might write ...myFileChooser.getSelectedFile().toPath()... or similar.
 
Sheriff
Posts: 22512
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:I get the impression that Swing components still use legacy code and haven't been updated properly.


You're very right about that. Apart from adding generic to some models and the UI components using them (e.g. JList), Swing hasn't had any noticeable change in years. I can remember reading somewhere that Oracle has basically given up on Swing. Their attempts to push JavaFX as follow-up have mostly failed, but there is still little to no effort in Swing these days.

JFileChooser can probably be wrapped by a to-be-created JPathChooser class. For files from the local file system you can easily use Path.toFile and File.toPath to bridge the gap; for other Path implementations you'd need some dummy File sub class that delegates all the hard work to Path. Fortunately File isn't final, and if I recall correctly all File creation is done by FileSystemView, so although it would be quite some work, it shouldn'y be impossible.
 
Jesse Silverman
Saloon Keeper
Posts: 1672
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I saw something similar very recently in a demo from 2018 or so where they were using Enumeration rather than Iterator.
I thought they were just being a dinosaur, but they were calling some API for working with .zip files from 1996 that predated Iterator and just used Enumeration, still.

I briefly looked and didn't see a way to do what they were doing with Iterator instead of Enumeration.  I didn't need to work with .zip files right now so I skipped the rest of the demo.

Looking here, I see that there was an adapter option starting in Java 9:
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Enumeration.html

But they were definitely using Java 8, and now that I think about it, the video might have first been recorded in 2016 or 2017 and posted later.

When you stray off the main Paths in Java, you get to meet a lot of legacy classes and interfaces you thought you might never see in new code, it seems.
 
Saloon Keeper
Posts: 13426
302
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general: Write all your APIs using the most modern types available to you. If you interface with legacy systems, perform conversions internally.

If you write a new public API that uses File instead of Path, or if you return null instead of Optional, I will curse you under my breath.
 
Jesse Silverman
Saloon Keeper
Posts: 1672
61
Eclipse IDE Postgres Database C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:In general: Write all your APIs using the most modern types available to you. If you interface with legacy systems, perform conversions internally.

If you write a new public API that uses File instead of Path, or if you return null instead of Optional, I will curse you under my breath.



I really feel that as huge as the WWW is, there is something somewhat unique and magical about this ranch.

The combination of friendliness to those who don't know better yet with disgust for those who know better and just don't care, with respect for the practical realities some may sometimes be working under imposed by the clueless, is deeply appreciated.

"That's the wrong way to do this now, it isn't 1996."

"Who cares?  I already know that now obsolete way, I just wanna do that" -- met with disgust.

"I know, but my boss won't listen to reason, please help me." -- met with empathy and helpful advice that shouldn't be needed....
 
Campbell Ritchie
Marshal
Posts: 74392
335
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:. . . wrapped by a to-be-created JPathChooser class. . . .

What a good idea
 
Paul Clapham
Marshal
Posts: 26915
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:JFileChooser can probably be wrapped by a to-be-created JPathChooser class. For files from the local file system you can easily use Path.toFile and File.toPath to bridge the gap...



That's basically what I plan to do, once I get past the higher-priority project which just popped up.
 
reply
    Bookmark Topic Watch Topic
  • New Topic