I have a Runnable jar file, is there anyway to embed it into html so people dont have to download my game to play?
An Applet is what you want...put the following inside your html..
<APPLET ARCHIVE="yourfile.jar" CODE="yourApplet.class" WIDTH=400 HEIGHT=200>
</APPLET>
Of course for this, your jar file must contain yourApplet.class
What you are looking for is Java Web Start. It can (install &) launch Java rich client apps. (e.g. Swing, SWT, AWT) from a link on a web page.
Note that both web-start & converting the app. to an applet mentioned by other people, would effectively download the Jar to the users computer, it's just that it is 'invisible' to them (unless it is 60+ megabytes - in which case the time will be noticed).
As an aside, speaking as someone with extensive experience of both applets and JWS, I strongly recommend to avoid applets for this one. Use JWS. It is easier, and no conversion of the 'main' class is required. Either way, the Jar will end up needing to be digitally signed.
Related
I have a html file, there are links in it, I wonder if there is a way to use those links to call a java program to generate another html file ?
Something like this :
<Html>
<body>
Some text
<A Href=[somehow point to a java .class file to run]>My Link</A>
More text
</Body>
</Html>
I know how to use Java to generate html, what I'm asking here is how to pass a parameter to this local java class so that it can generate html file with the input ?
So if the Java program is called : MyHtmlGen.java
Then the class will be MyHtmlGen.class
And then if I run it from the command line, it would be like this :
> java MyHtmlGen my_input
But I don't know how to turn that into the html link above ?
You could use WebStart to launch an Java application from a browser interaction.
The section of the linked documentation titled: "Running a Java Web Start Application From a Browser" provides a demo you can try. The link to the Java application is provided as:
Launch Notepad Application
That documentation states that when you click the link:
Java Web Start software loads and runs the application based on instructions in the JNLP file.
That isn't the behavior I get on Safari 7.1 on OS X 10.9 with Oracle Java 8u40 installed. Instead, I just get the jnlp file downloaded and can double click on the downloaded file to run the application. I think on some browsers, Oracle may provide a plugin to the browser which is able to launch the jnlp referenced application automatically without the user having to also double click on a downloaded jnlp file. Perhaps if the Java deployment toolkit were used, rather than a straight a href link, the user experience might be a bit more seamless.
Note: browser manufacturers have been phasing out support for plugin technology like this, so the experience or even the ability to automatically run the referenced application may vary for both you and your users. Additionally, allowing such plugins to run within a browser environment can increase the security attack vulnerability surface for a user's browser. WebStart is also quick a tricky technology to use and support for your users. So for these reasons I normally don't recommend using WebStart as a deployment solution.
That's just impossible. A link <a> will fire a GET request to the server for the URI set in the href attribute, it's not meant to execute a specific piece of code. If you want to execute code when clicking a link, use JavaScript, but be aware that JavaScript cannot start an instance of JVM and run your exact Java application.
On the other hand, maybe you should look into Applet or JavaFX and embed the java application in your page. Or probably you may submit an action to the server, and at server side you may start the JVM and execute your Java code.
I am writing a Java file uploader applet, but I simply could not figure the following issue out. (The uploader is very specialised, therefore we could not just use a stock solution). I have a self-signed applet, which I am trying to test locally, but I cannot get it to read local files. I have Permissions:all-permissions declared in the manifest.
If I add
<param name="permissions" value="all-permissions" />
to the applet tag , it throws
com.sun.deploy.security.BlockedException: User has denied the privileges to the code
If I avoid this, it throws
java.security.AccessControlException: access denied ("java.io.FilePermission" PATH_TO_FILE" "read")
BlockedException is thrown in the first case, even though when the Java plugin asks me about security issues, I always say "don't block", in order for this code to run.
Any ideas how I can test this? Or could you point me to an open source Java uploader applet implementation I could inspect? Of course, the deployed version of this software will be signed with a trusted certificate, but I need a means to test it....
Thank you!
Update
Here is what needs to be done:
Given a web application which we developed, this application needs a lot of small files from the local filesystem. So, we need to iterate over a directory structure and inspect files in order to find those that the web app needs. This is very cumbersome by hand, therefore we need to automate this.
I thought of two other approaches:
JNLP-applet, however, its API can only display a FileChooser for single or multiple files, but not for a directory
A plain old Java client application, which will find the files it needs and upload them to the server via an API. This client can then be launched via Java Web Start.
..Do you have any more ideas?
What you are trying to do is generally frowned-upon as this is exactly how systems are compromised with Java installed. The operation you want to do is privileged, you will need to run your code in a privileged mode, and, most likely, create a policy file to allow this to work on the client machine. There's a short, concise tutorial on http://www.coderanch.com/how-to/java/HowCanAnAppletReadFilesOnTheLocalFileSystem.
Now, please, this is actually a VERY BAD IDEA. Is there no way that you could rather write a JavaScript page that will perform this upload via some API call at all? That way, you are not bypassing the browser security to perform the upload.
The Java Applet approach is an out-dated, dangerous and down-right nasty solution, and no amount of signing, policy files or tweaks will make this a safe alternative. I'm a huge Java fan, but if there's one thing that gives me nightmares, it's the Java browser plug-in - there's just never a good reason for using it, not when you consider how incredibly unsafe it is. Of course, don't get me started on Flash...
Your idea of using a plain Java client, loaded via Web Start, seems to be the best solution. That way, once installed, your application would have full access to the underlying file system. Of course, this also opens up the debate of whether this is really a situation for using Java in the first place, but that's a whole other kettle of fish.
to do this you have to sign your applet.
keytool -genkey -keystore myKeyStore -alias me
keytool -selfcert -keystore myKeyStore -alias me
jarsigner -keystore myKeyStore jarfile.jar me
A self signed applet working off a local server1 should be able to access the local file-system. It might be necessary to lower the security level in the Java Control Panel. Oracle is in a process of tightening the security of applets, so it will depend on which exact JRE version is loading the applet.
It seems the security environment of an applet loaded off the local file-system is tighter than if it were loaded from localhost. See this answer for details.
I agree with your assessment that the the JNLP based file chooser is unsuited to this task. As you mentioned, it is for working with file resources, not directories. Even worse, I noticed a small applet that I had developed using the JNLP based file open services was throwing NullPointerException while browsing around, with associated odd visual behavior in the chooser itself. Totally inadequate.
As the top poster for applet questions, I strongly actually warn against embedding an uploader in a web page. The biggest problems:
It creates further problems with browser/JRE/JavaScript/applet interaction bugs
It creates a non-resizable GUI. There are ways to create a resizable applet, but last time I checked, they were not reliable across browsers.
So in the end, I recommend using a fully trusted (i.e. all-permissions) app. that uses either the Swing JFileChooser or a variant of the File Browser GUI opened from a free-floating, JNLP launched JFrame. If the use-case is simple enough, we might even be able to dispense with the frame itself, and (visually) go directly to the file chooser.
The 'free-floating' approach will not work in a web-app. that requires JavaScript interaction. If the web-app. requires that, we come back to 'applet', and that is where you'd look to use the doPrivileged(..) functionality you mentioned in a comment. The reason being that if a method is called programmatically by JS, the Java based security manager detects that some frames in the stack are not trusted (the JS), and therefore puts everything back in the sand-box - even if the Java code was originally trusted.
I have a client who has a java based game which he wants to make available online (at the moment it is desktop version which he had to install). He asked me whether I can embed it into a webpage. After trying for several days still no joy. Can you please point me to the right direction. It have fives jar files(executable jar file) and a folder called lib which has five more jar files. Now I don't know whether it is possible to embed the game using applet/object tag. Can you please point me what to look at when dealing with these jar files.
..at the moment it is desktop version which he had to install..
Launch it from a link using Java Web Start. It might be necessary to digitally sign the Jars (what does the app. do?).
Note that a 'desktop application' would typically be coded using a JFrame, whereas the equivalent top-level container for embedding is a JApplet. A frame cannot simply be embedded in a web page.
As the rest of the problems mentioned, you'll need to be a lot more specific about what you tried and the results of those attempts, or find some psychic helpers.
I have heard and read a lot of people putting down Java Applets. I have a java a application written for the desktop. But with a few lines of code, I can deploy my application to the web as an Applet? I fail to see what is so bad about them. Can anyone inform me why simply converting my application to an applet is a bad deployment idea?
I have a java a application written for the desktop. But with a few lines of code, I can deploy my application to the web as an Applet?
With a few lines of JNLP, you can launch your (J)Frame based project directly from a web site using Java Web Start.
..Can anyone inform me why simply converting my application to an applet is a bad deployment idea?
'Browsers'. As you probably realize, an applet is a guest in a web page that is rendered by a browser. Browser/JRE/applet interaction bugs are the bane of an applet developer. There is a new one every other week. Avoid the browser, and most of the problems are solved in a stroke.
I deploy applets on my site, though I generally only make an applet when the web page can bring something to the applet. E.G. there is a properties applet that is configured using JavaScript.
But my general advice is, avoid applets if at all possible.
I personally don't see anything inherently bad about applets.
Applets do have restricted security permissions, so you will have less access to the system in question. If you're deploying over the web, though, I wouldn't expect this to be a big problem.
There's nothing inherently wrong with Java applets. We have apps deployed as both JWS desktop applications and as applets.
Applets do have a few shortcomings, however.
First, a page with an applet forces the Java VM to start up if it isn't already running; this can cause noticeable lags for users on many systems. (I think this might be a source of some of the negativity for applets. They were being (over)used on web pages for things like navigation bars that can be easily handled with DHTML with much less overhead.)
Secondly, an applet in a browser tends to be a more constrained execution environment. Unless you are using JWS, you don't have access to the file system, printing, and many other resources. You can't open connections except back to the server where the applet came from. You generally can't easily resize the applet window. There are probably other issues as well.
I'm sure others will point out more shortcomings. :)
we have this problem: we want to save files or print from java applet in browser, but this could not be easily implemented, as java applets don't seem to have rights for calling OS services. Is there any way to implement these two functionalities (maybe with server help etc.). What would you suggest?
Thank you in advance
For accessing resources outside the Applet sandbox, you'll need to sign your Applet, and set up the access privilieges at a policy file.
Here you can find a quite complete guide on Applets Security.
Well the solution was very simple :). In Netbeans -> Project properties -> Application/Web Start/{check the self-signed checkbox}. That's it with all certifications
Tomas is right. But probably I can suggest you a workaround. You can implement your print through browser. This does not require additional security permissions and applet might be unsigned.
To call javascript API from applet the applet must have attribute MAYSCRIPT and use netscape.javascript.JSObject. Yes, netscape! The name remained as a monument for this died browser.