When I'm making a new JNLP file, I have to enter the versions of JAVA that my applet can work with, for example
<j2se version="1.6+">
Obviously, I want my applet to work with as many versions as it can, (I do, right?) how can I know what is the minimum required version to run my applet?
obviously, I want my applet to work with as many versions as it can, (I do, right?)
I disagree. It is well known that running Java in the web browser is a security nightmare. The best approach (for your users' security!) is to not use applets at all. But if you must do it, then you should be aiming to do it as securely as possible. That means writing your JNLP file to insist on a recent version of Java. Preferably, the most recent patch level of Java 7.
But to answer your Question, the simplest test to find the oldest a version of Java should support your application is to attempt to compile it with that version of the JDK. If it compiles on an old version JDK, then it is fairly likely that it will run.
But then you should test it, because successful compilation does not guarantee that the application will run properly.
And as #Lonzak points out, there is a separate issue of whether the user's installed Java supports JNLP.
There ought to be a better way but the following are the most general ones in my opinion:
Set the version of the Java Applet in your IDE to the lowest version you want to support and start programming.
Check the libraries/functions you need and check in which version they have been added.
When you want to use the JNLP mechanism you are bound to the next generation java plugin. It is supported starting with Java 1.6.0_10 (6u10). Java version older than that does not support JNLP. So if you want to support older Java versions you have to use the "old" mechanism (e.g. applet, object and embed tags).
So what would could you do?
Write a preceding applet, which is compiled with Java 1.4 (or even earlier). This applets basically only checks the Java version and other prerequisites. If the Java version is not sufficient (<6u10) it displays an error and otherwise the JNLP based applet is started...
Related
I am trying to use Emscripten's emconfigure and emmake to compile OpenJDK for the web. The end goal would be to be able to run uncompiled java code natively in the browser. However, running emconfigure ./configure throws the error
configure: The C compiler (located as /usr/lib/emscripten/emcc) does not seem to be the required gcc compiler.
configure: The result from running with --version was: ""
configure: error: A gcc compiler is required. Try setting --with-tools-dir.
I have been searching all day and I haven't found anything along the lines of this error. Is there any easy workaround for this? Should I even be trying to build OpenJDK this way?
Is there any easy workaround for this?
I doubt it. If you look at (for example) jdk11u/make/autoconf/toolchain.m4 you will see the toolchains that are supported on various platforms. Emscripten is not listed.
I expect that emconfigure is trying to use the JDK's autoconf-based configuration framework. And that framework is checking the compiler you are trying to use ... and saying Nope!
You may be able to modify the auto-conf macros to support the Emscripten tool chain. But the next problem will be getting the code to actually compile. And then to getting it to run.
Should I even be trying to build OpenJDK this way?
It is not up to us to say what you should do.
However, I would make some observations.
If you are expecting this to work without significant effort, you are sadly mistaken.
What you are doing is equivalent to trying to port Java to a new OP platform and hardware platform. This is is a massive project. In addition to just getting the JVM to compile, you also have the problem of getting the Hotspot JIT compiler to generate WebAssembly code.
This is probably a bad idea anyway. Once upon a time, mainstream web browser vendors did support Java in the browser. But there were so many "security issues" that (virtually) all vendors have dropped support. Oracle saw the writing on the wall, and in Java 9 they started the process of removing support from the OpenJDK codebase. Applet support and JNLP are gone, and they are planning to get rid of the SecurityManager framework.
What you would be doing is bring back Java support in the web browser ... with the security safeguards stripped out.
Basically, the Java SE platform is to rich to implement securely in a web browser.
If you are still keen on building a JVM using Emscripten, take a look at https://github.com/emscripten-core/emscripten/issues/3342.
But note that they are talking about building JamVM, which is Java 1.6, and hasn't been touched since 2014.
I'm working on research to move an existing applet (extends Applet) to Java Web Start due to the deprecation in Java 9. However, it seems like most of Oracle's migration docs instruct the dev to use the "applet-desc" tag to create a new JNLP and migrate. Does this mean that launching applets outside of the browser will not be deprecated?
If not, then what is the recommended approach? Saying "rewrite your applet" doesn't help... that's what everyone says. Doesn't really give me the "how".
What are possible solutions and examples/tutorials of migration? I can't seem to find much newer documentation out there, I see a lot of stuff between 2001 and 2011. It seems like most websites that provide examples no longer host the applications, or they aren't properly signed.
EDIT
My most important part of the question is: Is Oracle deprecating the Applet class when deprecating the browser plugin? Or, can we still use classes extending Applet within the tag in a JNLP, without a deprecation warning?
My applet requires user authentication and session cookies that are dynamically generated in our JSP. I've seen online that this is possible. This JWS application is not to be used offline, and is meant to be launched from an HREF. Is this still valid?
The thing that is deprecated is done by the browser manufacturers (though Oracle, realising the situation now advises not to develop them). So Oracle has not 'deprecated' the applet tag(1) in the same way that it has deprecated other classes, methods or attributes as occasionally mentioned in the Java Docs.
As to launching the applet using JWS, yes that should still 'work'. But note that whereas (for example) Chrome used to pass a JNLP direct to the program registered as a consumer of that file type (wherein it would be passed to the Java Web Start Client included in the JRE), it now causes the user to first download the JNLP, then explicitly choose to launch that file.
Update: Oracle may not have deprecated the applet tag, but they'll do effectively the same thing come Java 9. From JDK 9 and the Java Plugin:
By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Silverlight, Java, Flash and other standards-based plugin technologies.
Oracle plans to deprecate the Java browser plugin in Java Standard Edition Development Kit 9 (JDK 9). Deprecation is a warning for developers to stop using this technology. JRE 9 will continue to provide the Java Plugin and support launching applets on browsers that still offer standard plugin support. This browser plugin will be removed from the Oracle JDK and JRE in a future Java SE release. Developers and users who want to learn more about this planned change can find out more in this blog post.
I'm using java applet on my site. I want to provide correct applet tags which will work in modern browsers and in old IE versions (8+). As far as I understand, modern browsers use <embed> tag and <object> tag provides best experience for Internet Explorer. Internet Explorer even performs automatically silent Java installation, if user does not have installed Java without browser restart. That's very nice.
Now the problem is, most of the documentation regarding <object> tag is outdated. My applet compiles with Java 1.6 and works fine with it, but obviously I want users to install the latest Java. I can't find official documentation about silent installation for Java 8. If I specify classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6 and that's bad. I've found some urls for downloading .cab files and there are no urls for Java 8. Did Oracle remove that convenient method for Java 8?
What is the best approach to use for embedding Java Applets with modern Java with Internet Explorer?
See the Java Rich Internet Applications Deployment Advice for details of the deployment toolkit script. It should write whatever applet tags are recommended for that user agent.
If I specify classid="clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA", probably that will install Java 1.6..
Not anymore. Oracle has dropped support for loading/using an older JRE. Apparently they have become sick of supporting older JREs with potential security bugs.
I want to integrate java compiler in my application but I don't have any idea how will I do that.
I want that user could compile and run code on my application.
If anyone can help me then please tell me from where I should start.
Starting Java 1.6, the standard JDK ships with an API to the compiler. Meaning, you can easily write a Java program that will compile other programs.
http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html
EDIT as per Aaron's comment: an application using the compiler API must be run using the full JDK. The JRE doesn't include the compiler API implementation.
A second alternative is to embed the Eclipse Java compiler into your code. The advantage of this is that your application doesn't need a SDK to run - just add this single JAR.
Details are documented here: http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm
Note: Adding a compiler to an application creates an enormous security risk. It basically means anyone can start doing anything with your application. Things that spring to mind are:
Attacking other computers, people and sites
Looking at all the data on the computer on which the application is running
Analyzing the network the computer is in and attacking any other computer in the same network
Installing Trojans or viruses on the computer
I have developed a JavaFX app and I am going to distribute it as a Native Package to avoid headaches with users having a Java version lower than 7 (and thus, without JavaFX) or having no Java at all.
However, I also want to be able to deliver updates of my application. One solution is for the app to call home (its already communicating with the backend via XMLRPC), fetch a JAR and self-update. I can see potential problems with the actual update process though (would need to build a separate updater program, but how do you update the updater?).
I know about and would love to use Java Web Start. However, I have no idea if this will work with the Native Package thing. If the user already has Java installed, it will disregard my bundled JRE. If he has no Java... well, he can't use Java Web Start, right?
How can I solve this problem in an elegant way that will not have a detrimental effect on user experience? (and preferably won't be very long to implement)
note: I am using e(fx)clipse as build tool.
If he has no Java... well, he can't use Java Web Start, right?
True, but as mentioned in the JWS tag Wiki:
Java Rich Internet Applications Deployment Advice. Describes the deployJava.js
script designed to ensure a suitable minimum version of Java is installed before
providing a link to a
JWS app.
or launching an
applet.
Note that JWS also offers fine grained versioning as detailed in Java Web Start - Runtime Versioning.
Saying that, JWS can allow you to support earlier systems by adding the JavaFX 2 API selectively to those earlier systems. That is achieved using a version based resources section in the launch file.
So, JWS combined with deployJava.js would actually be 'the alternative' to the Native Package that page discusses.