Where does Java File instance store? - java

I have a question regarding to the Java File class. When I create a File instance, for example,
File aFile = new File(path);
Where does the instance aFile store in the computer? Or it stores in JVM? I mean is there a temp file stored in the local disk?
If I have an InputStream instance, and write it to a file by using OutputSteam, for example
File aFile = new File("test.txt");
OutputStream anOutputStream = new FileOutputStream(aFile);
byte aBuffer[] = new byte[1024];
while( ( iLength = anInputStream.read( aBuffer ) ) > 0)
{
anOutputStream.write( aBuffer, 0, iLength);
}
Now where does the file test.txt store?
Thanks in advance!

A File object isn't a real file at all - it's really just a filename/location, and methods which hook into the file system to check whether or not the file really exists etc. There's no content directly associated with the File instance - it's not like it's a virtual in-memory file, for example. The instance itself is just an object in memory like any other object.
Creating a File instance on its own does nothing to the file system.
When you create a FileOutputStream, however, that does affect whatever file system you're writing to. The File instance is relatively irrelevant though - you'd get the same effect from:
OutputStream anOutputStream = new FileOutputStream("test.txt");

It will write the file where you specify it with path arguement.
In your case, it will write it in the directory where you run your java class.
If you specify /test/myproject/myfile.txt
it will go in /test/myproject/myfile.txt

If you don't provide a path, it is in the current directory (ie: the directory where java.exe is executed from.) If you provide a full path, it is stored there.
Regardless, it is always stored in the filesystem, not in JVM memory.

Related

Is using the File class in Java how you create a file?

I need some serious help with concepts. I have been given background context on the class, specifically this:
I just need to understand the purpose of this class? Can I create a text file (or any other type of file) with its constructors? Is this just for handling files, if so, what does that mean?
Any help whatsoever will be greatly appreciated!
Thank you
You could use the java.io.File to create a file on the file system:
File myFile = new File("myFile.txt");
myFile.createNewFile();
Note that invoking the constructor won't create the file on the file system. To create an empty file, the createNewFile() method has to be invoked.
The File simply represents a abstraction of the file location, not the file itself. It comes with operations on the file identified by the path: exists(), delete(), length(), etc.
What you probably want is to use the classes that allow you to write content to a file:
If you are to write text, you should use the Writer interface.
If you are to write binary content, you should use the OutputStream interface.
The classes FileWriter and FileOutputStream are, respectively, the ones that link the File and Writer/OutputStream concepts together. Those classes create the file on the file-system for you.
FileWriter myFileWriter = null;
File myFile = new File("myFile.txt");
try {
// file is created on the file-system here
myFileWriter = new FileWriter(myFile);
myFileWriter.write("hello");
} finally {
if (myFileWriter != null) {
myFileWriter.close();
}
}
You can create a file using the File.createNewFile method, or, if you are using Java 7 or newer, using the newer Files.createFile method.
The difference between the old File and the new Path classes is that the former mixed a reference to a path to a file on the filsystem and operations you can do on it, and the latter is just representing the path itself but allows you to query it and analyze its structure.

Write to properties file inside a java Package

How to write to properties file in a java package using java class in another package.
Here is the code for writing properties file
String filePath1 = "com/...../application.properties";
File applicationProperties = new File(filePath1);
FileOutputStream fileOutputStream = new FileOutputStream(applicationProperties);
Date todayDate = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
properties.setProperty("application.database.backup.date", sdf.format(todayDate));
properties.store(fileOutputStream, "storing index values to properties file");
fileOutputStream.close();
Getting FileNotFoundException.But file is exist in this package.while reading these file get the output.
String filePath = "com/....../application.properties";
InputStream inputStream = getClass().getResourceAsStream(filePath);
Properties properties = new Properties();
properties.load(inputStream);
if (properties.getProperty("application.grouping.mode") != null || !properties.getProperty("application.grouping.mode").isEmpty()) {
String lastBackupDate = properties.getProperty("application.grouping.mode");
}
How to solve this Exception.
There are three problems here, which are related. Basically, you're assuming that get because you can read from a resource, you can write to a file in the same folder structure, relative to the current directory. That's a flawed assumption because:
The resources may not be on the file system as separate files to start with. For example, Java applications are usually packaged up into jar files. The classloader knows how to read resources from a jar file, but the folder structure isn't present on disk
Even if the files are on disk as separate files in the right folder structure, they may not be rooted in the process's working directory. For example:
# Running in /home/jon/Documents
$ java -cp /home/jon/java/bin com.foo.bar.SomeApplication
Here SomeApplication.class would be in /home/jon/java/bin/com/foo/bar, but new File("com/foo/bar/something.properties") would refer to /home/jon/Documents/com/foo/bar/something.properties.
Finally, even if you were trying to write to the right place, you may not have write access - very often the binaries for applications are stored in read-only directories, with the reasonable justification that the code and read-only application data should be separated from the application's changing state. Aside from anything else, this makes updates/repairs much easier - just blow away the old version's directory, knowing that you won't have lost any user data.
Your context isn't clear, but I would suggest that you find some appropriate way of passing a filename to the application, and write to that and read from it where you need to.
Make sure your property file is in class path. after that you should be able to load it as
String filePath = "/application.properties";
InputStream inputStream = getClass().getResourceAsStream(filePath);
Your com is in the src directory. So your file path must be src/com/...... It must start with src/ and not com/

Android get file using path (in String format)

My app needs to get an existing file for processing. Now I have the path of the file in String format, how can I get the File with it? Is it correct to do this:
File fileToSave = new File(dirOfTheFile);
Here dirOfTheFile is the path of the file. If I implement it in this way, will I get the existing file or the system will create another file for me?
That's what you want to do. If the file exists you'll get it. Otherwise you'll create it. You can check whether the file exists by calling fileToSave.exists() on it and act appropriately if it does not.
The new keyword is creating a File object in code, not necessarily a new file on the device.
I would caution you to not use hardcoded paths if you are for dirOfFile. For example, if you're accessing external storage, call Environment.getExternalStorageDirectory() instead of hardcoding /sdcard.
The File object is just a reference to a file (a wrapper around the path of the file); creating a new File object does not actually create or read the file; to do that, use FileInputStream to read, FileOutputStream to write, or the various File helper methods (like exists(), createNewFile(), etc.) for example to actually perform operations on the path in question. Note that, as others have pointed out, you should use one of the utilities provided by the system to locate directories on the internal or external storage, depending on where you want your files.
try this..
File fileToSave = new File(dirOfTheFile);
if(fileToSave.exists())
{
// the file exists. use it
} else {
// create file here
}
if parent folder is not there you may have to call fileToSave.getParentFile().mkdirs() to create parent folders

new a File object, namely create a file in disk?

when I new a File Object ,I found that there is not a file be create in disk,so I guess a File Obeject is not equal to a disk file, but when I write something to the File object through stream, I found the file be created in disk.
So, can I think like this, new File() - does not create a real file in disk, it is just an object in ram. But when you write something to the File through stream, for example:
FileWrite stream = new FileWrite(file);
stream.write(string);
..the stream will create a new file when the file does not exist (maybe function steam.write() does this?)?
How about File#createNewFile()? If you're using Java 7, you can also use Files.createFile(Path), as in this example from the Java tutorial.
FileWriter creates or truncates the file as required. The write put something in it. File is a file path name which may or may not exist. e.g. File.exists() is not always true and File.delete() can delete a file (i.e. the file no longer exists)

why new FileWriter("abc.txt") creates a new file and new File("abc.txt") does not?

new File("abc.txt") does not create actual file while new FileWriter("abc.txt") creates a file on disk. While going through source code i found that new FileWriter("abc.txt") eventually creates an object of file like new File()
Constructor of Class java.io.File does not create file on disk. It is just a abstraction over the file path. The file is created when you write to the file.
When you are creating FileWriter it calls constructor of FileOutputStream that calls a sequence of security checks and then invokes:
if (append) {
openAppend(name);
} else {
open(name);
}
Invocation of open() creates file on disk.
EDIT:
Here is how open() is defined:
/**
* Opens a file, with the specified name, for writing.
* #param name name of file to be opened
*/
private native void open(String name) throws FileNotFoundException;
I think file.createNewFile() creates the new file in actual.. please see following code for detal...
File file = new File("D:\\tables\\test.sql");
// if file does not exists, then create it
if (!file.exists()) {
file.createNewFile();
}
FileWriter fw = new FileWriter(file.getAbsoluteFile());
File doesn't always need to represent an actual file, it can be something you plan on creating, are guessing at the existence of, or something you've deleted as well.
From the JavaDoc for java.io.File:
An abstract representation of file and directory pathnames.
and
Instances of this class may or may not denote an actual file-system object such as a file or a directory.
In order to have the file actually be created, one needs to call createNEwFile(), whic according to the JavaDoc:
Atomically creates a new, empty file named by this abstract pathname if and only if a file with this name does not yet exist.
The File object is simply a representation of a file's location (URL) in the system. You can call createNewFile() on a File object in order to write our a file assuming one with that name does not already exist in that location.
When FileWriter creates a new File object internally, this is not what causes the file to come into existence. That happens in other parts of the code. A File object is just a standard way to designate a file (or directory), whether or not it exists.
There are lots of reasons really, but:
File is used by many classes in java.io. FileReader, etc... FileWriter is a "convenience" class that uses File and it enables the programmer to be more productive. Some Classes just want a File object which points to a file location and then they operate on it as needed to support their processing. Other Classes might support a FileWriter because it will only be writing to a file and not reading. It also makes the API more strongly-typed.

Categories