I'm working on a library that will translate all the hard-coded strings in swing.
I have, with some help, managed to find all the strings related to it, so that's a start. However, I have noticed that upon trying to rename a file in JFileChooser to a name that was already taken, I get an error dialog saying that I can't do that.
Was this Java, or was it Windows (OS on which the program was ran)?
If it was Java, I'd like to know more about how to customize such a JDialog, and if it was Windows, there's not much I can do, especially since the program is supposed to be cross-platform.
You can find the source code of your JDK in the directory you installed it in.
In the openJDK-7 implementation the String you are looking for is defined in the
package com.sun.swing.internal.plaf.basic.resources and the file basic.java.
The other files in this directory correspond to the different translations:
basic_de.java, basic_es.java, ..., etc.
There are all the String constants that are used by the Swing classes.
Amongst them:
{ "FileChooser.renameErrorFileExists.textAndMnemonic",
"Cannot rename {0}: A file with the name you specified already exists. Specify a different file name." },
So you will have to find a way to override the Attribute FileChooser.renameErrorFileExists.textAndMnemonic to change this dialog.
If you want to translate these strings refer to this answer.
Different Java installations might have different Strings there since these Files are not part of the official Java API.
As far as I can tell these files are not contained in the src.zip that is distributed by Oracle.
Related
This question already has answers here:
Can I list the resources in a given package?
(4 answers)
How to list the files inside a JAR file?
(17 answers)
Closed 5 years ago.
I am not convinced that it gives me all possibilities for my problem 1) xso said it was not a good answer 2) I would like to find an easiest solution 3) I doesn't address my question why browse the files in a jar has to be different as browse the files in the file system 4) it is an old thread, maybe it changed in Java 8 or Java 9 or in another library ?
even the new link doesn't convince me. Where is addressed the problem to find directories in directories ? Here it is only files in the jar. In my case, I don't know (and I don't want to know) the list of animals, the list of colors,...
I am developing games for eye-trackers (http://gazeplay.net). These games are done in particular for disabled children and their parents are often not accustomed to use computers. Hence, I try to release a software as easy as possible to run.
I have made it with java/javafx. My soft has to be downloaded as a jar and double clicked.
In a new game, the idea is to show some pictures to the child, a voice gives the order and (s)he stare at the correct one. For instance, « Where is the elephant ? » and the child has to select the elephant. It can be the same with colors, cartoon characters,… I tried to do something as generic as possible hence for animals, all are ordered in an « animals » directory where there is a directory for each animal (one for horses, one for eagles,…) and in each directory several images. It is hence easy to add a new animal (just need to add a directory) and easy to add a new picture (add it to the directory). It is easy to make a new game, build a new hierarchy of directories (one for colors, one for cartoon characters,…). Here is an excerpt of my actual directory structure.
actual directory structure
It works pretty well in my IDE but unfortunately it doesn’t work in my jar. It seems easy to show an image if you know its complete path but impossible to use functions as File listFiles(). I try to find solutions but they don’t seem to work. Some people seem to say that is it is possible with nio but I was not able to make it works.
I have two questions :
is it possible and if no, why is it impossible ? Folders exist in my jar, they don’t disappear, why is there no way to list their content ?
If no, how can I implement a solution as easy as possible ?
Thank you !
When you run code in IDE, it typically uses the files and directories as they are. When you pack the app into a JAR, they are packed into one file, so you get the issues you describe.
Both ways work, because when you run an app, it uses a so-called classpath to find stuff, and you can put both locations of directories and locations of jar files in the classpath, and Java automatically supports both. Normally, when it's used for code and known resources, it's all handled automatically, so you don't have to deal with it, but to discover stuff, you'll have to write some code yourself..
So, if you'd like to discover what files are available, you'll have to look at the classpath, then check for each entry if it's a directory or a jar file. For scanning directories, you can use the Files api, which you're already doing, and for scanning JAR files, you should probably use the JarFile API.
In particular - the Applet.class. How could I find where it locally resides? I have tried the following, but I get an exception:
System.out.println(JApplet.class.getProtectionDomain().getCodeSource().getLocation().getPath());
It is of course somewhere in Program Files/Java/jdk_7_xx/ but I have had quite a look around and searched online and cannot find the answer. I have always wondered where specific classes reside on the system.
Note: If you want some more detail (not necessary to read below this):
What I specifically want to do is edit the Applet.class and point my Eclipse to a new JRE System Library that contains the edited Applet.class. In theory this sounds plausible, yet in practice I am unsure.
This is needed so I can test legacy code which keeps making calls to super methods - I have tried many frameworks/approaches and tried multiple possible solutions that have been posted on stack overflow and other online resources - none work.
Found the JApplet.class in C:\Program Files (x86)\Java\jdk1.7.0_25\jre\lib\rt.jar
Made a back-up of jdk1.7.0.25 on my desktop and put it in a folder Desktop\BACKUP\jdk1.7.0.25
Unzipped it (rt.jar), decompiled Applet.class with jad, changed some methods and even added a new one, recompiled it, rezipped it, replaced the old rt.jar with the new one, made a new eclipse project and made it use the JRE in Desktop\BACKUP\jdk1.7.0.25 and it worked perfectly.
..do you know how I can find the specific path of the Applet.class?
For your own PC? Sure. For the PC of a client of your applet? No.
In fact, Oracle (or was it Sun?) eventually decided it was not the business of an app. launched within the Java Plug-In (e.g. applets or JWS apps), to know where the classes were cached. Not even it that app. was fully trusted.
I'm assuming its in a jar somewhere?
Don't assume. It is set in the Java Control Panel, which defaults to 'no compression'.
I would like to associate a specific file type with my application, so when I double-click one of the files of this specific type, my application opens. This works just fine, but the file I double-clicked does not get passed as an argument to my program.
If I for instance associate my application with txt files and I double-click todo.txt, my application opens, but I have no idea which txt file I double-clicked.
From what I can read, this is how it's supposed to work on OS X, and instead of relying on the default behaviour (how it works on e.g. Windows), I should use ApplicationListener.handleOpenFile(); from com.apple.eawt. When I attempt this, however, I'm being told that I'm not allowed to do so:
Access restriction: The type ApplicationListener is not accessible due
to restriction on required library
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
In another question here, one guy says he found the solution on some Chinese website, and the other says it isn't legal according to Java's license agreement terms.
I can find no mention of it in the Mac OS X Developer Library, and whatever links might seem useful on this site about JAR Bundler just sends me to a dead page on Apple's Developer site.
What am I missing? Is it supposed to be nearly impossible to do this, even though it's trivial on other operating systems?
It's probably worth mentioning... since JARfiles can't be associated with programs on OS X, I've created an OS X Application Bundle using JAR Bundler; an Apple tool made specifically for the purpose of being able to treat Java applications as native OS X applications. Using this is what allowed me to associate the file type with my application in the first place.
I've used OSXAdapter for preferences, about, and quit functionality. You might be able to leverage it's introspective approach to avoid the restriction. As com.apple.eawt.ApplicationListener is deprecated, you might try com.apple.eawt.OpenFilesHandler instead.
For whatever reason, I sometimes need to find the current user's My Documents folder on Windows in a Java program to read some files. But as far as I can tell, there is no way to do it that isn't severely flawed.
The first wrong way: System.getProperty("user.home");
Why it won't work:
It only returns the \username\ folder; I'd need to add "\Documents\" on to the end to get the Documents folder... and that only works in English.
Sun bugs 6519127 and 4787931. Java finds the user home folder on Windows by reading a deprecated registry key* to find the Desktop then taking the parent; this method has multiple known problems that will easily cause a completely wrong folder to be returned. The bugs are 3.75 years and 8 years old with no fix.
The second wrong way: Using a registry-reading program to get the Personal folder of the user, which is My Documents (but i18n'd).
Why it won't work:
While it fixes the English-only problem, it's still using the same deprecated registry area, so the bugs still apply to it.
The deprecated registry key says to use a native call (SHGetKnownFolderPath) which I obviously can't do from Java.
The third wrong way:
JFileChooser fr = new JFileChooser();
FileSystemView fw = fr.getFileSystemView();
File documents = fw.getDefaultDirectory();
Why it won't work: It works great!
Except when it doesn't. While I had a program that used this open and running in the background, I opened a DirectX game (Fallout: New Vegas). The Java program immediately terminated with no stack trace. Always reproducible (for me on that game, and who knows what else). Couldn't find a Sun bug#.
So is there any method to find a user's Documents folder, on Windows, from Java, that doesn't have known problems?
(This is a nice big question.)
*(The key is "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders")
There's no pure java way to do it, but you could use the JNA wrapper over JNI to do it without having to write any native code yourself. There's a good example of how to get the Documents folder on Windows halfway down the responses at:
What is the best way to find the users home directory in Java?
A time consuming, but reliable way of finding the 'Documents' folder of a windows user: Make your java app execute a bat script that uses Reg.exe (a windows system file) to find the value of the reg key which has the path in it. Then use a pipeline in the same bat file to send that data to the 'findstr' function which windows command prompt has. Use another pipeline to output the returned value to a text file. Then, simply make your java app read that text file, and delete it once its done :) Worked well enough for me.
Code for the bat file:
# echo off
Title Find Documents Folder
Reg Query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" |findstr "Personal">>DocPath.dat
exit
There is a custom Java API that someone built (their website no longer works), but there code remains on Google Code:
http://winfoldersjava.googlecode.com/files/WinFoldersJava_1.1.zip
There are two DLL's that need to be referenced, one for each architecture(x86 and x64).
user.home is not "my documents", but users home folder, like on Unix ~/.
To get to "My documents" you can use System.getProperty("user.home")+"\Documents"; irrespective of the language system. Try it.
I know the following things, and was wondering if they can be combined to make Java use jump-lists in Windows:
Windows displays Jump-Lists for supporting programs when a taskbar icon is right-clicked
C++, C#, F#, and VB support this natively (as shown here)
Java can import native capabilities using the JNA (as shown here)
Anybody have experience they can lend to help me create a jump-list for a Java app?
The J7Goodies library won't work, as it no longer exists.
The word "natively" is overstating the case a bit. WPF provides jump list support. That's not the same as C# providing it. (For Windows Forms people there's the Code Pack which is a set of managed wrappers.) And MFC provides jump list support which is also not the same as C++ providing it. Anyway, there are two things going on here. One is adding files you opened recently to that jumplist, which under some circumstances you can get for free. The other is adding arbitrary files (typically starting point templates etc) to the jumplist.
To add a file to the recent/frequent list, you call SHAddToRecentDocs, though you may not have to if, for example, you use the Common File Dialog control to open files, and/or the user double-clicks files to launch your app and open them (you have the file type registered.) Lots of folks suggest calling it anyway to be on the safe side. To add any old thing to the jumplist see http://msdn.microsoft.com/en-us/library/dd378402(v=VS.85).aspx.
How to call those from Java, I forget, but I hope they get you started.
There is a Java library providing the new Windows 7 features for Java. It's called J7Goodies by Strix Code. You can create your own jump lists with it.