There, that's better.
Second, your code DOES get compiled. It give you (well, it give me) a warning:
Note: FileTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
but the class file is there. It even runs:
C:\slop>java FileTest trk.hl7
getName() = trk.hl7
getAbsoluteFile().getName() = trk.hl7
exists() = true
canRead() = true
canWrite() = true
getPath() = trk.hl7
getAbsolutePath() = C:\slop\trk.hl7
getCanonicalPath() = C:\slop\trk.hl7
getAbsoluteFile() = C:\slop\trk.hl7
toURL() = file:/C:/slop/trk.hl7
toURI() = file:/C:/slop/trk.hl7
getParent() = null
isAbsolute() = false
isDirectory() = false
isFile() = true
isHidden() = false
lastModified() = 1310499558269 = Tue Jul 12 14:39:18 CDT 2011
length() = 3589
The warning it gave you tells you what you should do:
Note: Recompile with -Xlint:deprecation for details.
Basically, you are being told you are using a method that is no longer supported - there is a new, better one you should be using.
C:\slop>javac -Xlint FileTest.java
FileTest.java:30: warning: [deprecation] toURL() in java.io.File has been deprecated
System.out.println("toURL() = " + f.toURL());
Checking the API for the toURL method shows this:
This method does not automatically escape characters that are illegal in URLs. It is recommended that new code convert an abstract pathname into a URL by first converting it into a URI, via the toURI method, and then converting the URI into a URL via the URI.toURL method.
Secondly, looks like the method exists() on class "File" does not look for files (such as .doc, .xls etc) it checks only sub directory.
boolean exists = f.exists();
System.out.println("exists() = " + exists);
This prints exists only if there are sub directories under it.
How do I modify to check for any "files" inside the directory ?
Mei Fdo wrote:it is frustrating I am just using text pad to write the code. Apologize..
No need to apologize - there is a lot to learn when you are just starting. the code tags are a feature of this site, not what you use to write your code with. Check out this article. There are probably some other articles you should read found here as well to get an idea how this site works best.
raden achmad hendry purnomo wrote:it means we have to learn more... how about a newbie like me that learn from the internet?then we have learned a deprecated syntax. wasting time.
That can be annoying, I know. When people say "Java," they typically mean much more than just the language. They are often referring to the many API packages in the standard library. I truly doubt that anyone ever learns all of what's in there. However, even the part you learn is subject to improvement and, with each new release of the language, there are additions to the library. You're right that a tutorial on the internet could be teaching you something that's become obsolete since it was written. One way to guard against that is to be sure the writer states which version of the language they are using, and make sure it is the latest. If what you want to do depends on a specific class in the library, read the online documentation. It will tell you, clearly, if it has been deprecated and, if so, it will usually tell you what the recommended alternative is to that class or method.
Jave SE 8 (the current version as I write this) came out in March of 2014. So, almost anything written in the last two years is less likely to be out of date than anything older than that, and a lot has been written in the last two years.
Now, when it comes to classes or methods marked with the word "deprecated," it's a good idea to take it as a strong warning that you should not use them. But, particularly when you are learning, if something that is marked "deprecated" in the online documents is still safe to use (and only deprecated because there is now a superior alternative), go ahead and try it if you think it will teach you something. Sadly, not every superior replacement for a deprecated class is always as easy to use as the class it replaces. There can still be value in experimenting with deprecated classes as a way to learn what you need to know to understand their (sometimes) more complicated successors. BUT, beware: some classes and/or some methods have been deprecated because they can really mess up your application, so you should never use them. Thread.stop is a great example. Note that the online documentation for that one starts with this:
Oracle wrote:This method is inherently unsafe.
Don't mess with anything like that! But, the fact that a lot of deprecated methods are still safe to use is implicit in the fact that lots and lots of not-deprecated library classes still use deprecated methods. If you use an IDE that marks them for you (NetBeans marks them like this: Thread.
So, while I understand your problem, I feel you have two ways to cope with it: first, read stuff published in the last two years and, second, get used to it, because Java is a work in progress; it's never going to stop changing, and that's actually a good thing.
Deprecation allows the vendor to gracefully remove functionality so that instead of a fatal compile error, you get a deprecation warning, can safely put the amended app into production and can then update the app's source code at leisure, rather than in a flustered panic. OK, we all know that "leisure" means never, but still, the idea is sound.
Perhaps one of the best illustrations of deprecation at work is one of the constructors for java.util.Date. If I have the order of the parameters correct, it's "Date(int year, int month, int day)". This is a very convenient constructor for people living in places where the Gregorian Calendar is in use, but isn't good for anything else. Since part of Java-s "write once/run anywhere" philosophy encompasses not only OS, but also language, time zone, regional quirks (like US m/d/y versus English d/m/y), and even calendars in use (Gregorian, Hegira, etc.)
That particular constructor was deprecated somewhere back around Java version 1.2, and last time I checked, is still present. So lazy people have a quick way to create a Western-style Date.
It's not a good idea to use deprecated functions/objects, however. Deprecation also means that they may be totally removed in some future software release.
Campbell Ritchie wrote:If you go through books like Object‑Oriented Sofware Construction by Bertrand Meyer, you find a different view of deprecation. Meyer says you should flag a feature for deprecation for maybe six months and then remove it. TH shows why that approach is horribly wrong.
That may be OK for systems still under development, but large shops often have critical systems that go for 5 years or more without being touched. If you remove stuff after 6 months, then for cases like that, deprecation is worthless.
Here's one that happened to me: I worked on a core application for a shop that processed a large percentage of the nation's mortgage loans on a daily basis Most of our customers were large banks. If this app broke, every last customer would be paralyzed and very little production could occur for anything.
The app in question pulled in a modified third-party compression algorithm that permitted it to make much more efficient use of long-term storage and CPU resources, but it had a fatal flaw in it that could cause it to overflow its allotted working storage by a single byte.
For years, that little time bomb ticked away until one night a minor OS upgrade from IBM shifted the way that such buffers were located in RAM and KABOOM! And our third-shift operators could be really annoyingly cheerful when they woke you up at 2 am.
The application hadn't changed, but that's how bit rot often works - the fatal blow was due to leakage from outside. This was a classic case where a few lines of code made all the difference. And we needed to get back online absolutely ASAP. If we'd been dependent on a removed deprecated function, we would have been royally screwed. As it was, the 7th-largest bank in the USA was running our code in-house and it blew up on them within hours of the same time it hit us and I narrowly avoided ending up in Chicago with lots of people yelling at me.
So deprecation is a wonderful thing, but unless you do a periodic rebuild of EVERYTHING in your shop, don't be too quick to pull deprecated items.