Our approach to deployment of the new Java 3D libraries is to create a
single extension to the jnlp resources, called "jogl.jnlp". This makes
direct reference to bundled native libraries as well as Java3D jars.
What follows is the listing for the "jogl.jnlp":
<description>Java 3D library</description>
<jar href="libs/jogl/j3dcore.jar" download="eager"/>
<jar href="libs/jogl/j3dutils.jar" download="eager"/>
<jar href="libs/jogl/vecmath.jar" download="eager"/>
<jar href="libs/jogl/jogamp-fat.jar" download="eager"/>
The j3dcore.jar, j3dutils.jar and vecmath.jar are pure Java code. Native
methods for the common platforms (Windows 64, Windows 32, Linux 64,
Linux 32 and the Mac) are all placed in the jogamp-fat.jar. A JNLP that
launches a jogl application follows:
<j2se version="1.8+" initial-heap-size="64m" max-heap-size="384m"
<extension name="Java3D" href="jogl.jnlp"></extension>
<jar href="joglquad.jar" />
<application-desc main-class="j3d.JOGLQuad" />
Here we we the common extensions for jogl support, <extension
name="Java3D" href="jogl.jnlp"></extension>. This enables a common
deployment to all Java3D and JOGL based programs. Also, most critical to
proper operation, the J2SE tag:
<j2se version="1.8+" initial-heap-size="64m" max-heap-size="384m"
The "--add-exports" is part of the new-style module arguments. For example:
follows the pattern: --add-exports <source-module>/<package>=<target-module>
where <source-module> is "java.base", <package> is "java.lang" and
<target-module> is "ALL-UNNAMED". The "ALL-UNNAMED" enables all modules
to access all classes in java.lang. In the case of legacy code, all the
modules will be unnamed.
As webstart applications must be signed before modern Java will run
them, we have authored a collections of articles that guide the reader
through the signing process [Lyon, 2004a,b, 2008].
The signed jar files are all available from:
Full text of the below articles cited are available from the authors web
site at http://www.docjava.com
[Lyon 2004a] “Project Initium: Programmatic Deployment” by Douglas A.
Lyon, Journal of Object Technology, vol. 3, no. 8, September-October
2004, pp. 55-69.
[Lyon 2004b] “The Initium X.509 Certificate Wizard” by Douglas A. Lyon,
Journal of Object Technology, vol. 3, no. 10, November-December 2004,
[Lyon 2008] “I Resign! Resigning Jar Files with Initium”, by Douglas A.
Lyon, Journal of Object Technology, vol. 7, no. 4, April-May 2008, pp. 9-27.
On 1/9/18 9:10 PM, Predrag Bokšić [via jogamp] wrote:
> GOOD NEWS! I don't know if you have updated any code in the meantime,
> but this JNLP execution works on KUbuntu 16 with all the latest updates
> and the Oracle JDK 9, and with the Oracle JDK 8 separately. The last
> time I checked from the same operating system in a virtual machine, it
> displayed an empty canvas inside a window. Now I am on a real machine,
> and everything works as expected, including my off-line projects.
> Douglas, will you find the time - its no hurry - to perhaps, pack and
> send a directory with the jar and jnlp files? I think that I understood
> everything that you are saying, but can you imagine someone coming from
> Google in 3 years time to this thread utterly confused about the thing
> he/she should copy-paste :-)
> Here's some "statistics" to keep the engineer's mentality going.
> VM arguments:
> --add-modules=ALL-DEFAULT,javafx.deploy -Xverify:remote
> -DtrustProxy=true -Xverify:remote
> -Djnlpx.home=/usr/lib/jvm/java-9-oracle -Djava.security.manager
> -Djnlpx.origFilenameArg=/home/gamma/idea/classy/joglquad polished.jnlp
> -Djnlpx.remove=false --add-exports=java.base/java.lang=ALL-UNNAMED
> --add-exports=java.desktop/sun.java2d=ALL-UNNAMED -Xms64m -Xmx384m
> --illegal-access=deny --add-modules=ALL-DEFAULT
> If you reply to this email, your message will be added to the discussion
> To unsubscribe from Jogl/Jogamp on Java 9, click here
Thank you for sharing your findings and explaining in details how you use Java Webstart. Actually, it was possible to point to our JNLP files in order to use JogAmp without having to handle all our files but I don't know whether it still works.
In my humble opinion, there isn't only one solution to solve all deployment problems. Java Webstart fits into your need, that's fine. It's suitable when you want to test something without having to (explicitly) download and install. However, Let's Encrypt can't be used for code signing, all providers of free of charge trusted certificates expect some compensations and trusted certificates have become mandatory to use Webstart whereas they only give a false feeling of security. A Russian programmer stole such a certificate and illegally used my only registered trademark to provide a fake version of my game full of crapwares (viruses), it shows that blindly trusting "trusted" certificates is stupid and can lead to install dangerous softwares. The best security suite is an educated person who accepts to understand a bit the technology (s)he uses. Encouraging Java Webstart now means encouraging this vision of security. Sorry but I can't agree with it and it excludes the developers who can't afford such certificates. I'm fed up with re-intermediation. In other words, the corporations selling those certificates just put tolls to make money with no additional value in term of security. This problem concerns some other means of deploying softwares too but Java Webstart wasn't concerned by this before some changes done in Java 1.7.
Moreover, when a developer needs a more complete way of installing a software, IzPack is a viable alternative (obviously there are other solutions). When we need much more control on what has to be installed on the end user's machine, Java Webstart can't be the right answer as it doesn't support all JVM options for security reasons, its class loader doesn't behave exactly like the one of a Java software launched without it and it's not possible to install another JRE for your program with Java Webstart. Numerous professional softwares on which I worked required a particular update of Java to work, it doesn't make a lot of sense to use Webstart to run this kind of software without relying on the JRE installed on the system.
Finally, there are lots of ways to fail to deploy a software with Java Webstart, that's why explaining how to use it has become increasingly complicated. Some manifest attributes were (are?) mandatory under some operating systems but not on others, including "Application-Name". As the support of "Trusted-Only" and "Trusted-Library" has changed several times, it's impossible to make a single JNLP file working with all updates of Java 1.7. The parsing of some options was partially broken for years, for example in "java-vm-args" in Java 1.7 update 45. I think that a developer should know the pitfalls of Webstart before choosing it as a deployment solution even though I admit that some alternatives are cumbersome to use, their main lack is the update management, some just don't work at all (I have never succeeded in using GetDown). Webstart has a huge history of major bugs and limitations. Do you remember when it caused a deadlock when showing a window at the beginning? Its caching system is far from perfection too. I strongly disagree with your title, it should be "Here is how to do multi-platform deployment with Java Webstart" as it's not the only mean of doing multi-platform deployment and claiming it is leads to ignoring what I've just written above, it doesn't fit into all needs...
By the way, the desktop shortcuts can't be created on all operating systems supported by Java with Webstart, I had to reimplement this feature by myself and mine did a far better job especially under GNU Linux with KDE.
|Free forum by Nabble||Edit this page|