I'm following this tutorial:
http://docs.oracle.com/javase/tutorial/uiswing/components/filechooser.html
so that i can learn how to use the file chooser in a GUI i am building, but the source file i have downloaded doesn't match up with the tutorial, i am getting an error message whenever i press a button in the GUI.
if (e.getSource() == saveButton) {
FileSaveService fss = null;
FileContents fileContents = null;
ByteArrayInputStream is = new ByteArrayInputStream(
(new String("Saved by JWSFileChooserDemo").getBytes()));
//XXX YIKES! If they select an
//XXX existing file, this will
//XXX overwrite that file.
try {
fss = (FileSaveService)ServiceManager.
lookup("javax.jnlp.FileSaveService");
} catch (UnavailableServiceException exc) { }
if (fss != null) {
try {
fileContents = fss.saveFileDialog(null,
null,
is,
"JWSFileChooserDemo.txt");
} catch (Exception exc) {
log.append("Save command failed: "
+ exc.getLocalizedMessage()
+ newline);
log.setCaretPosition(log.getDocument().getLength());
}
}
if (fileContents != null) {
try {
log.append("Saved file: " + fileContents.getName()
+ "." + newline);
} catch (IOException exc) {
log.append("Problem saving file: "
+ exc.getLocalizedMessage()
+ newline);
}
} else {
log.append("User canceled save request." + newline);
}
log.setCaretPosition(log.getDocument().getLength());
}
}
I am getting the user cancelled save request.
Your main issue is that your fileContents may be null without you to know it. This can be caused by 2 reasons:
The user cancelled the request, so saveFileDialog returns null. This is the message you actually get, but the source of your error can be different ;
The error could come from the extension parameter of saveFileDialog that is null... . If an exception is raised, it would be nice to know about it, so I advise you add a message to the log (see code below).
Solution:
You should log the UnavailableServiceException to keep track of the exception, and you should respect the saveFileDialog method prototype (to avoid any ambiguity) as described here: FileSaveService Interface.
This is the part of your code where are applied the previous advices:
try {
fss = (FileSaveService)ServiceManager.lookup("javax.jnlp.FileSaveService");
} catch (UnavailableServiceException exc) {
log.append("A problem occurred while accessing the service manager." + newline);
}
if (fss != null) {
try {
fileContents = fss.saveFileDialog(null, { "txt" }, is, "JWSFileChooserDemo");
}
/* Your previous code */
}
/* Your previous code */
If this doesn't solve your problem, this will at least give your more information about where it comes from.
Related
I am trying to figure out why my inputFile.delete() will not delete the file. After looking at numerous topics it looks like something is still using the file and hence it won't delete. But I can't figure it out. What am I missing??
File inputFile = new File("data/Accounts.txt");
File tempFile = new File("data/tmp.txt");
try {
tempFile.createNewFile();
BufferedReader reader = new BufferedReader(new FileReader(inputFile));
BufferedWriter writer = new BufferedWriter(new FileWriter(tempFile));
String line;
int i = 0;
for (User u : data) {
String toRemove = getIDByUsername(username);
while ((line = reader.readLine()) != null) {
if (line.contains(toRemove + " ")) {
line = (i + " " + username + " " + getStatusByUsername(username) + " " + password);
}
writer.write(line + "\n");
i++;
}
}
reader.close();
writer.close();
} catch (FileNotFoundException e) {
ex.FileNotFound();
} catch (IOException ee) {
ex.IOException();
} finally {
inputFile.delete();
tempFile.renameTo(inputFile);
}
You can have that much shorter and easier by using java.nio:
public static void main(String[] args) {
// provide the path to your file, (might have to be an absolute path!)
Path filePath = Paths.get("data/Accounts.txt");
// lines go here, initialize it as empty list
List<String> lines = new ArrayList<>();
try {
// read all lines (alternatively, you can stream them by Files.lines(...)
lines = Files.readAllLines(filePath);
// do your logic here, this is just a very simple output of the content
System.out.println(String.join(" ", lines));
// delete the file
Files.delete(filePath);
} catch (FileNotFoundException fnfe) {
// handle the situation of a non existing file (wrong path or similar)
System.err.println("The file at " + filePath.toAbsolutePath().toString()
+ " could not be found." + System.lineSeparator()
+ fnfe.toString());
} catch (FileSystemException fse) {
// handle the situation of an inaccessible file
System.err.println("The file at " + filePath.toAbsolutePath().toString()
+ " could not be accessed:" + System.lineSeparator()
+ fse.toString());
} catch (IOException ioe) {
// catch unexpected IOExceptions that might be thrown
System.err.println("An unexpected IOException was thrown:" + System.lineSeparator()
+ ioe.toString());
}
}
This prints the content of the file and deletes it afterwards.
You will want to do something different instead of just printing the content, but that will be possible, too ;-) Try it...
I am trying to figure out why my inputFile.delete() will not delete the file.
That's because the old file API is crappy specifically in this way: It has no ability to tell you why something is not succeeding. All it can do, is return 'false', which it will.
See the other answer, by #deHaar which shows how to do this with the newer API. Aside from being cleaner code and the newer API giving you more options, the newer API also fixes this problem where various methods, such as File.delete(), cannot tell you the reason for why it cannot do what you ask.
There are many, many issues with your code, which is why I strongly suggest you go with deHaar's attempt. To wit:
You aren't properly closing your resources; if an exception happens, your file handlers will remain open.
Both reading and writing here is done with 'platform default encoding', whatever that might be. Basically, never use those FileReader and FileWriter constructors. Fortunately, the new API defaults to UTF_8 if you fail to specify an encoding, which is more sensible.
your exception handling is not great (you're throwing away any useful messages, whatever ex.FileNotFound() might be doing here) - and you still try to delete-and-replace even if exceptions occur, which then fail, as your file handles are still open.
The method should be called getIdByUsername
Your toRemove string is the same every time, or at least, the username variable does not appear to be updated as you loop through. If indeed it never updates, move that line out of your loop.
I am writing a method that takes in a List of Twitter Status objects as a parameter, opens a log file containing String represenatations of Tweets, checks if any of the String representations of the Status objects are already written to the file - if so, it removes them from the list, if not it appends the Status to the file.
Everything is working up until I attempt to write to the file. Nothing is being written at all. I am led to believe that it is due to the method having the file open in two different places: new File("tweets.txt") and new FileWriter("tweets.txt, true).
Here is my method:
private List<Status> removeDuplicates(List<Status> mentions) {
File mentionsFile = new File("tweets.txt");
try {
mentionsFile.createNewFile();
} catch (IOException e1) {
// Print error + stacktrace
}
List<String> fileLines = new ArrayList<>();
try {
Scanner scanner = new Scanner(mentionsFile);
while (scanner.hasNextLine()) {
fileLines.add(scanner.nextLine());
}
scanner.close();
} catch (FileNotFoundException e) {
// Print error + stacktrace
}
List<Status> duplicates = new ArrayList<>();
for (Status mention : mentions) {
String mentionString = "#" + mention.getUser().getScreenName() + " \"" + mention.getText() + "\" (" + mention.getCreatedAt() + "\")";
if (fileLines.contains(mentionString)) {
duplicates.add(mention);
} else {
try {
Writer writer = new BufferedWriter(new FileWriter("tweets.txt", true));
writer.write(mentionString);
} catch (IOException e) {
// Print error + stacktrace
}
}
}
mentions.removeAll(duplicates);
return mentions;
}
I wrote here few thoughts looking your code.
Remember to always close the object Reader and Writer.
Have a look at try-with-resources statement :
try (Writer writer = new BufferedWriter(new FileWriter("tweets.txt", true))) {
writer.write(mentionString);
} catch (IOException e) {
// Print error + stacktrace
}
To read an entire file in a List<String>:
List<String> lines = Files.readAllLines(Paths.get("tweets.txt"), StandardCharsets.UTF_8);
And again, I think it's a bad practice write in the same file you're reading of.
I would suggest to write in a different file if you don't have a particular constraint.
But if you really want have this behavior there are few alternative.
Create a temporary file as output and, when you process is successfully completed, than move it to the old one using Files.move(from, to).
Edit: I just found out that not a IOExcpetion but a FilerException is thrown. Therefore I changed that in the description and the title.
I'm working with Annotation Processing to generate some files for my java project. Now I always get an FilerException when the Annotation Processing tries to generate my files.
This is the way I create the files (GenClass and GenAnnotation are custom classes that abstract the generated classes. They weren't changed in about half a year so I'm sure the error isn't somewhere there. The way I write the files also didn't change in the last year.):
public static boolean generateJavaSourceFile(final ProcessingEnvironment processingEnv,
final GenClass element, final String fileName, final Class<?> generatorClass) {
boolean succeed = false;
Writer fw = null;
Filer f = processingEnv.getFiler();
// Mark the class as generated
GenAnnotation generatedAnnotation = getAnnotation(generatorClass);
element.pushImport(generatedAnnotation);
element.addAnnotation(generatedAnnotation);
try {
JavaFileObject jfo = f.createSourceFile(fileName, (Element[]) null);
// create new java source file
fw = jfo.openWriter();
// write the GenClass object into file
fw.write(element.toString());
succeed = true;
} catch (FilerException e) {
LOGGER.severe("Couldn't generate file (" + fileName + ")!");
processingEnv.getMessager().printMessage(Kind.ERROR,
"Could not create source file " + fileName
+ " because it already exists");
throw new RuntimeException(e.getMessage(), e);
} catch (IOException e) {
LOGGER.severe("Couldn't generate file (" + fileName + ")!");
throw new RuntimeException(e.getMessage(), e);
} finally {
if (fw != null) {
try {
fw.close(); // flush and close the stream
} catch (IOException e) {
LOGGER.severe("Couldn't close file [" + fileName + "]!");
}
}
}
LOGGER.fine(fileName + " written");
return succeed;
This is the message of the exception:
Source file already created: /path/to/the/file/to/create
I did change something on my processors, however the error only occurs for a certain type of files (Filters we use to filter data) and I didn't change anything on the processor that generates the filters. I added a new processor that works with a different annotation and those file are generated correctly.
Does anyone know what the cause of this error could be?
I had an error in another processor (that had nothing to do with the processor that generates the Filters) and that caused this error. Now that I fixed that error also this behavior stopped. I'm not really sure why this FilerException happened all the time, however it is gone now.
System.out.println("READ");
String currentWorldName = "RANDOM";
String propertiesFileDirectory = propertiesFolder + currentWorldName + "/props.properties";
String entitiesFolderDirectory = propertiesFolder + currentWorldName + "/Entities";
try
{
properties.load(new FileInputStream(propertiesFileDirectory));
}
catch (FileNotFoundException e)
{
//Since it doesn't exist either it was deleted by the user or hasn't been created yet.
createNewPropertiesFile();
}
catch (IOException e)
{
outputToLog("IOException when loading properties file for the world: '" + currentWorldName + "'.\n" + e.getStackTrace().toString());
}
//getting values from properties
//Now to read each properties file in Entities
File entitiesFolder = new File(entitiesFolderDirectory);
try
{
List<String> entitiesDirectoryContents = Arrays.asList(entitiesFolder.list());
//Read each file in the entities directory and load it into memory.
for (String entityPropertiesFileName : entitiesDirectoryContents)
{
if (propertiesBelongsToEntityCH(entityPropertiesFileName))
{
//Get properties one way
}
else //The properties file we're working does not belong to CH.
{
//Get properties from the same file a different way
}
}
//This should never be hit since we have the file to read.
catch (FileNotFoundException e)
{
outputToLog("FileNotFoundException when loading entity properties file." + e.getMessage().toString());
}
//I don't know when/if this would be hit. It hasn't happened.
catch (IOException e)
{
outputToLog("IOException when loading entity properties file." + e.getMessage().toString());
}
catch (NullPointerException e)
{
entitiesFolder.mkdirs();
}
This HAS been working, I swear. It just started doing this.
Java keeps claiming that the "entitiesFolder" directory doesn't exist (I check with entitiesFolder.exists()). I have a solution for when that happens as you can see, because while my program is running it definitely can happen. Well it still claims that the folder doesn't exist, over and over.
I'm absolutely positive that it's the right directory because I print the "entitiesFolderDirectory" out to the console. It's correct. I can also be looking at the files inside of that folder and when mkdirs() runs it just deletes them all.
Java bug? This has completely broken my program.
I would write it without throwing a NullPointerException.
File entitiesFolder = new File(entitiesFolderDirectory);
entitiesFolder.mkdirs();
for (String entityPropertiesFileName : entitiesFolder.list()) {
//Do stuff
}
This will always work unless the folder could not be created.
What is the problem with this code? only one curly braces i found is missing else it is working fine.
This will create a dir test in c drive if does not exist else it will list the files in test dir over n over again
String entitiesFolderDirectory = "C:\\test";
File entitiesFolder = new File(entitiesFolderDirectory);
try
{
List<String> entitiesDirectoryContents = Arrays.asList(entitiesFolder.list());
for (String entityPropertiesFileName : entitiesDirectoryContents)
{
System.out.println(entityPropertiesFileName);
}
}catch (NullPointerException e)
{
System.out.println("creating new folder");
entitiesFolder.mkdirs();
}
Could you please suggest how to deal with these situations ? I understand that in the second example, it is very rare that it would happen on unix, is it ? If access rights are alright. Also the file wouldn't be even created. I don't understand why the IOException is there, either it is created or not, why do we have to bother with IOException ?
But in the first example, there will be a corrupted zombie file. Now if you tell the user to upload it again, the same thing may happen. If you can't do that, and the inputstream has no marker. You loose your data ? I really don't like how this is done in Java, I hope the new IO in Java 7 is better
Is it usual to delete it
public void inputStreamToFile(InputStream in, File file) throws SystemException {
OutputStream out;
try {
out = new FileOutputStream(file);
} catch (FileNotFoundException e) {
throw new SystemException("Temporary file created : " + file.getAbsolutePath() + " but not found to be populated", e);
}
boolean fileCorrupted = false;
int read = 0;
byte[] bytes = new byte[1024];
try {
while ((read = in.read(bytes)) != -1) {
out.write(bytes, 0, read);
}
} catch (IOException e) {
fileCorrupted = true;
logger.fatal("IO went wrong for file : " + file.getAbsolutePath(), e);
} finally {
IOUtils.closeQuietly(in);
IOUtils.closeQuietly(out);
if(fileCorrupted) {
???
}
}
}
public File createTempFile(String fileId, String ext, String root) throws SystemException {
String fileName = fileId + "." + ext;
File dir = new File(root);
if (!dir.exists()) {
if (!dir.mkdirs())
throw new SystemException("Directory " + dir.getAbsolutePath() + " already exists most probably");
}
File file = new File(dir, fileName);
boolean fileCreated = false;
boolean fileCorrupted = false;
try {
fileCreated = file.createNewFile();
} catch (IOException e) {
fileCorrupted = true;
logger.error("Temp file " + file.getAbsolutePath() + " creation fail", e);
} finally {
if (fileCreated)
return file;
else if (!fileCreated && !fileCorrupted)
throw new SystemException("File " + file.getAbsolutePath() + " already exists most probably");
else if (!fileCreated && fileCorrupted) {
}
}
}
I really don't like how this is done in Java, I hope the new IO in Java 7 is better
I'm not sure how Java is different than any other programming language/environment in the way you are using it:
a client sends some data to your over the wire
as you read it, you write it to a local file
Regardless of the language/tools/environment, it's possible for the connection to be interrupted or lost, for the client to go away, for the disk to die, or for any other error to occur. I/O errors can occur in any and all environments.
What you can do in this situation is highly dependent on the situation and the error that occured. For example, is the data structured in some way where you could ask the user to resume uploading from record 1000, for example? However, there is no single solution that fits all here.