Java Forum / General / September 2007
How to save a new data file inside the executable JAR package?
JTL.zheng - 26 Sep 2007 14:32 GMT How to save a new data file inside the excutable JAR package?
if only -- new File("text.dat") it will save the file in the folder where the jar file live in. I want to save the file inside the jar package.
Thank you very much in advance.
neo - 26 Sep 2007 15:25 GMT > How to save a new data file inside the excutable JAR package? > [quoted text clipped - 4 lines] > > Thank you very much in advance. I think you must make a new package.
Andrew Thompson - 26 Sep 2007 15:28 GMT >How to save a new data file inside the excutable JAR package? A Jar and a package are very different things. One jar might contain classes from many packages, while the classes of one package might also be spread across a number of Jar files. The latter is uncommon, and does not make much sense, but it is possible.
>if only >-- new File("text.dat") >it will save the file in the folder where the jar file live in. >I want to save the file inside the jar package. Unpack the jar, then repack it with the new file.
What ability are you attempting to offer to the end user by doing that?
And assuming I recall your earlier questions correctly, I will ask you to please try and separate strategies from goals. Most of the time, the strategy is the entire wrong way to achieve the goal. It is much easier to help when we understand the goal.
As an example. Goal - Offer the user the option to store program preferences between runs, without cluttering their disks with a load of files. Strategy - Put the data in a file and hide it inside the executable jar.
Note that I can think of a number of ways to achieve that goal, but *nothing* that justifies that strategy.
So - what is the actual *goal*?
 Signature Andrew Thompson http://www.athompson.info/andrew/
JTL.zheng - 26 Sep 2007 16:05 GMT > So - what is the actual *goal*? I have made a jar application, it's a JFrame. when the user close the app, I want to save the JFrame's location and size inside a file. so that the next time when the user run it again, it will be the loaction and the size of last time it has been. and I don't want to save the data file outside the jar file, can I save it inside the jar?
>Unpack the jar, then repack it with the new file. how can I do that? can you give me the codes? or is there any other way easier?
lord.zoltar@gmail.com - 26 Sep 2007 16:45 GMT > >Unpack the jar, then repack it with the new file. > > how can I do that? can you give me the codes? > or is there any other way easier? Sorry, I don't have any code readily available, but you will probably want to start looking at the java.util.jar package.
Andrew Thompson - 26 Sep 2007 16:49 GMT >> So - what is the actual *goal*? > [quoted text clipped - 3 lines] >so that the next time when the user run it again, it will be the >loaction and the size of last time it has been. Now *that's* what I call a goal!
OK - yes this is a relatively common question.
>and I don't want to save the data file outside the jar file, can I >save it inside the jar? As I mentioned, that is *theoretically* possible, but a great deal of hassle. I have never actually attempted it myself.
How about these different strategies instead?
1) For Java 1.4+ applications, use the Preferences class. This is 'transparent and invisible' to the end user. Lew is fond of reminding me that Java 1.4 is about to enter its End-Of-Life phase, so I am guessing most development is for Java 1.4+ VMs. 2) For a Java Web Start app., look to the PersistenceService class. This is also 'transparent and invisible' to the end user, and has the advantage that even sandboxed JWS apps. can use it. Here is an example.. <http://www.physci.org/jws/#ps> 3) (Is Lew looking?) For *pre* 1.4, non JWS apps., there is yet another strategy. Use the Properties class to create the file, then put it inside a special directory on the path of the user.home. I say 'special' because we want to .. a) ensure no other application overwites the file, and this file is not likely to overwite the files of other apps. To do that, put the file in a sub-directory that is based on the package name of the main class. E.G. com.ourcompany.theapp.OurApplication ..class would store preferences in.. (user.home)/com/ourcompany/theapp/properties.file b) To 'hide' it, simply prefix the first directory with ".". So..
(user.home)/.com/ourcompany/theapp/properties.file
This will hide the directory to the casually browsing *windows* user, but the directory will still be visible to Mac or Linux users who actually care to browse user home (or indeed a Windows user like myself - who does not agree that *any* files should be invisible). Ultimately, I would not recommend even *trying* to hide files from the Linux user, as they can get quite irritated if developers try to 'hide' things from them.
(I trimmed the last part of your question, in the hope I can steer you in a better direction.)
So what do you think? Do any of those strategies sound like the way to go, for your application?
 Signature Andrew Thompson http://www.athompson.info/andrew/
Lew - 26 Sep 2007 21:56 GMT >>> So - what is the actual *goal*? >> I have made a jar application, it's a JFrame. [quoted text clipped - 53 lines] > So what do you think? Do any of those strategies sound > like the way to go, for your application? One way to unpack JARs and repack them is via the 'jar' tool, an executable program.
Yes,J2SE 1.4 is in End-of-Life. Earlier versions are already dead. Many organizations still prefer J2SE 1.4 to the current version, Goddess knows why. JSE 5 and 6 are so much better. Even JSE 5 is getting hoary and venerable, in I.T. terms.
One possibly nifty aspect of Preferences is that it might use the O.S. registry as its backing store. (I don't think anything about the MS Windows registry is "nifty", though. Unless you're fascinated by pointless destruction.)
Why, oh why, OP, do you not want to store the information in the user's registry or file system? Rebuilding JARs on their file system is actually much more intrusive. It's also messier, and wrong for your goal.
 Signature Lew
Andrew Thompson - 27 Sep 2007 00:11 GMT ...
>Yes,J2SE 1.4 is in End-of-Life. It's official now? 'Bye bye'* 1.4.
* Just the other day I heard someone wanting to back compile an app. for 1.3! I could not be bothered taking them seriously, though.
 Signature Andrew Thompson http://www.athompson.info/andrew/
Lew - 27 Sep 2007 00:17 GMT Lew wrote:
>> Yes,J2SE 1.4 is in End-of-Life.
> It's official now? 'Bye bye'* 1.4. It's been official for over nine months.
> * Just the other day I heard someone wanting to back > compile an app. for 1.3! I could not be bothered taking > them seriously, though. <http://java.sun.com/j2se/1.4.2/index.jsp>
> J2SE 1.4.2 has begun the Sun End of Life (EOL) process. > The EOL transition period is from Dec, 11 2006, > until the General Availability (GA) of the next Java version, > Java SE 7, currently planned for the summer of 2008.
 Signature Lew
Andrew Thompson - 27 Sep 2007 00:38 GMT > Lew wrote: > >> Yes,J2SE 1.4 is in End-of-Life. > > It's official now? 'Bye bye'* 1.4. > > It's been official for over nine months. D'Oh! That's me 'behind the times' already today. And I had not even finished my morning cup of coffee!
> > * Just the other day I heard someone wanting to back > > compile an app. for 1.3! I could not be bothered taking [quoted text clipped - 4 lines] > > J2SE 1.4.2 has begun the Sun End of Life (EOL) process. > > The EOL transition period ... Huh. I recall you mentioning that they usually have the 'current and two previous' versions in usual availability, and the previous version goes into EOL. ..
> > ...is from Dec, 11 2006, > > until the General Availability (GA) of the next Java version, > > Java SE 7, currently planned for the summer of 2008. ..Which is kind of backed up by that specific mention of 1.7. Me thinks they had wanted to EOL it earlier, but got sick of waiting for 1.7 to be ready for 'general consumption'.
(grumbles) I hate Sun's use of 'summer' though. My first thought whenever I read things like that is '*which* damn summer of 2008 - the first or second?'. OK.. it only takes a few moments to realise that is probably from the perspective of their own hemisphere of the globe, but if they were brave enough to name a month, I would not have to 'bother my pretty little head about it'.
Andrew T.
Roedy Green - 26 Sep 2007 22:49 GMT >and I don't want to save the data file outside the jar file, can I >save it inside the jar? Jars are for read-only data. You can construct them on the fly, but even that is a peculiar thing to. See http://mindprod.com/jgloss/zip.html
What would be more likely is to create your files uncompressed, and when you shutdown update a compressed version of them and delete the originals.
You an also GZIP individual files. See http://mindprod.com/applet/fileio.html
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Roedy Green - 26 Sep 2007 22:50 GMT >I have made a jar application, it's a JFrame. >when the user close the app, I want to save the JFrame's location and >size inside a file. the tool for that is called "preferences". See http://mindprod.com/jgloss/preferences.html
In windows it tucks the information away in the registry.
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Roedy Green - 26 Sep 2007 22:33 GMT >How to save a new data file inside the excutable JAR package? > [quoted text clipped - 4 lines] > >Thank you very much in advance. A data file packaged inside a Jar is called a resource, often an image file, e.g. *.png, *.jpg, *.gif.
See http://mindprod.com/jgloss/resource.html http://mindprod.com/jgloss/jar.html http://mindprod.com/jgloss/jarexe.html http://mindprod.com/jgloss/image.html
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
JTL.zheng - 27 Sep 2007 06:13 GMT I think the Preferences class is useful for me. can you give me some codes about how to save data to Windows' register? and how to get the data back?
Roedy Green - 27 Sep 2007 06:41 GMT >I think the Preferences class is useful for me. >can you give me some codes about how to save data to Windows' >register? >and how to get the data back? Have a look at the code in the com.mindprod.replicator.PersistConfigForReceiver.java
You can download the source from http://mindprod.com/products1.html#REPLICATOR
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Andrew Thompson - 27 Sep 2007 06:48 GMT >I think the Preferences class is useful for me. >can you give me some codes about how to save data to Windows' >register? >and how to get the data back? <sscce> import java.awt.Point; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import javax.swing.JFrame; import javax.swing.JTextArea; import javax.swing.SwingUtilities;
import java.util.prefs.Preferences;
class MemoryFrame extends JFrame {
MemoryFrame() { super("MemoryFrame");
JTextArea ta = new JTextArea( "Remembers location.." ); getContentPane().add(ta); pack(); setSize(400,300);
// probably better to use the systemNodeForPackage(this) // form here, but since this class is in the default // package, I'll go with the root prefs. final Preferences prefs = Preferences.systemRoot();
int x, y;
Integer xObj = prefs.getInt( "MemoryFrame.x", 50 ); Integer yObj = prefs.getInt( "MemoryFrame.y", 50 );
x = xObj.intValue(); y = yObj.intValue();
setLocation(x,y);
this.addWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent we) { Point location = getLocation(); prefs.putInt( "MemoryFrame.x", new Integer(location.x) ); prefs.putInt( "MemoryFrame.y", new Integer(location.y) ); System.exit(0); } } ); }
public static void main(String[] args) { Thread t = new Thread() { public void run() { MemoryFrame frame = new MemoryFrame(); frame.setVisible(true); } }; SwingUtilities.invokeLater( t ); } } </sscce>
 Signature Andrew Thompson http://www.athompson.info/andrew/
mekane - 27 Sep 2007 14:19 GMT > public static void main(String[] args) { > Thread t = new Thread() { [quoted text clipped - 7 lines] > } > </sscce> I'm just curious, why do you create a new Thread to open the new MemoryFrame? I would usually just create the new MemoryFrame in main(). What's the rationale here?
Lew - 27 Sep 2007 14:48 GMT >> public static void main(String[] args) { >> Thread t = new Thread() { [quoted text clipped - 11 lines] > MemoryFrame? I would usually just create the new MemoryFrame in main(). > What's the rationale here? The rationale is that it's only safe to do Swing graphics operations from the Event Dispatch Thread. If you haven't been doing that, you've been doing it wrong all this time, and your programs could have lurking bugs.
 Signature Lew
Daniel Pitts - 27 Sep 2007 16:01 GMT > >> public static void main(String[] args) { > >> Thread t = new Thread() { [quoted text clipped - 18 lines] > -- > Lew True, but you should use Runnable, not Thread!
Also, you should use EventQueue.invokeLater(), not the wrapper SwingUtilities.invokeLater().
One of my common approaches (depends on the situation ofcourse) is to make my main class the main frame and the runnable:
public class MyApp extends JFrame implements Runnable { public static void main(String[] args) { EventQueue.invokeLater(new MyApp()); }
public void run() { // set up children components. } }
Lew - 27 Sep 2007 16:57 GMT mekane wrote:
>>> I'm just curious, why do you create a new Thread to open the new >>> MemoryFrame? I would usually just create the new MemoryFrame in main(). >>> What's the rationale here? Lew wrote:
>> The rationale is that it's only safe to do Swing graphics operations from the >> Event Dispatch Thread. If you haven't been doing that, you've been doing it >> wrong all this time, and your programs could have lurking bugs.
> True, but you should use Runnable, not Thread! > > Also, you should use EventQueue.invokeLater(), not the wrapper > SwingUtilities.invokeLater(). I thought the new wisdom was to use SwingWorker, which has marvelous lifecycle methods. <http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html>
That's what Brian Goetz, et al., say in /Java Concurrency in Practice/, anyway.
Of course, they also give the EventQueue advice, I suppose for those situations where you don't need the full power of SwingWorker. They point out that SwingUtilities.invokeLater() is a simple wrapper around the EventQueue call, and exists only for really old versions of Java.
 Signature Lew
JTL.zheng - 27 Sep 2007 17:31 GMT > prefs.putInt("MemoryFrame.x", new Integer(location.x)); where does it put the location.x? how can I find it in registry? or some place else?
> You should read the Javadocs for Preferences. > Have you? I have read it, but not understand...
Lew - 27 Sep 2007 18:19 GMT >> prefs.putInt("MemoryFrame.x", new Integer(location.x)); > [quoted text clipped - 5 lines] > > I have read it, but not understand... If you can elucidate your specific issues with the docs, perhaps we can help explain them.
 Signature Lew
Roedy Green - 28 Sep 2007 00:20 GMT >where does it put the location.x? >how can I find it in registry? or some place else? please read http://mindprod.com/jgloss/preferences.html and follow the links.
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Andrew Thompson - 27 Sep 2007 17:32 GMT ...
>True, but you should use Runnable, not Thread! Some interesting comments. I am going to need to look more closely into this matter. But (yawns) sleepy now.
BTW - was whoever writ those docs for invokeLater(), a fan of 'The Crystals'? My ..extensive music collection includes two songs by The Crystals - & neither of them is "Da Doo Ron Ron". ( I am far too tired to be posting to usenet, at this moment! ;)
 Signature Andrew Thompson http://www.athompson.info/andrew/
Roedy Green - 28 Sep 2007 00:19 GMT >I'm just curious, why do you create a new Thread to open the new >MemoryFrame? I would usually just create the new MemoryFrame in main(). >What's the rationale here? see http://mindprod.com/jgloss/swingthreads.html
invokeLater gets stuff off the Swing thread without the overhead of creating a fat new Thread. It uses the Runnable interface without actually starting a Thread.
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Lew - 27 Sep 2007 14:49 GMT JTL.zheng wrote:
>> I think the Preferences class is useful for me. >> can you give me some codes about how to save data to Windows' >> register [sic]? >> and how to get the data back? There is no guarantee that Preferences will use the Windows registry.
You should read the Javadocs for Preferences.
Have you?
 Signature Lew
Roedy Green - 28 Sep 2007 00:21 GMT >There is no guarantee that Preferences will use the Windows registry. It will be in the registry in Windows. The API leaves the implementation wide open. It COULD be a flat file, or a database.
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Lew - 28 Sep 2007 02:30 GMT >> There is no guarantee that Preferences will use the Windows registry. > It will be in the registry in Windows. The API leaves the > implementation wide open. It COULD be a flat file, or a database. As long as you know that you're running on a JVM that uses the Windows registry.
It seems unlikely that other JVM vendors would do it differently, but there's no requirement that they use the registry even in Windows.
In practice, if you're using Sun's JVM you are all right, but you're really not supposed to care how Preferences stores things, according to the Javadocs.
 Signature Lew
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|