making a program work on another computer (beginner question)

[rfractal30]

Hi

I've got a question about transferring a program I created to another
computer. Am I right in thinking that I will have to include in my 'Jar
file' every custom made package which contains classes which I have
used within my application - even if I have used only a very few
classes from that package?

Or is it the case that when a java source file has imports of classes
from a package - then at compilation time those imported files become
merged with that class; and therefore that class becomes self contained
and would not need to 'carry' the other classes with it, when it is
transferred onto another computer system?

This is how I see it:

---
import myroot.myclasses.ClassY;
import myroot.myclasses.ClassZ;

public class ClassMain {}
---

So - when I compile ClassMain - am I right in thinking that ClassY and
ClassZ have been merged with ClassMain (assuming that they have
definitely been used within ClassMain). If this is the case, I should
be able simply transfer ClassMain onto another computer - without
needing to include package 'myroot' when I put it into a Jar file.
Thanks for any help - Michael

 

[Bjorn Abelli]

...

I've got a question about transferring a program I created to another
computer. Am I right in thinking that I will have to include in my 'Jar
file' every custom made package which contains classes which I have
used within my application - even if I have used only a very few
classes from that package?

No, you only have to include those *classes* that are actually used.

Note, that this could though mean that there are more classes needed than
those you explicitly use in your program, if any of those "imported" classes
in turn needs other classes to work...

So, if you're uncertain of how these classes are linked to other classes in
the "custom made packages", the *safest* is to include all of them...

Or is it the case that when a java source file has imports of classes
from a package - then at compilation time those imported files become
merged with that class; and therefore that class becomes self contained
and would not need to 'carry' the other classes with it, when it is
transferred onto another computer system?

No, Java does not use "static linkage", only "dynamic linkage".


// Bjorn A

 

[rfractal30]

...


No, you only have to include those *classes* that are actually used.

Note, that this could though mean that there are more classes needed than
those you explicitly use in your program, if any of those "imported" classes
in turn needs other classes to work...

So, if you're uncertain of how these classes are linked to other classes in
the "custom made packages", the *safest* is to include all of them...

O.k, I think I understand what you are saying. But this has thrown up
alot of new questions! Firstly, you say that I would only need those
classes which I am actually using. Given that this is risky - let's say
I decide to try this option... I'm assuming that when I come to include
these 'required' classes in my JAR file - that I will need to keep the
same 'directory' structure - otherwise the import statements will be
looking for the files in the wrong places? (if this is the case it
sounds abit fiddley!)

Ok, I'm trying to reach an understanding of how this all works and why!

So I'll take your advice and go to the other extreme: i.e. I'll include
the entire package. In my way of thinking this throws up a whole lot of
other problems. For one thing - it might be a huge directory containing
hundreds of classes - of which I am only using say 5 of them (maybe
these 5 are themselves linked to 15 others - so in all it is around
20).

When I come to publish my application though - I have to send out this
entire package (and all the other packages which only include a few of
the classes actually required) - which is greatly increasing the size
of the application. In my way of thinking this is a problem - although
I think I'm beginning to understand the logic behind this: in effect
you are sending the recipient of your software an extension to their
API (is that the right term?). They are getting a whole lot of 'bonus'
classes which they don't need. Some of these classes might be highly
specialized classes which don't help the application they are running
at all - but which were actually developed to create an application -
which was made to help your Aunty Vera improve her 'Cross Stitching'
repertoire!

I do have a suggested solution - which you will probably tell me is
horribly naive: which is to use an application which will extract the
required classed (including those classes required classes) - and then
put them into a directory structure which mirrors the origional
(assuming that it is necessary to keep the same directory structure).
Does this kind of software to do this kind of stuff exist?
Thanks - Michael

 

[Bjorn Abelli]

...

I'm assuming that when I come to include
these 'required' classes in my JAR file - that I will need to keep the
same 'directory' structure - otherwise the import statements will be
looking for the files in the wrong places?

That's a correct assumption.

In your example you had:

import myroot.myclasses.ClassY;
import myroot.myclasses.ClassZ;

....which if you include them in the same jar-file as your other classes
would have to be as

\myroot\myclasses\ClassY.class
\myroot\myclasses\ClassZ.class

So I'll take your advice and go to the other extreme:
i.e. I'll include the entire package. In my way of
thinking this throws up a whole lot of other problems.
For one thing - it might be a huge directory containing
hundreds of classes

....which in most cases doesn't need to be a problem. My guess is that the
user of your application never "opens" the jar-file, but only "uses" it,
which means that the number of classes never becomes a problem.

The only problem I see with that solution is whether size matters or not.

In my way of thinking this is a problem - although
I think I'm beginning to understand the logic behind
this: in effect you are sending the recipient of your
software an extension to their API (is that the right
term?).

Well...

I wouldn't use that terminology in this particular case,
but I think you're on the right track.

What you do is to provide a bunch of classes, which can or cannot be used
directly by the user.

Every Java-class has an interface, which means they can be "used as an API"
or just plainly "used".

So you could say that you extend their API with the "custom packages", but
so will also the classes you provide yourself.

I do have a suggested solution - which you will probably
tell me is horribly naive: which is to use an application
which will extract the required classed (including those
classes required classes) - and then put them into a
directory structure which mirrors the origional (assuming
that it is necessary to keep the same directory structure).
Does this kind of software to do this kind of stuff exist?

You could look into these, if someone fulfils your needs, I haven't tried
them myself:

http://depfind.sourceforge.net/Resources.html#software

Otherwise, you could always just use "try and error".

Pack your application with the classes you definitely know is needed and try
it on another machine. When you run it, you'll see what other classes you'll
need to pack, as it will give you error messages telling you what is
missing.

// Bjorn A

 

[rfractal30]

...which in most cases doesn't need to be a problem. My guess is that the
user of your application never "opens" the jar-file, but only "uses" it,
which means that the number of classes never becomes a problem.

The only problem I see with that solution is whether size matters or not.

I guess your right. After all, it's not like the user has a whole load
of my personal information lurking about on their hard-drive - it's
just innocuous java code. I am slightly curious about the wider
security implications (for commercial software developers and so on)
having so much of their work available to be grabbed by anyone who
wants to take their work and use it for their own purposes. Personally,
I like the concept of software that can be recycled - but I wouldn't
assume that everyone feels this way about it (or rather - is in the
situation to have this liberal/sharing philosophy).

What you said about size I agree with also. After all, computers
generally have so much hard-drive space these days that it is hardly a
problem.

You could look into these, if someone fulfils your needs, I haven't tried
them myself:

http://depfind.sourceforge.net/Resources.html#software

I looked at this page. Some of the software recommend there, e.g.
'review' looks interesting. If I could afford it I might try it out.
Thanks for your patient advice!

- Michael

 

[Bjorn Abelli]

...

I looked at this page. Some of the software recommend there, e.g.
'review' looks interesting. If I could afford it I might try it out.

Just for the record, much of the software listed on that page is freeware,
just as Dependency Finder itself, where I found that list.

http://depfind.sourceforge.net/


// Bjorn A

 

[rfractal30]

I do have a suggested solution - which you will probably tell me is
horribly naive: which is to use an application which will extract the
required classed (including those classes required classes) - and then
put them into a directory structure which mirrors the origional
(assuming that it is necessary to keep the same directory structure).
Does this kind of software to do this kind of stuff exist?

http://www.tiobe.com/jdeploy.htm

 

[Rogan Dawes]

I do have a suggested solution - which you will probably tell me is
horribly naive: which is to use an application which will extract the
required classed (including those classes required classes) - and then
put them into a directory structure which mirrors the origional
(assuming that it is necessary to keep the same directory structure).
Does this kind of software to do this kind of stuff exist?
Thanks - Michael

ProGuard

http://proguard.sourceforge.net/

Rogan