How to make java client app to download jar package from server autoly?

[sealo]

Hello,
I want to write a command line java client program. And the program
need to use the jar package, but the package was located in the server.
I want the client program to download the jar package automarically at
the program startup.
I am not familiar with java. Could you tell me how to do it?

 

[Andrew Thompson]

sealo wrote:
.....

I want to write a command line java client program.

Why? Or rather, why would you want to use Java to
program a tool intended to be run from within the
command line, as opposed to a program with a GUI?

..And the program
need to use the jar package, but the package was located in the server.
I want the client program to download the jar package automarically at
the program startup.
I am not familiar with java. Could you tell me how to do it?

If it is the GUI'd program, it could be launched using
web-start, with the Jar file being downloaded lazily
(when 1st needed) or eagerly (at time of first run).

Web-start was designed to launch GUI'd, but not
command line based, client programs.

Andrew T.

 

[Thomas Kellerer]

Andrew Thompson wrote on 31.12.2006 12:54:

sealo wrote:
....

Why? Or rather, why would you want to use Java to
program a tool intended to be run from within the
command line, as opposed to a program with a GUI?

Why not?

It's a very good language to write a cross-platform application be it a GUI or a
commandline app.

Thomas

 

[Andrew Thompson]

Andrew Thompson wrote on 31.12.2006 12:54:

Why not?

1) I expect most things invoked from the command
line to be 'quicker than the eye can see'. Which is
not the case with any Java application, where the
JVM needs to load, loads some basic classes, load
the appliaction classes, and run.

2) Java is not well suited (from what I understand) to
adding those 'little extras' that make CLI based
programs better/bearable. Font colors, 'menus' etc.

It's a very good language to write a cross-platform application be it a GUI or a
commandline app.

I disagree with the latter, unless you are referring
to starting a server (or some other long running
process) from the command line, and also presuming
the application does not need to thereafter gain
input (beyond the very basic) from the end user.
(oh, and of course for those just learning programming,
no need to go rushing into GUI programming until
you've got some understanding of the language)

But then, I did want to push the web-start aspect,
which is another plus for GUI'd desktop apps. ;-)

Andrew T.

 

[Thomas Kellerer]

Andrew Thompson wrote on 31.12.2006 14:24:
[...]

1) I expect most things invoked from the command
line to be 'quicker than the eye can see'. Which is
not the case with any Java application, where the
JVM needs to load, loads some basic classes, load
the appliaction classes, and run.

What makes a Java app slow to start is (in most of the cases) the Swing classes
that are loaded. A pure CLI is not that slow nowadays. On my machine I can't
really detect a huge "starting phase" for e.g. a Hello World program (especially
not with Java6). Of course it depends on what the program is doing.

C:\>date +%s
1167572635

C:\>java Hello
Hello, world

C:\>date.exe +%s
1167572636

(date is a small unix utility that can output the current seconds since
00:00:00, Jan 1, 1970)

As you can see running Hello.java only took one second, which I consider
acceptable for a CLI program.

2) Java is not well suited (from what I understand) to
adding those 'little extras' that make CLI based
programs better/bearable. Font colors, 'menus' etc.

Agreed, although my understanding of a CLI is, that you invoke the program, it
carries out it's tasks and then ends. When menus come into play, I'd call it a
text-mode-GUI. But then that is probably personal "taste"

Thomas

 

[Patricia Shanahan]

1) I expect most things invoked from the command
line to be 'quicker than the eye can see'. Which is
not the case with any Java application, where the
JVM needs to load, loads some basic classes, load
the appliaction classes, and run.

Presumably a program that needs to download part of itself from a server
is not going to be a "quicker than the eye can see".

My current research project involves a lot of simulations. I do all my
development, including testing, on various Windows XP machines. However,
they are useless when I need to do a hundred runs with different
parameters, some taking hours.

Fortunately, I have access to a Linux grid computer where I can do up to
64 jobs at a time.

A GUI would be a disaster for this type of work - there is no way I'm
going to manually enter the parameters for each simulation individually.

2) Java is not well suited (from what I understand) to
adding those 'little extras' that make CLI based
programs better/bearable. Font colors, 'menus' etc.


I disagree with the latter, unless you are referring
to starting a server (or some other long running
process) from the command line, and also presuming
the application does not need to thereafter gain
input (beyond the very basic) from the end user.
(oh, and of course for those just learning programming,
no need to go rushing into GUI programming until
you've got some understanding of the language)

But then, I did want to push the web-start aspect,
which is another plus for GUI'd desktop apps. ;-)

You did give me the impression that you thought that Java should only be
used for GUI programs. It seems now that you think it should not be used
for two special classes, non-GUI programs that need fancy console
interaction with the user, and quicker-than-the-eye-can-see programs.

Since I would use a GUI if I wanted user interaction with color etc.,
and most of my programs would take long enough to be visible anyway, I
think I'll go on using Java for command line application programming.

Patricia

 

[Patricia Shanahan]

Hello,
I want to write a command line java client program. And the program
need to use the jar package, but the package was located in the server.
I want the client program to download the jar package automarically at
the program startup.
I am not familiar with java. Could you tell me how to do it?

Does the jar in question contain the whole program, or just a part of
it? In particular, is the main that you want run in that jar?

Patricia

 

[Christopher Benson-Manica]

I disagree with the latter, unless you are referring
to starting a server (or some other long running
process) from the command line, and also presuming
the application does not need to thereafter gain
input (beyond the very basic) from the end user.

One possibility that you omitted is an application invokable with
either a command-line or GUI interface. If need be, the command line
version can include a JMX interface for interacting with it, which is
much better than nothing, or can merely be a scaled-down version of
the GUI program for use with command-line arguments in batch mode.

 

[Andrew Thompson]

Patricia Shanahan wrote:
.....
(snip)

Fortunately, I have access to a Linux grid computer where I can do up to
64 jobs at a time.

A GUI would be a disaster for this type of work - there is no way I'm
going to manually enter the parameters for each simulation individually.

I don't get it. What 'non-manual' way is there to
enter parameters to a CLI based program, that is
not *also* available to a GUI'd program (if not in
the same exact way, then in some similar form)?

Andrew T.

 

[Tom Hawtin]

What makes a Java app slow to start is (in most of the cases) the Swing
classes that are loaded. A pure CLI is not that slow nowadays. On my
machine I can't really detect a huge "starting phase" for e.g. a Hello
World program (especially not with Java6). Of course it depends on what
the program is doing.

(date is a small unix utility that can output the current seconds since
00:00:00, Jan 1, 1970)

time is more appropriate (or ptime on Solaris):

$ time java Hi
Hello world

real 0m0.156s
user 0m0.052s
sys 0m0.020s

156 ms for running it first time. Almost good (for interactive work).
Perl does it in 7 ms. A responsive program should be in the range 50 -
140 ms.

I suppose you could start a Java process on a well known port/pipe and
connect to it from something simple.

Tom Hawtin

 

[Patricia Shanahan]

Patricia Shanahan wrote:
....
(snip)

I don't get it. What 'non-manual' way is there to
enter parameters to a CLI based program, that is
not *also* available to a GUI'd program (if not in
the same exact way, then in some similar form)?

Andrew T.

The way I use is a make file that looks at the set of parameter files in
the working directory, and generates a task for each parameter file
using it as input and a result file whose name is based on the parameter
file name as output.

There are all sorts of automation and mass production techniques that
can be used to generate, edit, and manage a collection of small, closely
related, structured text files without editing each of them individually.

Patricia

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

sealo wrote:
....

Why? Or rather, why would you want to use Java to
program a tool intended to be run from within the
command line, as opposed to a program with a GUI?

I think that many people write command line
(console) programs.

Easier to script. Can be run via a simple telnet
connection. In some cases even faster to just write
the right command line arguments.

Arne

 

[Guest]

I want to write a command line java client program. And the program
need to use the jar package, but the package was located in the server.
I want the client program to download the jar package automarically at
the program startup.
I am not familiar with java. Could you tell me how to do it?

It should be possible to use an URLClassLoader to
do that.

Arne

 

[Andrew Thompson]

It should be possible to use an URLClassLoader to
do that.

Of course it is. Many things are possible.

OTOH, I think it might profit the OP to fill in
some of the answers to the questions already
raised on this thread (with particular attention to
how the application is used/scripted, and what it
does) before we begin to consider the best way
to deliver the required functionality to the end-user.

To put that another, simpler way.

I *suspect* the OP is not approaching the
final objective (the goal) with the best strategy,
and until we know what that objective is -
we cannot really help solve it.

( Of course, I might also be accused of snobbily
'holding on to the answer - until the OP
negotiates the standard obstacle course'
...but I don't see it that way

Andrew T.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Of course it is. Many things are possible.

OTOH, I think it might profit the OP to fill in
some of the answers to the questions already
raised on this thread (with particular attention to
how the application is used/scripted, and what it
does) before we begin to consider the best way
to deliver the required functionality to the end-user.
>
> To put that another, simpler way.
>
> I *suspect* the OP is not approaching the
> final objective (the goal) with the best strategy,
> and until we know what that objective is -
> we cannot really help solve it.

I doubt it.

He stated command line program.

You started a weird subthread arguing that the OP
should use a GUI instead.

A discussion I consider rather pointless.

He asked a question about a command line program.

There are nothing wrong with using a command line
program.

He could rewrite it to be GUI.

He could also rewrite it to Python.

Since there are no technical reasons not to do
what he are doing, then I would not suggest
rewriting to GUI or rewriting to Python or
anything else.

Arne

 

[Andrew Thompson]

....
The way I use is a make file that looks at the set of parameter files in
the working directory, and generates a task for each parameter file
using it as input and a result file whose name is based on the parameter
file name as output.

There are all sorts of automation and mass production techniques that
can be used to generate, edit, and manage a collection of small, closely
related, structured text files without editing each of them individually.

....mmm, Yeh-OK ..but

At some point, the 'operator' (I am not quite sure, from
your description above, whether you are referring to things
as you might expect your *end* *users* to see, or whether
you are refering to your own builds and such) needs to
'choose a file' to run, right?

I mean, the scenario above seems to link it all
to the 'current directory', so how about this?

Instead of navigating to the correct directory
and 'starting the application' as it seems the
minimum might be for this process to happen,
the user simply 'starts the application' - which
then produces a dialog asking ..
'Current Directory? Yes/No'
...if the user answers 'yes' it proceeds, if 'no',
it shows a JFileChooser to navigate to whatever
directory the process should be performed in.

Which brings me back to the point that a GUI'd
application could not only do what you described
(as far as I vaguely understand it), but do it
(slightly) more easily/slickly for the end user.

...sure it means more programming, but even for things
that I design for running in a headless environment,
if I intend to run them more than a handful of times,
I will 'wrap a GUI around it' as well.

[ It seemed to take a lot of words, to get to that
minor point.. ]

More closely focused on the OP's statement to
'use a command line' (presumably as opposed
to using a GUI), I will stress that *most* command
line apps. could be 'fitted' with a GUI if 'needed',
for instance, if you wanted to launch using
web-start..

(pauses, considers..)

You know, I never have checked specifically,
whether web-start *can* launch command-line apps. -
its just I cannot see how the user could easily
specify input, or view output - of a command-line
based, web-start application...

(wander off slowly, muttering.. '2007, already?')

Andrew T.

 

[Patricia Shanahan]

...mmm, Yeh-OK ..but

At some point, the 'operator' (I am not quite sure, from
your description above, whether you are referring to things
as you might expect your *end* *users* to see, or whether
you are refering to your own builds and such) needs to
'choose a file' to run, right?

I'm my own end user. This is a research project in which I am using a
simulation as a tool. I want to optimize my total time, which means I'll
do infrastructure programming if, and only if, the result will save me
more time than it costs.

I mean, the scenario above seems to link it all
to the 'current directory', so how about this?

Instead of navigating to the correct directory
and 'starting the application' as it seems the
minimum might be for this process to happen,
the user simply 'starts the application' - which
then produces a dialog asking ..
'Current Directory? Yes/No'
..if the user answers 'yes' it proceeds, if 'no',
it shows a JFileChooser to navigate to whatever
directory the process should be performed in.

I generally leave a PUTTY window on the grid computer's control server,
sitting in the right directory. The actual actions to fire up a series
of runs, once I have the parameter files, is something like "!qm"
followed by enter. I'm a touch typist, so the time for four keystrokes
can be ignored - most of the time is bringing up the right window, which
I would have to do anyway.

Which brings me back to the point that a GUI'd
application could not only do what you described
(as far as I vaguely understand it), but do it
(slightly) more easily/slickly for the end user.

..sure it means more programming, but even for things
that I design for running in a headless environment,
if I intend to run them more than a handful of times,
I will 'wrap a GUI around it' as well.

I think you are underestimating the cost. If I were not using qmake I
would have to have some other grid-aware program throwing jobs at the
grid's queues, keeping track of the number of jobs, and adding more when
there is more work to do and the number of jobs is under the limit. Why
reinvent the wheel?

Moreover, the simulator itself would still be a command line program,
because it has to be something I can ship to a grid queue, and in any
case I don't have time to interact with them individually. A batch may
contain over a hundred runs, and up to 50 of them can be running at any
one time.

Patricia

 

[sealo]

Hello, dear all,
I just want to write a simple command line java app in linux. Don't
want to cost any effort on the GUI design. Because the client need to
use the jar package in the server, so it need to download to local
firstly. And the interface in the jar package are already known. The
client just need to get the jar package and use it.
Thanks all of you!

Maybe, like Arne said, I will try to use "URLClassLoader" to have a try.

 

[Andrew Thompson]

sealo wrote:
...

..I will try to use "URLClassLoader" to have a try.

Are you going to cache the jar locally, for future use?

Andrew T.

 

[sealo]

I think it will be a cache usage.

sealo wrote:..


Andrew T.