Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / September 2007

Tip: Looking for answers? Try searching our database.

How to save a new data file inside the executable JAR package?

Thread view: 
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.