We Keep Coding

Java: FileOutputStream("NUL:") not working after Java upgrade

On Windows, NUL is the null output device similar to /dev/null on Linux.
With Oracle Java 8 Update 331, trying to get a new FileOutputStream("NUL:") throws an exception. Previously (Java 8u321) it worked fine.
The problem seems to be the colon:
new FileOutputStream("NUL") - OK
new FileOutputStream("NUL:") - exception
Can anyone point me to docs or JDK sources regarding this change? I can't change the code itself because it is in a 3rd party lib (xnio-api).
try
{
new FileOutputStream("NUL:");
System.out.println("OK");
}
catch (FileNotFoundException e)
{
System.out.println(e);
}

I suspect this is the offending change.
Apparently it tries to avoid accessing ADS (alternate data streams), but seems to "accidentally" also prevent access to device-files like this.
If that's correct, then you can try setting the system property jdk.io.File.enableADS to true to re-enable the old behaviour.

file.delete() not working properly

I'm having some problems with file deletion in Java. I'm doing a simple CRUD application for my OOP class and we need to use files as database. I tried to create a function to erase the database (Delete all database files and save new empty ones), but, so far, I always receive the success message, but the files still there, untouched.
I have the file path set this way in my config.java file:
private String fileBooks = "books.dat";
private String fileUsers = "users.dat";
private String fileOperations = "operations.dat";
I have this function, responsible for file erase:
public void deleteFiles() {
try {
File fbooks = new File(config.getFileBooks());
File fusers = new File(config.getFileUsers());
File fop = new File(config.getFileOperations());
if(fbooks.delete() && fusers.delete() && fop.delete()){
JOptionPane.showMessageDialog(null, "Success!",
"Database cleaning", JOptionPane.PLAIN_MESSAGE);
}else{
JOptionPane.showMessageDialog(null, "Error!",
"Database cleaning", JOptionPane.ERROR_MESSAGE);
}
} catch (Exception e) {
e.printStackTrace();
}
}
I checked the inheritance, the controller, everything looks fine. What I'm doing wrong? Is it a problem with the path?
If is useful information I'm running a Ubuntu 14.04 LTS, using NetBeans to code.
Any help and code advice will be welcome.
EDIT:
I added the System.out.println(fbooks.getAbsoluteFile()) this was my output:
/home/dotk/Dropbox/College/OOP/TP02/hw02/books.dat
/home/dotk/Dropbox/College/OOP/TP02/hw02/users.dat
/home/dotk/Dropbox/College/OOP/TP02/hw02/operations.dat
Do I need to change the path? I want the program to be OS independent, and it will be probably tested in a windows machine.
EDIT 2
I changed the file names, now they don't have the "./" but still not working. I verified that isn't any other open streams to the files, the only ones that run are in the start of the program to load the informations in ArrayLists, but they are closed after.

I found the error, the problem was in the order of the calls. I feel a little bit stupid, but now is fixed.

Major java libraries doesn't predict the case of “cyclic copy” of a file onto a destination differently mapped

In my experience and after repeated tests I've done and deep web researches, I've found that major java libraries (either "Apache Commons" or Google.coomons or Jcifs) doesn't predict the case of “cyclic copy” of a file onto a destination differently mapped (denoted with different RootPath according with newer java.nio package Path Class) that,at last end of mapping cycle,resolves into the itself origin file.
That's a situation of data losing, because Outputsream method nor jnio's GetChannel method prevents itself this case:the origin file and the destination file are in reality "the same file" and the result of these methods is that the file become lost, better said the size o file become 0 length.
How can one avoid this without get off at a lower filesystem level or even surrender to a more safe Runtime.exec, delegating the stuff at the underlying S.O.
Should I have to lock the destination file (the above methods not allowing this), perhaps with the aid of the oldest RandomAccessFile Class ?
You can test using those cited major libraries with a common "CopyFile(File origin,File dest)" method after having done:
1) the origin folder of file c:\tmp\test.txt mapped to to x: virtual drive via a cmd's [SUBST x: c:\tmp] thus trying to copy onto x:\test.txt
2) Similar case if the local folder c:\tmp has been shared via Windows share mechanism and the destination is represented as a UNC path ending with the same file name
3) Other similar network situations ...
I think there must be another better solution, but my experience of java is fairly few and so I ask for this to you all. Thanks in advance if interested in this “real world” discussion.

Your question is interesting, never thought about that. Look at this question: Determine Symbolic Links. You should detect the cycle before copying.

Perhaps you can try to approach this problem slightly differently and try to detect that source and destination files are the same by comparing file's metadata (name, size, date, etc) and perhaps even calculate hash of the files content as well. This would of course slow processing down.
If you have enough permissions you could also write 'marker' file with random name in destination and try to read it at the source to detect that they're pointing to the same place. Or try to check that file already exist at destination before copying.

I agree that it is unusual situations, but you will agree that files are a critical base of every IT system. I disagree that manipulating files in java is unusual: in my case I have to attach image files of products through FileChooser and copy them in ordered way to a repository ... but real world users (call them customers who buy your product) may fall in such situations and if it happens, one can not 'blame the devil of bad luck if your product does something "less" than expected.
It is a good practice learning from experience and try to avoid what one of Murphy's Laws says, more' or less: "if something CAN go wrong, it WILL go wrong sooner or later.
Is perhaps also for one of those a reason I believe the Java team at Sun and Oracle has enhanced the old java.io package for to the newest java.nio. I'm analyzing a the new java.nio.Files Class which I had escaped to attention, and soon I believe I've found the solution I wanted and expected. See you later.

Thank for the address from other experienced members of the community,and thanks also to a young member of my team, Tindaro, who helped me in the research, I've found the real solution in Jdk 1.7, which is made by reliable, fast, simple and almost definitively will spawn a pity veil on older java.io solutions. Despite the web is still plenty full of examples of copying files in java using In/out Streams I'll warmely suggest everyone to use a simple method : java.nio.Files.copy(Path origin, Path destination) with optional parameters for replacing destination,migrate metadata file attributes and even try a transactional move of files (if permitted by the underlying O.S.).
That's a really good Job, waited for so long!
You can easily convert code from copy(File file1, File file2) by appending a ".toPath()" to the File instance (e.g. file1.toPath(), file2.toPath().
Note also that the boolean method "isSameFile(file1.toPath(), file2.toPath())", is already used inside the above copy method but easily usable in every case you want.
For every case you can't upgrade to 1.7 using community libraries from Apache or Google is still suggested, but for reliable purpose, permit me to suggest the temporary workaround I've found before:
public static boolean isTheSameFile(File f1, File f2) {//throws Exception{
// minimum prerequisites !
if(f1.length()!=f2.length()) return false;
if (!file1.exists() || !file2.exists()) { return false; }
if (file1.isDirectory() || file2.isDirectory()){ return false; }
//if (file1.getCanonicalFile().equals(file2.getCanonicalFile())); //don't rely in this ! can even still fail
//new FileInputStream(f2).getChannel().lock();//exception, can lock only on OutputStream
RandomAccessFile rf1=null,rf2=null; //the only practicable solution on my own ... better than parse entire files
try {
rf1 = new RandomAccessFile(f1, "r");
rf2=new RandomAccessFile(f2, "rw");
} catch (FileNotFoundException e) {
e.printStackTrace();
return false;
}
try {
rf2.getChannel().lock();
} catch (IOException e) {
return false;
}
try {
rf1.getChannel().read(ByteBuffer.allocate(1));//reads 1 only byte
} catch (IOException e) {
//e.printStackTrace(); // if and if only the same file, the O.S. will throw an IOException with reason "file already in use"
try {rf2.close();} catch (IOException e1) {}
return true;
}
//close the still opened resources ...
if (rf1.getChannel().isOpen())
try {rf1.getChannel().close();} catch (IOException e) {}
try {
rf2.close();
} catch (IOException e) {
return false;
}
// done, files differs
return false;
}

How to print PDF file in a Java application?

How do I print a PDF file from a Java application?

Here some source code that will allow you print any text file:
public void print() {
//The desktop api can help calling other applications in our machine
//and also many other features...
Desktop desktop = Desktop.getDesktop();
try {
//desktop.print(new File("DocXfile.docx"));
desktop.print(new File("Docfile.pdf"));
} catch (IOException e) {
e.printStackTrace();
}
}
Maybe it suit your needs since you did not give more details.

Try PDF Renderer. It's open source and there are a couple of examples on the site on how to render to a printer device.

I've used PDFBox before for a similar task like yours.
It's an excellent library from the Apache Software Foundation.
The class you are probably going to use is called: PDFTextStripper .
The javadoc for the class can be found here.

Data in J2ME RecordStore does not persist across sessions

I'm building a mobile app with J2ME, and I've found that the data I write into a RecordStore can be accessed while the program is still running but it is lost after quitting and restarting it. No exception is thrown, the data is simply lost.
UPDATE: Thanks everyone for your suggestions. I'm using NetBeans on Windows 7. I'm not sure if it is using the WTK version I have previously installed or another one it has installed somewhere else. I've checked my WTK folder for the files Pavel wrote about, but couldn't find them. Now I'm testing the features requiring persistence on my phone and everything else in the emulator, but it would of course be much better to be able to test everything in the emulator.
private RecordStore recordStore = null;
public MyMIDlet() {
readStuff(); // output: nothing found in recordStore :(
saveStuff();
readStuff(); // output: stuff
}
private void readStuff() {
try {
recordStore = RecordStore.openRecordStore(REC_STORE, true);
int n = recordStore.getNumRecords();
String stuff;
if (n == 0) {
stuff = "nothing found in recordStore :(";
}
else {
stuff = new String(recordStore.getRecord(1));
}
System.out.println(stuff);
}
catch (Exception e) {
System.out.println("Exception occured in readStuff: " + e.getMessage());
}
finally {
if (recordStore != null) {
try {
recordStore.closeRecordStore();
}
catch (Exception e) {
// ignore
}
}
}
}
private void saveStuff() {
try {
recordStore = RecordStore.openRecordStore(REC_STORE, true);
int n = recordStore.getNumRecords();
byte[] stuff = "stuff".getBytes();
recordStore.addRecord(stuff, 0, stuff.length);
} catch (Exception e) {
System.out.println("Exception occured in saveStuff: " + e.getMessage());
} finally {
if (recordStore != null) {
try {
recordStore.closeRecordStore();
} catch (Exception e) {
// ignore
}
}
}
}

If you use Sun WTK, it creates a file named "in.use" in its "appdb" folder:
C:\WTK25\appdb\DefaultColorPhone\in.use
If you close your emulator in unusual way (kill a process, for example), it would not delete it, and next time you run emulator, it would create temporary folder for storing data:
C:\WTK25\appdb\temp.DefaultColorPhone1
when starting this way, it should print in console: "Running with storage root temp.DefaultColorPhone1".
I fix it, including into my ".bat" file a line for deleting "in.use" file each time, emulator runs. But you should be careful when running several emulators at once.

I experienced the same problem myself, I did however discover that NetBeans, or whatever, deletes the deployed program files after execution. These files are located in the C:\Documents and Settings\MyUser\javame-sdk\3.0\work\0\appdb folder, might be different on Vista/Win7 and I guess the number in the path refers to the emulator you are currently using. Anyways, in this folder look for something that is named like your RecordStore. E.g. "00000002_PSC_onfig.db", which is my suite configuration recordstore named PSConfig. By copying this to e.g. "Copy of 00000002_PSC_onfig.db" it will not be deleted. After NetBeans have cleaned up, just copy it back to its original name.
The next time you hit run in NetBeans your recordstore will be there. It's pain, but at least it gives you the possibility to use the emulator to debug your RMS handling.

This question has been around for a while but I stumbled upon it whilst looking for an answer to the same problem with the emulator but in my case it was when using the Java ME 3 SDK. It is possible that the solution I found might also fix this problem.
Using:
emulator -Xdescriptor:/path/to/app.jad
will according to the docs: "Install a MIDlet, run it, and uninstall it after it finishes."
To persist an installation (and it's data) you should use:
emulator -Xjam:install=<JAD-file-URL>
The JAD file URL can either be a web address or 'file:///path/to/app.jad' if you want to install from your local file system. This installation command will display an application storage number which you can then use to launch the emulator and run the previously installed app by calling:
emulator -Xjam:run=<application-storage-number>
See the docs for further command line options.

I could finally get it to work on a real handset. It seems that, as Martin Clayton suggested, the emulator reset erased the data. I'm still looking for a way to enable persistence in the emulator though.

If you are using windows Vista there can and almost are permission issues. I am not sure how to resolve this but you might want to check that the user that is running the emulator has access to write to the emulator store.
In appdb/$phone/*.db

to fix the storage problem you need to check the option "Storage size" in the netbeans platform manager.
Go in project properties;
go in platform;
manage emulators;
select the sun java wireless toolkit;
go in Tools and Extensions;
open preferences;
storage;
storage size option... set a size.
this works for me

I experienced the same issue on Ubuntu Linux and working with WTK 2.5.2 and Netbeans 8.0.2. I later figured it was caused by shutting down my laptop without closing the emulator. It also happens if you run a second emulator without shutting down the first.
My solution is based on the Best Answer here, just shut down all emulators and delete the file located at
~/j2mewtk/2.5.2/appdb/DefaultColorPhone