IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
- 16,446
- 7,460
The checks are separate. "file1 != null" makes sure the pointer is actually pointing at a valid memory location. "file1.exists()" is making sure whatever memory location file1 is pointing to actually references a file that exists on the file system.
Basically, you gotta make sure the pointer is valid and file is valid because both are going to exercised when you open file1.
Basically, you gotta make sure the pointer is valid and file is valid because both are going to exercised when you open file1.
ShakyJake
<Donor>
- 7,681
- 19,353
Khane
Got something right about marriage
- 19,933
- 13,472
Does Java not have static methods? In C# File.Exists is a static method meaning you don't instantiate any objects you just call File.Exists(file1) where file1 is just the path of the file. This will never throw a null exception, it will just return false if the file does not exist.
moontayle
Golden Squire
- 4,302
- 165
Nah, in Java that's a straight up public method (if I'm reading thejavadocright). This is where my newbness shines through, in a lot of ways I'm still figuring out how certain things work.
That said, I think part of my confusion is that I understand the lifecycle of Android fairly well and this specific check is being done further down the chain, long after the File objects have been created and initialized. There is no actual need to check for null there, and because we never have to worry about screen rotation, we don't have to worry about anything being restarted and losing the object to the nether.
That said, I think part of my confusion is that I understand the lifecycle of Android fairly well and this specific check is being done further down the chain, long after the File objects have been created and initialized. There is no actual need to check for null there, and because we never have to worry about screen rotation, we don't have to worry about anything being restarted and losing the object to the nether.
I don't work with raw files often and in general Apache and other 3rd parties have things like FileUtils but in Java File is a concrete class instantiated with the path. So yeah you'd need to call exists on it. But like I said some third parties have made interaction with files much more intuitive and convenient than the native api.
moontayle
Golden Squire
- 4,302
- 165
Good start to Monday morning. My app redesign was approved for release!
It's too bad the previous engineers working on this product fucked up the update process. I can't actually "release" this because it would wipe out the settings in all the devices in the field. So it gets used going forward and I get to keep thinking up ways to unscrew our updates.
It's too bad the previous engineers working on this product fucked up the update process. I can't actually "release" this because it would wipe out the settings in all the devices in the field. So it gets used going forward and I get to keep thinking up ways to unscrew our updates.
Cad
scientia potentia est
- 24,522
- 45,534
Java does have static methods but File just isn't implemented that way, you could just do if (new File("/var/myfile.txt").exists()) { do something } if you wanted to.
Khane
Got something right about marriage
- 19,933
- 13,472
Seems like you have to instantiate the object anyway just to do an exists() check. The original code just didn't show where it was instantiated, but it was further up the chain otherwise he wouldn't be able to call exists() on it.
Cad
scientia potentia est
- 24,522
- 45,534
The cost of instantiating objects while we're discussing going to the hard drive to check if a file exists is bottling my mind. Instantiating objects takes picoseconds probably depending on what the constructor does, going to the file system will take orders of magnitude longer. How many objects we instantiate to do that is a completely worthless metric.
Cad
scientia potentia est
- 24,522
- 45,534
I was just saying if you wanted to do it the same way as the static check in C#, you could do it that way. Or, you could create a local File variable and stick the File reference in there to re-use if you're going to do that. Obviously you wouldn't want to call new File() over and over if you're doing multiple operations with the file. I was just answering how you could call it in a one-line way.
Cad
scientia potentia est
- 24,522
- 45,534
Probably, but I think wasteful instantiated objects are probably not a very serious performance issue in any event. In CPU-performance driven apps/games etc that type of thing would be critical. In most "business" apps and webapps like what I have primarily worked on, managing your database and file system calls gets you 99% of your performance benefit.
moontayle
Golden Squire
- 4,302
- 165
Using just base Java you end up writing a lot of boilerplate for simple tasks. I've actually started usingOkiowith a dash of ApacheCommons FileUtil for most of it because it's much simpler. You still need a File object, but doing things with that object are much much simpler and a hell of a lot easier to follow.
BTW, Square open source libraries are the shiznit. Google even started using Okhttp as the backstop for Android's URLConnection library.
BTW, Square open source libraries are the shiznit. Google even started using Okhttp as the backstop for Android's URLConnection library.
Java's underlying IO implementation maybe a product of legacy bad API decisions (most probably) or that it requires a concrete file handle due to its "run anywhere" nature. I honestly don't know. And like Moon said any questionable and overly boiler plate Java stuff is almost always implemented elsewhere in a cleaner format in some utility package. You just have to know where to look. If you're a Java developer you need to make sure to know FileUtils and StringUtils from Apache fairly well.