Packing JRE

S

Steve Sobol

IINET said:
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 is a more stripped-down framework than Netbeans is, which is a good
thing because Netbeans is a memory hog. I use the Jigloo GUI builder from
Cloudgarden.com - yes, it's a third-party package but it works very well.
 
C

Chas Douglass

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!
[snip]

GUI building isn't, perhaps, Eclipse's greatest strength, but it is
possible, both with 3rd party add-on's and the new VE (Visual Editor)
plugin that is now a formal Eclipse project.

Chas Douglass
 
B

Bill Tschumy

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.

I wonder how well WebStart apps are perceived by most Windows users.
WebStart requires them to do things very differently from how they run most
of their apps. Most users don't like variations in their routine.

On Mac OS X, WebStart will automatically offer to create a double-clickable
executable after the app has been run a couple of times. This seems like an
ideal solution to me and I wish the windows version would implement it.

I have thought of making WebStart verisons of my apps, but many download
sites will lower your rating if you don't follow the established Windows
conventions.
 
B

ByteCoder

Bill said:
I wonder how well WebStart apps are perceived by most Windows users.
WebStart requires them to do things very differently from how they run most
of their apps. Most users don't like variations in their routine.

On Mac OS X, WebStart will automatically offer to create a double-clickable
executable after the app has been run a couple of times. This seems like an
ideal solution to me and I wish the windows version would implement it.
[...]

It does ask you to create a link on the windows desktop when you execute
a webstart app for the second time.
 
B

Bill Tschumy

Bill said:
I wonder how well WebStart apps are perceived by most Windows users.
WebStart requires them to do things very differently from how they run most
of their apps. Most users don't like variations in their routine.

On Mac OS X, WebStart will automatically offer to create a double-clickable
executable after the app has been run a couple of times. This seems like
an
ideal solution to me and I wish the windows version would implement it.
[...]

It does ask you to create a link on the windows desktop when you execute
a webstart app for the second time.

I've never seen it do that for any Webstart app I've run. Interesting. I
guess I'll have to explore further.
 
A

Andrew Thompson

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.

You can 'have your cake and eat it too' with JWS, since you can
specify either a *minimum* version of Java, or a *specific* version.
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.

Would you care to list them for the purposes of progressing
this thread, or are they secret?
 
A

Andrew Thompson

Bill Tschumy wrote: ...
On Mac OS X, WebStart will automatically offer to create a double-clickable
executable after the app has been run a couple of times. This seems like
an
ideal solution to me and I wish the windows version would implement it.
[...]

It does ask you to create a link on the windows desktop when you execute
a webstart app for the second time.

I've never seen it do that for any Webstart app I've run. Interesting. I
guess I'll have to explore further.

That got me once, as well. AFAIR there is a 'checkbox' shown
in early invocatoins of JWS that asks if you want to 'integrate
the app. to desktop' (or words to that effect). I think the
options are 'yes', 'no', and 'no and do not bother me again'.
 
B

ByteCoder

Andrew said:
Bill Tschumy wrote:
..
On Mac OS X, WebStart will automatically offer to create a double-clickable
executable after the app has been run a couple of times. This seems like
an
ideal solution to me and I wish the windows version would implement it.

[...]

It does ask you to create a link on the windows desktop when you execute
a webstart app for the second time.

I've never seen it do that for any Webstart app I've run. Interesting. I
guess I'll have to explore further.


That got me once, as well. AFAIR there is a 'checkbox' shown
in early invocatoins of JWS that asks if you want to 'integrate
the app. to desktop' (or words to that effect). I think the
options are 'yes', 'no', and 'no and do not bother me again'.

That's right and was the case at least until Java 1.4.2. I don't know
(yet) how it works with Java 1.5.
 
J

johndoe

Andrew Thompson said:
You can 'have your cake and eat it too' with JWS, since you can
specify either a *minimum* version of Java, or a *specific* version.

Whoops, I'll have to ask you to excuse my ignorance on this one. It's
wonderful that the people who designed JWS had the foresight to allow
you specify a specific version of the JRE is required. I've learned
my lesson and will avoid talking about JWS in the future until I've
taken time to research it better.
Would you care to list them for the purposes of progressing
this thread, or are they secret?

Here are a few reasons, some of them perhaps good reasons, some
perhaps not such good reasons.

1. Asking or requiring the end user to take any more installation
steps than absolutely necessary. As an example, I'm a PuTTY user
(it's an SSH client for Windows) because I can download and run a
single executable and be up and running immediately. I used to use
TeraTerm with the SSH plug-in, and switched to PuTTY only because
of the ease of deployment factor. (I may find myself using several
different computer systems every day, possibly having never used
any of them previously.)

Even though the WWW is a big step back in user interfaces in many
ways, I think its success shows how important the simplest
installation possible can be. It's unfortunate to have to ask
users to step through a JRE installation before they can begin
using your software.

2. The size of the JRE may be a burden for many end users who may find
themselves on dial up or metered access to the Internet. I often
wish I could deploy my Java applications statically bound with only
those parts of the JRE and libraries that my application absolutely
requires.

For example, if my application runs in the background only, with no
user interface, it seems like an unnecessary burden that end users
would have to download a full JRE with AWT and Swing support (I'm
assuming for the moment that AWT and Swing take up a non-trivial
amount of space in the JRE - I could be mistaken, but this is just
an example - you could probably apply it to other things).

Of course this doesn't apply to programs delivered on CD-ROM...

3. Native executables are harder to reverse engineer, thus protecting
proprietary applications better. (Been debated to death, but I
thought it was worth mentioning).

Some of these items are based on experiences I had writing small
applications and deploying them via the Internet. One such
application was written in C++ (shudder :) and used the wxWidgets
(previously wxWindows) and I was very pleased that the resulting
application was just over a megabyte.

Another was a small Python (shudder again :) program and again the
application was just over a megabyte.

Java is currently my preferred programming language but I have to
admit I have more trouble with Internet-based deployment because a lot
of users (whether rightly or wrongly) complain about having to
download and install the JRE first, many of them won't do it at all.

I'll admit I'm probably asking for the impossible, but I do find
myself wishing I could "compile to .exe" (when deploying on Windows)
and also wish the resulting program would be as small as possible
(that is, only link in those parts of the JRE/Java libraries I'm
actually using).

To be fair, I should add that these thoughts won't stop me from using
Java. I don't like languages such as C++ or Python at all!

One more thought to add: I'm concerned about Microsoft's .net.
Microsoft can and will leverage their Windows monopoly to make sure
every Windows user has the CLR installed when Windows is installed
(starting with Longhorn, I assume, unless they've started doing this
already) which gives Microsoft a huge advantage in terms of points #1
and #2 listed above.

I have no intention of using .net or languages like C#, but I can't
ignore the fact that when I compete against .net programs with my Java
programs, the end users will have the choice of either downloading a
small .exe (since CLR will presumably already be installed on their
Windows machine), or downloading my program which might first require
them to download and install the JRE. It doesn't seem like much to
ask, but I suspect most end users will take the path of least
resistance, much like flowing water does. This translates into lost
market share for me.

Whew! I didn't expect this to end up so long. I'm very interested in
your comments and suggestions. :)
 
A

Andrew Thompson

(JD)

Here are a few reasons, ..
(I've snipped 1 and 3, since I do not disagree)
...
2. The size of the JRE may be a burden for many end users who may find
themselves on dial up or metered access to the Internet. ..

True, but weight that up for 20 Java based applications.

You may need to include a Meg or two of the JVM with the
each native executable (sometimes the same classes,
sometimes different). By the time the user has installed
15-20 such apps., the total download size of the 20 native
executables will be larger than 20 JWS apps. and 1 JVM.

So, I am generally taking the wider view. Make a JWS app.
that ultimately benefits the *user*, rather than a native exe
that plays into the user's misplaced caution of anything new.
...
Whew! I didn't expect this to end up so long. ..

The most interesting threads are like that. ;-)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top