So right now I´m trying to load an Image on my Harddrive in a BufferdImage in my Code. Yet I think I did everything right but my trycatch only leaves the catch.
Code for better understanding :
private static BufferedImage image;
public void initPictures() {
try {
image = ImageIO.read(new File("Pictures/blue.png"));
} catch (IOException ex) {
System.out.println("Will not load");
ex.printStackTrace();
}
}
The initPictures() is called in my Constructor of the Class. And you can see here that my picture that I try to load is in the E:\Dropbox\Dropbox\Java Projekte\FallingBlocks1\build\classes\Pictures folder on my OS. So the "Pictures/blue.png" should be good.
Windows Folder Picture:
So my Qustion here is : What am I missing?
EDIT : added ex.printStackTrace(); nothing changed thought.
EDIT : also tried to load other pictures int the "image", with no other results
There are two possibilities:
1. Your program may not be running in the folder that contains the "Pictures" folder.
To find out where your program is running, do a System.out.println(System.getProperty("user.dir")); to see what folder you're running in. If it prints something other than E:\Dropbox\Dropbox\Java Projekte\FallingBlocks1\build\classes, you know it's an issue with the path you're providing to ImageIO.read(file). For kicks, you may also want to see what new File("Pictures/blue.png").isFile() is returning.
2. Your image might not readable.
If you try the first test out and you know for certain that the path you are providing is correct, then it's likely that your image file is either corrupt or cannot be read (could be caused by access restrictions, connectivity problems, hardware issues, etc.). Try pointing to a different image and see what happens.
Related
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.
I know it's not a good practice to catch errors, but in this case, it's important to do it. I'm trying to run a jar which contains a part of my game, but it's giving me an unsatisfiedlink error, but here's it's the funny part:
I'm using this code:
System.setProperty("org.lwjgl.librarypath", new File("lib/natives").getAbsolutePath());
But in netbeans, it's giving me this error, BUT, the jar runs. Now, if i change to code, to this:
System.setProperty("org.lwjgl.librarypath", new File("Dist/lib/natives").getAbsolutePath());
Now, it runs in netbeans, but the jar it's not working... and i don't get it!, so, i'm trying to use a try/catch to use either of both, and well this is the complete code:
try{
System.setProperty("org.lwjgl.librarypath", new File("lib/natives").getAbsolutePath());
}
catch (UnsatisfiedLinkError e){
System.setProperty("org.lwjgl.librarypath", new File("dist/lib/natives").getAbsolutePath());
}
and when I run it in netbeans, it's giving me the error of the first line, not an error of the catch part. What's going on? Thanks in advance friends!
In code like this:
new File("Dist/lib/natives").getAbsolutePath()
you are giving a path "Dist/lib/natives" relative to JRE "user" (or working) directory. Relative to the value of the system property "user.dir". The value of this property is set on startup of the JVM, and can vary depending on how the JVM is started. You should print or log the value of 'user.dir' and observe the difference in each startup-case mentinoed in your question to understand what is going on.
System.ou.println(System.getProperty("user.dir"));
I've been making a 2D game with my buddy and I've been learning a lot about some basic game dev concepts through some Youtube tutorials. One of the things I was learning about is sprites (for those that don't know, 2D images to render to the screen) and how to use them in my game. I've been using ImageIO.read(this.class.getResource(pathToMySprite)) but it seems that getResource() is returning null for some reason.
I've been screwing around with the path a little, adding "/" in front of it, removing "/", putting the user.dir property to see if it needed the whole path, and I'm still getting the same error.
TILE_TEXTURES(System.getProperty("user.dir") + "/textures/tile.png");
//ENTITY_TEXTURES("/textures/entity.png");
private BufferedImage img;
private SpriteSheet(String path) {
System.out.println(System.getProperty("user.dir"));
try {
//TODO: Fix this error, don't know what's wrong.
img = ImageIO.read(SpriteSheet.class.getResource(path)); // error here!!!
} catch (IOException e) {
e.printStackTrace();
}
}
public BufferedImage getImage() {
return img;
}
Any and all help is appreciated.
I haven't been commenting the code (I usually do that when I get to place where I can sit back and be happy with what I've finished) but it's a pretty small class so I think you guys will be able to understand what's going on just fine.
The folder that holds the image IS in the class path of my project.
I've also included the error:
Exception in thread "Thread-2" java.lang.ExceptionInInitializerError
at com.brickbattle.client.src.gui.Sprite.<clinit>(Sprite.java:7)
at com.brickbattle.client.src.objs.Tile.<init>(Tile.java:67)
at com.brickbattle.client.src.objs.Player.initPlayerNum(Player.java:19)
at com.brickbattle.client.src.util.BrickBattle.init(BrickBattle.java:114)
at com.brickbattle.client.src.util.BrickBattle.run(BrickBattle.java:85)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: input == null! //HERE IS ERROR
at javax.imageio.ImageIO.read(Unknown Source)
at com.brickbattle.client.src.gui.SpriteSheet.<init>(SpriteSheet.java:17)
at com.brickbattle.client.src.gui.SpriteSheet.<clinit>(SpriteSheet.java:8)
Thanks again!
This problem is basically unrelated to ImageIO, but rather how Class/ClassLoader.getResource or getResourceAsStream works.
For an explanation, see this answer.
In any case, these ways of obtaining a resource will only be able to read from classpath (ie. user.dir will never help here).
This should work:
ImageIO.read(getClass().getResource("/path/to/resource"));
Where the path is relative to the root of the classpath (specified by the leading /).
If your resources are not on the classpath, simply use:
ImageIO.read(new File("path/to/resource");
Where the path is relative to the directory your application was launched from.
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;
}
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