Suppose I do the following in java for a process that stays open:
import java.io.File;
import java.util.Date;
public class LogHolder {
public static void main(String[] args) {
File file1 = new File("myLogFile.log");
while (true) {
System.out.println("Running " + new Date());
}
}
}
Have I locked this file in a way that other windows processes can't write to the log file?
This might help you: FileLock.
No, you haven't locked the file. Here's how the Java documentation summarizes the purpose of java.io.File:
An abstract representation of file and directory pathnames
(In other words, new File() doesn't even open the file.)
You can find the rest here: http://java.sun.com/javase/6/docs/api/java/io/File.html
Related
I am trying to delete a DLL which has been loaded into JNA and later disposed. I have tried all the solutions described in the answer to this question, but they are not working: How to dispose library loaded with JNA
Here is code I've tried without a time delay:
import java.io.File;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
class Filter {
private static ExtDLLTool DLLUtil;
final private static String dllPath = "./ExternalDownloader_64.dll";
static {
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) {
if (DLLUtil != null) {
DLLUtil = null;
NativeLibrary lib = NativeLibrary.getInstance(dllPath);
lib.dispose();
}
File dllFile = new File(dllPath);
if(dllFile.exists()){
boolean isDeleted = dllFile.delete();
if(!isDeleted){
System.out.println("Unable to delete dll file, since it hold by jvm");
}
}
}
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}
I added a time delay to give the native code time to release the handle:
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
class Filter {
private static ExtDLLTool DLLUtil;
final private static String dllPath = "./ExternalDownloader_64.dll";
static {
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) throws Exception{
if (DLLUtil != null) {
DLLUtil = null;
NativeLibrary lib = NativeLibrary.getInstance(dllPath);
lib.dispose();
Thread.sleep(3000);
}
File dllFile = new File(dllPath);
if(dllFile.exists()){
Files.delete(Paths.get(dllPath));
// boolean isDeleted = dllFile.delete();
if(dllFile.exists()){
System.out.println("Unable to delete dll file, since it hold by jvm");
}
}
}
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}
This code results in an exception implying the JVM has not released the file.
Exception in thread "main" java.nio.file.AccessDeniedException: .\ExternalDownloader_64.dll at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
In the end the problem is, that Native#open is called twice and Native#close only once. The assumption behind the presented code is, that:
NativeLibrary lib = NativeLibrary.getInstance(dllPath);
yields the same NativeLibrary instance, that is used by:
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
This assumption does not hold. Indeed NativeLibrary#load does use caching and if invoked with the same parameters it will yield only a single instance.
The codepath behind Native.loadLibrary passes two options to Native#loadLibrary: calling-convention and classloader. The calling-convention is equal to the default calling convention, so can be ignored. It is/would be automatically added in NativeLibrary#getInstance. The classloader though is not set to a default value and there is the difference. The options are part of the caching key and thus a second instance of the NativeLibrary is created and not the first returned.
To make it work, the call to NativeLibrary#getInstance must pass the correct classloader. If you modify the sample like this:
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;
import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.NativeLibrary;
class Filter {
private static ExtDLLTool DLLUtil;
final private static String dllPath = "./ExternalDownloader_64.dll";
static {
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
}
public static void main(String[] args) throws Exception{
if (DLLUtil != null) {
DLLUtil = null;
NativeLibrary lib = NativeLibrary.getInstance(dllPath, ExtDLLTool.class.getClassLoader());
lib.dispose();
Thread.sleep(3000);
}
File dllFile = new File(dllPath);
if(dllFile.exists()){
Files.delete(Paths.get(dllPath));
// boolean isDeleted = dllFile.delete();
if(dllFile.exists()){
System.out.println("Unable to delete dll file, since it hold by jvm");
}
}
}
private interface ExtDLLTool extends Library {
String validateNomination(String dloadProps);
}
}
it works as expected.
After discussion there is another requirement: The cache path is only hit in a limited number of cases:
the library name is the filename of the library (without a prefix)
the library name is the absolute path to the library
the library name is the "base" name without any prefixes or suffixes the default library search mechanism adds (on windows ".dll" should be stripped, on linux "lib" prefix and ".so" suffix should be stripped) (UNTESTED!)
The TL;DR version: find the absolute path name and use that for interface loading and NativeLibrary loading.
I was able to reproduce the problem with your code, but only on Windows. When reproducible, I was able to successfully delete the file by adding a garbage collection suggestion before the time delay:
if (DLLUtil != null) {
DLLUtil = null;
NativeLibrary lib = NativeLibrary.getInstance(dllPath);
lib.close();
System.gc();
System.gc();
Thread.sleep(3000);
}
When JNA loads a Windows DLL via Native.loadLibrary(), it internally executes the WinAPI LoadLibraryExW function.
Internally the Java instance is stored in a map to be re-used when possible -- however for this to happen, it requires two things to look up the same Java object:
the DLL Path must be an absolute path
the options must match. In this case, you would need to pass the classloader as an argument as Matthias Bläsing indicated in his answer:
// if loaded like this:
DLLUtil = (ExtDLLTool) Native.loadLibrary(dllPath, ExtDLLTool.class);
// fetch from cache like this:
NativeLibrary lib = NativeLibrary.getInstance(dllPath, ExtDLLTool.class.getClassLoader());
lib.dispose();
This should allow you to delete the file.
However, in your case, with the relative path, the library is getting unloaded but the old java object isn't getting closed until GC occurs.
The dispose() (or close() as of 5.12) call in JNA eventually calls the Native.close() method which uses the Windows API FreeLibrary function. This unloads the DLL from the Process memory, so the advice on the linked question on how to dispose is still accurate in the case that you want to re-load the library. If you're not reloading the library, using dispose() (5.11-) or close() (5.12+) is optional.
If you must use a relative path, consider this approach using a PhantomReference inspired by this answer to track the deletion:
if (DLLUtil != null) {
// Unload the DLL from process memory
// Optional here, as it will be called by a cleaner on GC below
NativeLibrary lib = NativeLibrary.getInstance(dllPath);
lib.close();
System.out.println("Closed.");
// Remove any internal JVM references to the file
final ReferenceQueue rq = new ReferenceQueue();
final PhantomReference phantom = new PhantomReference(DLLUtil, rq);
DLLUtil = null;
// Poll until GC removes the reference
int count = 0;
while (rq.poll() == null) {
System.out.println("Waiting...");
Thread.sleep(1000);
if (++count > 4) {
// After 5 seconds prompt for GC!
System.out.println("Suggesting GC...");
System.gc();
}
}
System.out.println("Collected.");
}
The DLL was successfully deleted following this sequence. It did take a second GC call to take effect:
Closed.
Waiting...
Waiting...
Waiting...
Waiting...
Waiting...
Suggesting GC...
Waiting...
Suggesting GC...
Collected.
Deleted!
I'm aware this question might be a duplicate in some sense but first hear me out.
I tried to create a code where i can create gitignore file with contents and for some reason i always end up having a file with txt extension and without name. Can someone explain this behavior and why?
Example Code:
System.out.println(fileDir+"\\"+".gitignore");
FileOutputStream outputStream = new FileOutputStream(fileDir+"\\"+".gitignore",false);
byte[] strToBytes = fileContent.getBytes();
outputStream.write(strToBytes);
outputStream.close();
You can use java.nio for it. See the following example:
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.List;
public class StackoverflowMain {
public static void main(String[] args) {
// create the values for a folder and the file name as Strings
String folder = "Y:\\our\\destination\\folder"; // <-- CHANGE THIS ONE TO YOUR FOLDER
String gitignore = ".gitignore";
// create Paths from the Strings, the gitignorePath is the full path for the file
Path folderPath = Paths.get(folder);
Path gitignorPath = folderPath.resolve(gitignore);
// create some content to be written to .gitignore
List<String> lines = new ArrayList<>();
lines.add("# folders to be ignored");
lines.add("**/logs");
lines.add("**/classpath");
try {
// write the file along with its content
Files.write(gitignorPath, lines);
} catch (IOException e) {
e.printStackTrace();
}
}
}
It creates the file on my Windows 10 machine without any problems. You need Java 7 or higher for it.
I have two classes in a Maven project, which contain the same code (except for their name). The code shall later create a new class with Javassist based on a csv-file.
The first one CsvParser is placed in the src/main/java/csvParser package. The second one TestCsvParser is placed in the src/test/java/csvParser package. In both packages the same file assistant.csv is placed.
When I run the one from the main directory (CsvParser) I get a java.lang.NullPointerException but when I run TestCsvParser, placed in the testdirectory the same code works fine.
Why is it like that? (Or do I just not see something? ;) )
CsvParser:
package csvParser;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class CsvParser {
public static void main(String[] args) throws IOException
{
createClass("/assistant.csv");
}
/**
* Create a class from a csv-file.
*/
private static void createClass(String input) throws IOException {
try(BufferedReader stream = new BufferedReader(new InputStreamReader(
CsvParser.class.getResourceAsStream(input))))
{
// Create class based on csv-file.
}
}
}
TestCsvParser:
package csvParser;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class TestCsvParser {
public static void main(String[] args) throws IOException
{
createClass("/assistant.csv");
}
/**
* Create a class from a csv-file.
*/
private static void createClass(String input) throws IOException {
try(BufferedReader stream = new BufferedReader(new InputStreamReader(
TestCsvParser.class.getResourceAsStream(input))))
{
// Create class based on csv-file.
}
}
}
The exception
Exception in thread "main" java.lang.NullPointerException
at java.io.Reader.<init>(Reader.java:78)
at java.io.InputStreamReader.<init>(InputStreamReader.java:72)
at csvParser.CsvParser.createClass(CsvParser.java:19)
at csvParser.CsvParser.main(CsvParser.java:11)
I believe this question is not a duplicate of a question like What is a NullPointerException because:
The NullPointerException occurs based on the location of the class and the resource referred to. So it's more about directory structures and Mavens targetdirectory.
Thanks for your time!
Finally I found the error. I added the assistant.csv beside the two classes (CsvParser and TestCsvParser). But in both cases this file is not added to the target directory.
The reason why it was working in TestCsvParser is an additional assistant.csv in the ../test/resource/ directory. In fact the two conditions which I described missed this fact and therefore you could not reconstruct my error fully. I'm sorry for that.
To have a working example the resource files both for main and test have to placed within the resource folder instead of beside the class.
Thanks for your help, especially Kalaiselvan A.
It will depend on location of "/assistant.csv" file and if it's not found, you will get NPE. The path will be dependent on your class location since you are calling CsvParser.class.getResourceAsStream..
For my project, I am using weka.jar. I am converting a CSV file to ARFF using following code:
import weka.core.Instances;
import weka.core.converters.ArffSaver;
import weka.core.converters.CSVLoader;
import java.io.File;
public class CsvArffConverter
{
public static void Convert(String sourcepath,String destpath) throws Exception
{
// load CSV
CSVLoader loader = new CSVLoader();
loader.setSource(new File(sourcepath));
Instances data = loader.getDataSet();
// save ARFF
ArffSaver saver = new ArffSaver();
saver.setInstances(data);
saver.setFile(new File(destpath));
saver.setDestination(new File(destpath));
saver.writeBatch();
}
public static void main(String args[]) throws Exception
{
Convert("C:\\ad\\BSEIT.csv", "C:\\ad\\test.arff");
}
}
However, on executing, I am getting following error:
Cannot create a new output file. Standard out is used.
Exception in thread "main" java.io.IOException: Cannot create a new output file (Reason: java.io.IOException: File already exists.). Standard out is used.
at `enter code here`weka.core.converters.AbstractFileSaver.setDestination(AbstractFileSaver.java:421)
at Predictor.CsvArffConverter.Convert(CsvArffConverter.java:29)
at Predictor.CsvArffConverter.main(CsvArffConverter.java:34)
According to weka mail list, this error is a file issue, may be permission. Other emails suggest to use Java I/O approch to save arff file.
This error is coming from the CSVSaver and indicates that it is unable
to create the directory and/or file that you've specified. More than
likely it is something to do with permissions on where it is trying to
write to.
Try following code.
import weka.core.Instances;
import weka.core.converters.ArffSaver;
import weka.core.converters.CSVLoader;
import java.io.File;
public class CsvArffConverter
{
public static void Convert(String sourcepath,String destpath) throws Exception
{
// load CSV
CSVLoader loader = new CSVLoader();
loader.setSource(new File(sourcepath));
Instances dataSet = loader.getDataSet();
// save ARFF
BufferedWriter writer = new BufferedWriter(new FileWriter(destpath));
writer.write(dataSet.toString());
writer.flush();
writer.close();
}
public static void main(String args[]) throws Exception
{
Convert("BSEIT.csv", "test.arff");
}
}
As you can see, I use relative paths. Since absolute path writing may be blocked due to permission issues.
I'm trying to convert a csv file to arff using some Java code I found, but I keep getting the IO error that no source has been specified.
How should I make the file path because a standard "C:\user\user1\Desktop\folder\file.csv" one isn't working for me?
Here is the code I am using:
import weka.core.Instances;
import weka.core.converters.ArffSaver;
import weka.core.converters.CSVLoader;
import java.io.File;
public class CSV2Arff {
public static void main(String[] args) throws Exception {
// load CSV
CSVLoader loader = new CSVLoader();
loader.setSource(new File("file path"));
Instances data = loader.getDataSet();//get instances object
// save ARFF
ArffSaver saver = new ArffSaver();
saver.setInstances(data);//set the dataset we want to convert
//and save as ARFF
saver.setFile(new File("file path"));
saver.writeBatch();
}
}
Your file path should be specified like this
loader.setSource(new File("C:\\Users\\user1\\Desktop\\file1\\file.csv"));
You should use \\ instead of \.