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

[JTL.zheng]

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]

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.

I think you must make a new package.

 

[Andrew Thompson]

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*?

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[JTL.zheng]

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]

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]

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.

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?

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[Lew]

Now *that's* what I call a goal!

OK - yes this is a relatively common question.


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?

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.

 

[Roedy Green]

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.

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

 

[Roedy Green]

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

 

[Roedy Green]

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.

 

[Andrew Thompson]

Lew wrote:
...

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.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1

 

[Lew]

It's official now? 'Bye bye'* 1.4.

It's been official for over nine months.

 

[Andrew Thompson]

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!

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

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

 

[JTL.zheng]

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]

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

 

[Andrew Thompson]

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>

 

[mekane]

public static void main(String[] args) {
Thread t = new Thread() {
public void run() {
MemoryFrame frame = new MemoryFrame();
frame.setVisible(true);
}
};
SwingUtilities.invokeLater( t );
}
}
</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]

public static void main(String[] args) {
Thread t = new Thread() {
public void run() {
MemoryFrame frame = new MemoryFrame();
frame.setVisible(true);
}
};
SwingUtilities.invokeLater( t );
}
}
</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?

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.

 

[Lew]

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?

 

[Daniel Pitts]

public static void main(String[] args) {
Thread t = new Thread() {
public void run() {
MemoryFrame frame = new MemoryFrame();
frame.setVisible(true);
}
};
SwingUtilities.invokeLater( t );
}
}
</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?

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().

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