B
Bender
Can anyone tell me how to package a JRE with my JAR application?
Thanks
Thanks
A
Andrew Thompson
Why? How do you intend to deploy your application?
Off CD(1)? Off the net(2)?
1) you would simply include the latest JRE on the CD.
2) you would point the user to Sun.
But then there is the lesser followed route of creating a
not-cross platform '.exe' of your Jar file.
<http://www.physci.org/codes/javafaq.jsp#exe>
B
Bender
Andrew said:
I am distributing it over the net. I was hoping to keep the user from
downloading the JRE for a Windows version, i.e. - releasing an 'exe'
version.
A
Andrew Thompson
On Wed, 22 Dec 2004 04:05:24 GMT, Bender wrote:
....
Many people already have them (even Windows users).
Even better, when a new, faster, better JRE becomes available
(and is automatically updated on the client-side), your app.
gains those benefits.
In that case, if you only require windows support, it makes
more sense to develop it in .NET. OTOH, given the code
is already written, the links from the document I mentioned
earlier should give you an idea of your options.
....
Many people already have them (even Windows users).
Even better, when a new, faster, better JRE becomes available
(and is automatically updated on the client-side), your app.
gains those benefits.
In that case, if you only require windows support, it makes
more sense to develop it in .NET. OTOH, given the code
is already written, the links from the document I mentioned
earlier should give you an idea of your options.
S
Son KwonNam
I
IINET
re:
In that case, if you only require windows support, it makes
more sense to develop it in .NET.
Why - just becasue it is only for windows does not rule out java
automatically? Why suddenly switch to a whole other platform becasue it is
not intended for anything other than windows? Java runs on windows - so what
if it runs many other places too?
In that case, if you only require windows support, it makes
more sense to develop it in .NET.
Why - just becasue it is only for windows does not rule out java
automatically? Why suddenly switch to a whole other platform becasue it is
not intended for anything other than windows? Java runs on windows - so what
if it runs many other places too?
R
Robert kebernet Cooper
Bender said:
Honestly, I would recommend skipping the unified installer and use Java
WebStart. It gives you all the advantages of a windows installer plus
automatic updates.
Plus, once a person has one JRE with WebStart installed, it will
automatically update their JRE if you shift forward with your app too.
A
Andrew Thompson
On Wed, 22 Dec 2004 14:10:38 +0800, IINET wrote:
Please note how I 'in-line post with trimming' to your post,
and please adopt that posting style in future.
I'm glad you asked.
..NET is Win oriented. The layouts could be simpler for
the direct reason of not having to support a vast variety of
fonts, font sizes and PLAF's. I imagine the .NET IDE would
also have a D'n'D GUI editor, which would also speed development
over the general Java approach of hand coding the GUI.
It would be much easier in .NET to display/edit common MS
document formats such as .doc, .xls, to get the 'OS Component',
and actively control it.
It would be much simpler to get into the guts of the OS and system.
( For instance, .NET might even have the -advanced- ability to tell
you the free space on a physical drive.
Applications deployment could also be more streamlined.
Of course, all that is purely speculative, in the category
of 'if MS had *not* done that, they would be complete idiots'.
No, it does not. I generally encourage X-plat in any case.
Just because it needs to run on Windows, does not mean it
*cannot* be X-plat.
It would completely depend on factors not yet known, but
depending on the size of the application, it is something
that should be considered if the app. is truly to be 'Win only'*.
Besides, you have to weigh that against the downside of
making a Win .exe from a Java jar file, as detailed at the
link I provided to creating an 'exe'.
If you add that overhead to your Java development costs,
it may tip the balance in favor of development in .NET.
* One of the most important of the questions is 'Why Win only?'
[ And noting that an answer of 'we only run Win' is not in
itself sufficient, given time's nature of changing things. ]
Good point. Dump the idea of the EXE, and educate the users
about Java. ..Which even runs on Windows. ;-)
Please note how I 'in-line post with trimming' to your post,
and please adopt that posting style in future.
I'm glad you asked.
..NET is Win oriented. The layouts could be simpler for
the direct reason of not having to support a vast variety of
fonts, font sizes and PLAF's. I imagine the .NET IDE would
also have a D'n'D GUI editor, which would also speed development
over the general Java approach of hand coding the GUI.
It would be much easier in .NET to display/edit common MS
document formats such as .doc, .xls, to get the 'OS Component',
and actively control it.
It would be much simpler to get into the guts of the OS and system.
( For instance, .NET might even have the -advanced- ability to tell
you the free space on a physical drive.
Applications deployment could also be more streamlined.
Of course, all that is purely speculative, in the category
of 'if MS had *not* done that, they would be complete idiots'.
No, it does not. I generally encourage X-plat in any case.
Just because it needs to run on Windows, does not mean it
*cannot* be X-plat.
It would completely depend on factors not yet known, but
depending on the size of the application, it is something
that should be considered if the app. is truly to be 'Win only'*.
Besides, you have to weigh that against the downside of
making a Win .exe from a Java jar file, as detailed at the
link I provided to creating an 'exe'.
If you add that overhead to your Java development costs,
it may tip the balance in favor of development in .NET.
* One of the most important of the questions is 'Why Win only?'
[ And noting that an answer of 'we only run Win' is not in
itself sufficient, given time's nature of changing things. ]
Good point. Dump the idea of the EXE, and educate the users
about Java. ..Which even runs on Windows. ;-)
S
Steve Sobol
Andrew said:
Andrew,
That's just plain silly.
I don't think as many people have a Java2 RE as you might think.
I
IINET
re:
it makes
more sense to develop it in .NET
The reccomendation was really my issue here - you do not know this posters
situation, yet made this assumption.
you do not know if he is skilled in both platforms.
If the cost to switch is worthwhile for given the benefits to the app.
If win can offer anything java cannot for this app.
If the app will EVER need to be ported to other OS's
and so on...
Oh, and lets not forget the poster has already written the app in Java.
So, the slightly silly "it makes more sense to do it in .NET" statement was
not very sensible to me.
it makes
more sense to develop it in .NET
The reccomendation was really my issue here - you do not know this posters
situation, yet made this assumption.
you do not know if he is skilled in both platforms.
If the cost to switch is worthwhile for given the benefits to the app.
If win can offer anything java cannot for this app.
If the app will EVER need to be ported to other OS's
and so on...
Oh, and lets not forget the poster has already written the app in Java.
So, the slightly silly "it makes more sense to do it in .NET" statement was
not very sensible to me.
Andrew Thompson said:On Wed, 22 Dec 2004 14:10:38 +0800, IINET wrote:
Please note how I 'in-line post with trimming' to your post,
and please adopt that posting style in future.
I'm glad you asked.
.NET is Win oriented. The layouts could be simpler for
the direct reason of not having to support a vast variety of
fonts, font sizes and PLAF's. I imagine the .NET IDE would
also have a D'n'D GUI editor, which would also speed development
over the general Java approach of hand coding the GUI.
It would be much easier in .NET to display/edit common MS
document formats such as .doc, .xls, to get the 'OS Component',
and actively control it.
It would be much simpler to get into the guts of the OS and system.
( For instance, .NET might even have the -advanced- ability to tell
you the free space on a physical drive.
Applications deployment could also be more streamlined.
Of course, all that is purely speculative, in the category
of 'if MS had *not* done that, they would be complete idiots'.
No, it does not. I generally encourage X-plat in any case.
Just because it needs to run on Windows, does not mean it
*cannot* be X-plat.
It would completely depend on factors not yet known, but
depending on the size of the application, it is something
that should be considered if the app. is truly to be 'Win only'*.
Besides, you have to weigh that against the downside of
making a Win .exe from a Java jar file, as detailed at the
link I provided to creating an 'exe'.
If you add that overhead to your Java development costs,
it may tip the balance in favor of development in .NET.
* One of the most important of the questions is 'Why Win only?'
[ And noting that an answer of 'we only run Win' is not in
itself sufficient, given time's nature of changing things. ]
Good point. Dump the idea of the EXE, and educate the users
about Java. ..Which even runs on Windows. ;-)
A
Andrew Thompson
In what way did your statement correlate to what you quoted?
How many Win users do you think *I think* have Java?
I cannot make much sense of your statements.
S
Steve Sobol
Andrew said:
Heh. I didn't express myself very well, now did I. Sorry.
Let's try this again.
"In that case, if you only require windows support, it makes
more sense to develop [your application] in .NET" than it does to just bundle a
JRE with your application? That was the comment I was referring to as "just
silly." Even if you *are* developing only for Windows, to switch to another
language/development platform *only* for the purpose of easily building an
executable doesn't make a whole lot of sense. Furthermore, quoting another one
of your replies in this thread,
".NET is Win oriented. The layouts could be simpler for
the direct reason of not having to support a vast variety of
fonts, font sizes and PLAF's."
But you don't have to with Java, either. Either use the Windows L&F on Swing,
or (IMHO a better choice) use the Standard Widget Toolkit.
"I imagine the .NET IDE would
also have a D'n'D GUI editor, which would also speed development
over the general Java approach of hand coding the GUI."
I use Eclipse and Jigloo and see the same benefits. People running NetBeans can
also use DnD.
"It would be much easier in .NET to display/edit common MS
document formats such as .doc, .xls, to get the 'OS Component',
and actively control it."
I doubt it. Maybe a little easier. You can embed ActiveX objects in a Java app
running on Windows, can't you? (I could be wrong about this; have never tried it)
"Besides, you have to weigh that against the downside of
making a Win .exe from a Java jar file, as detailed at the
link I provided to creating an 'exe'."
Or not - you can create a separate EXE and still package the JARs separately,
and there is at least one Java install builder that'll do this.
You said "many". I'm saying "still relatively few", and I apologize, that
should have been a completely separate statement as it was not directly
relevant to my comment about your reply being silly.
A
Andrew Thompson
Using what Layouts though? AbsoluteLayout? XYLayout?
It brings us to the basic problem that when you shift the
application from the development machine to a machine with a
different RE, fonts, screen size, PLAF, the UI breaks.
If you use a D'n'D GUI designer (using PutItHere layouts) you
effectively lose the X-plat GUI in any case.
? News to me. I have no need to get that intimate with Windows.
...
Of course, when I said 'many', I meant 'many, plus or minus 25%'. ;-)
+ or -..?
It's cool.
It did read rather oddly.
S
Steve Sobol
Andrew said:
I used to use AbsoluteLayout, then I got smart; now I use GridLayout and
FormLayout (FormLayout may be an SWT-specific thing).
Oh, I don't know, 100%? (*pained expression*)
Winbloats PCs don't ship with the J2 RE yet. When that starts happening,* I'm
sure the number will increase significantly.
Cheers...
*insert obligatory "yeah, right" here, followed by standard rant about
anticompetitive Microsoft bulls^H^H^H^H^Hcompany policies.
A
Andrew Thompson
I vote 'not ever'. Java is a plug-in that needs to be kept up to date.
Install an OS/browser bare and get Java from the manufacturer.
<http://www.physci.org/codes/java/plugin.jsp>
It's up to you, me and other Java developers to convince users
of the need for the Java plug-in, by producing all those wonderful
apps. that have the 'Requires the free Java Plug-In' message below
the glossy picture.
C
Chas Douglass
[snip]
I think your prejudices are showing through here.
Eclipse and JBuilder both, from my personal experience, support "D'n'D"
GUI designers using a full range of java layouts. There is, of course,
no requirement for a programmer to use them -- but then you can write bad
code without a "D'n'D" GUI designer, too.
I'm sure there are others, like NetBeans, that do it, as well.
I'd be surprised if "the general Java approach of hand coding the GUI"
was the norm, anymore. However that's merely exposing MY prejudice
against hand coding GUIs.
Chas Douglass
I
IINET
re:
Eclipse and JBuilder both, from my personal experience, support "D'n'D"
GUI designers using a full range of java layouts.
Not sure what personal expereinces you've had here, but DnD gui development
is most definitely not a strength of eclipse - in fact, it is infamous for
its poor support here. Are you sure thats what you meant to say? Netbeans is
the one with the support here, not eclipse - not by a long shot!
Eclipse and JBuilder both, from my personal experience, support "D'n'D"
GUI designers using a full range of java layouts.
Not sure what personal expereinces you've had here, but DnD gui development
is most definitely not a strength of eclipse - in fact, it is infamous for
its poor support here. Are you sure thats what you meant to say? Netbeans is
the one with the support here, not eclipse - not by a long shot!
Chas Douglass said:
T
The Abrasive Sponge
I was wondering when someone was going to post a smart answer like this.Robert said:
A
Andrew Thompson
I've been wonderring when anyone in this thread will read the
link that I quoted above.
J
johndoe
Andrew Thompson said:
I'm not sure I entirely agree with all the points made in the section
you linked. For example:
This could be considered undesirable, as well. Consider if the user
either actively or passively downloads a newer JVM that has subtle
bugs in the libraries or JIT compiler that did not exist before.
And later:
This could potentially be an even larger problem for Java developers.
A developer that uses a static compiler can continue to use the same
well known static compiler for years. A Java developer can't be sure
their application will work on JDK 1.5.1 as well or reliably as it did
It's additional work, but not extremely difficult to write an
application that's capable of updating itself to newer versions. I do
however realize Java Web Start gives you this for free.
This paragraph struck me as very wrong:
My personal opinion is that it's dangerously misleading to suggest
that Java developers can pass the blame onto the JVM when their
application fails. It may be the fault of the JVM, but in my opinion,
the developer needs to take responsibility for what set of tools they
use to make their application available.
There are, in fact, quite a few good reasons for wanting to deliver to
a customer a native .exe with everything statically compiled into it.