heap size -xms and -xmx definition on a per-app basis in manifest file?

Wed Sep 12 12:09:12 UTC 2012

On Wed, Sep 12, 2012 at 8:10 AM, Dmytro Sheyko <dmytro_sheyko at hotmail.com>wrote:

> With JNLP it's even simpler - just tell users to click on link (with jnlp
> file) on your web page. Application will be downloaded by Java Web Start
> and then started.
>

I´m perfectly aware of what JNLP and Java Web Start is. In fact, I
contributed several entries in the Wikipedia entry for Java Web Start,
that, surprisingly, has one user who likes to delete the list of known apps
using JWS, and I restored it.

http://en.wikipedia.org/wiki/Java_Web_Start#Well-known_applications

 I think Java web Start is one of Java´s hidden gems, and that it should be
promoted more. However, it´s not a "one size fits all" solution or the holy
grail.

There is no need to find place on user's filesystem where to store
> appname.jar and then clicking on it, or creating shortcut on desktop.
>

There are some instances where JNLP / Java Web start are not an option:

1. User is behind a firewall and doesn´t want to place the app on a web
server
2. The author doesn´t want all users worldwide to fetch the app from his
server, due to bandwidth issues
3. The end user wants to place the app on his pen drive and not having to
deal with a complex directory structure.

>
> BTW, what are benefits of having single jar file? Why do you believe that
> this is the right way?
>

Since you´re doing a considerable effort not to believe me, you should ask
the authors of one-jar:

http://one-jar.sourceforge.net/

-----
What is One-JAR?

One-JAR lets you package a Java application together with its dependency
Jars into a single executable Jar file.
Who uses One-JAR? A number of commercial and open-source
projects<http://www.google.com/search?hl=en&q=%22One-JAR%22+P.+Simon+Tuffs+%28simon%40simontuffs.com%29.+++All+rights+reserved.&btnG=Search&aq=f&aqi=&aql=&oq=&gs_rfai=>have
chosen One-JAR as their packaging mechanism. Since inception One-JAR
has had over 75,000
downloads<http://sourceforge.net/project/stats/?group_id=111153&ugn=one-jar&type=&mode=alltime>and
shows a consistent download profile over time, and is used across a
variety of operating-systems<http://sourceforge.net/downloads/one-jar/stats_os?dates=2010-02-01%20to%202010-07-16>
---

http://one-jar.sourceforge.net/index.php?page=introduction&file=background

---

The Java Runtime Environment supports running a Jar file using the
following syntax:

java -jar *jarname.jar*

The only requirement of the *jarname.jar* file is that it contains a
manifest attribute with the key Main-Class a main class to run, for
instance in the META-INF/MANIFEST.MF file:

Main-Class: com.mydomain.mypackage.Main

Any non-trivial Java application is going to rely on any number of
supporting Jar files. For example, using the Apache Commons Logging
capabilty to do logging an application will need to have the
commons-logging.jar file on its classpath. Most developers reasonably
assume that putting a dependency Jar file into their own Jar file, and
adding a Class-Path attribute to the META-INF/MANIFEST will do the trick:

jarname.jar
| /META-INF
| |  MANIFEST.MF
| |    Main-Class: com.mydomain.mypackage.Main
| |    *Class-Path: commons-logging.jar*
| /com/mydomain/mypackage
| |  Main.class
| commons-logging.jar

Unfortunately this is does not work. The Java Launcher$AppClassLoader does
not know how to load classes from a Jar inside a Jar with this kind of
Class-Path. Trying to use jar:file:jarname.jar!/commons-logging.jar also
leads down a dead-end. This approach will only work if you install (i.e.
scatter) the supporting Jar files into the directory where the
jarname.jarfile is installed.

Another approach is to unpack all dependent Jar files and repack them
inside the jarname.jar file. This approach tends to be fragile and slow,
and can suffer from duplicate resource issues.
---

...or ask the authors of this game why they provide
a single-jar version of their app

http://www.snorms.com/downloads_demo/snorms-demo.jar?PHPSESSID=e5q5fccq0eut7dv4e2m3c81me0

Basically a single-jar gives you:

-Easy app portability (no need to "install" it scattering thousands of
files, apps are "self-contained" and movable to any path the user wants to
place them -including removable drives like pen drives- without having to
fiddle with the system´s path or classpath)
-No need to include native "launch scripts" or stub exes that call java
with the right paths
-Just tell the users to double click on the jar (windows) or create a
desktop object with java -jar pointing to the .jar file
Or ask yourself why popular apps like Java Image Editor are delivered as a
single-jar

http://www.jhlabs.com/ie/
"Download ImageEditor.jar for Windows and
Unix<http://www.jhlabs.com/ie/ImageEditor.jar>
"
links to http://www.jhlabs.com/ie/ImageEditor.jar

...or ask yourself why the "default-class" parameter was implemented in the
manifest file. Maybe it´s to make it easy to execute java apps as "java
-jar appname.jar" without long class names as a parameter -often requiring
a start-up script- as was the case in the ancient Java 1.x days?

But if you still don´t want to believe me that this is a really useful
feature and that the only thing that is missing is being able to specify
the apps´s memory requirements in the JAR´s manifest file, then fine, I´m
sure you can develop an argument against it...

Me? I think that implementing this would be a win-win... for portable
self-contained apps. (Right now java -jar appname.jar together with the
default-class parameter in the manifest file already gives this
functionality, the only hurdle to adopt this approach is in apps that
require customizing the memory parameters.... then it´s required to do a
launch script or do jnlp, as it´s impossible to specify the jre memory
startup params embedded within the .jar.... this is a serious shortcoming
and hence my proposal of a RFE...)

FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
 George Orwell