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. :)
Related
i am currently writing a game on javaFX and i have plans to post it in the website i run in the future (end exploit the Ads while at it). The problem is that after searching around a little it seems there is no way to run a java application on a browser.
Allowing people to run it through the browser would really help sharing the program.
My question is: is there today(2018) any way to run a java application through the web? Though i like java, no browser support seems like a really, really bad idea.
Oh, i also heard of Java Web Start. Although it looks like it is just avoiding the problem (not running in the browser) it seems like a good way to share an application. The problem is that it seems it is (Will be?) deprecated? I am helpless, it is like java isn't even trying anymore...
PS: If it makes any difference my game would be a 2D game with 3rd person view. It will also require some server stuff since players will create "arenas" that others can challenge. I would say my game wouldn't be "simple".
Java Web Start does the job very well—if you are willing to pay for a code signing certificate. (They’re a lot more expensive than regular SSL certificates.) The idea is that a user clicks on a hyperlink on your page, which causes the user’s Java installation to launch your application (possibly after installing it). This requires users to have Java installed beforehand.
If you don’t have the resources or desire to go with a code signing certificate, you can look at https://docs.oracle.com/javase/9/deploy/self-contained-application-packaging.htm. It allows you to create native installation packages for JavaFX applications. The disadvantage: You need each platform to create an installer for it. Meaning, you need Windows to create a Windows installer, OS X to create an OS X installation image, and Linux to create a Linux package. Some may also require signing using native tools.
Java 9 includes the jmod and jlink tools, which are capable of creating a file tree with an executable shell script or .bat file. A major advantage is that you can build such a tree for any platform, regardless of your own platform, if you unpackage the foreign platform’s JDK on your machine. Another advantage is that the user doesn’t need to have Java installed at all. A disadvantage is that the script requires a terminal, unless running on Linux.
Of course, you can just go the manual route and distribute a zip file which contains your .jar file(s), a shell script you’ve written, and a .bat file you’ve written. It’s not elegant, but it’s better than nothing. But it may trip up some non-technical users.
There exist a number of tools which create a native executable from .jar files, but I am not familiar with them (and I prefer to avoid third party tools unless they are truly necessary).
Whatever approach you choose, the answer is the same: You distribute something on your web page which the user downloads and runs. Aside from the download process, the browser is not involved.
What you can’t do is have users run your application inside the browser. That is deprecated, with good reason: It’s a disaster for the browser performance, for the Java runtime, for security, and for the user experience. And Firefox has all but banned plugins, so you’d be locking out a substantial percentage of users.
So, how much trust do I need to have in a publisher before I run their applet in the web browser?
In other words, I understand that a java applet is run in a sandbox in the browser, but this article suggests that the applet can actually access files stored on the local computer.
Can you please clarify the security limits of a java applet run in a modern browser, such as Firefox 50?
I understand that a java applet is run in a sandbox in the browser, but this article suggests that the applet can actually access files stored on the local computer.
There are potentially three different levels of security available to a Java applet.
The first is as you described 'sandboxed'. They can only access resources from their own server, nothing on your local file system unless they are launched using Java Web Start & will thereby have access to the services of the JNLP API. You might note that two of the services are the FileOpenService / FileSaveService! If the applet goes to use these, the end user will be prompted to permit the action via a dialog that states what the applet is trying to do, and asking for permission to proceed (to show a file chooser & go from there). These services provide back a 'file like' object that is more limited than the normal File API would supply. For example, it will not provide the path to the resource, just it's name and access to the content.
The level up from that can be specified in the launch file - '(J2EE) application client permissions'. This level removes the prompts for use of the JNLP API services.
The highest level of access is obtained by requesting, and being granted, 'all permissions'. Then the applet should have full access to File objects, be able to communicate with servers other than the one that launched it, etc. One of the few things they would still not be permitted to do in this mode is to call System.exit(n) to effectively 'kill the JRE' - this is something that is commonly done in other desktop apps.
But then there are JRE bugs, that screw all that up. Sun, then Oracle, kept stuffing up security so poorly (& regularly) that many browser manufacturers are entirely removing the support for applets (and other embedded objects requiring plug-ins) in web pages.
See Java Plugin support deprecated and Moving to a Plugin-Free Web for more detail.
..how much trust do I need to have in a publisher before I run their applet in the web browser?
I cannot answer for you, but my take would be that I would need to know them personally, and trust completely both their integrity and competence before I'd run their code in any browser I controlled.
Having said that, I don't think I have a single browser installed that even supports applets, and my complete lack of motivation to set something up, is probably a good view on whether I'd allow applets to run on this PC at all.
I have created a Java applet as part of a request from a client for a web-based program, and while I've gotten it embedded, Chrome has disabled support, you need to bypass various security protocols in both Internet Explorer and Firefox, and Edge doesn't have support for java in the first place. My question is, is there some sort of way we can run this program through a wrapper or an alternative way of getting it on the web without re-writing the entire program in a different language? Thanks!
Realistically, as you're seeing, applets are dead. Your best option is to use Java Web Start and convert your applet into an application. That really isn't too bad to do but it will require some work.
Basically the server sends a JNLP file that runs an application. The application (i.e. your Java application) can be downloaded from a remote server so that you don't have to have pre-installed anything except for Java on the client machine.
Today I'm using an applet to modify client-side information, considering the new browsers i have to found out a new workaround to continue modifying file and execute windows command at client-side because some browser are suspending the applet execution.
Any ideia for solution that has allow windows command execution and access file at client side like Activex ?
Applets have always been sitting between webapps and desktop apps. In that sense, what you want to achieve is exactly what every hacker in the world wants to achieve, that is gain access to your computer from a browser. And I think it would fair to say that for that reason, applets are dying and are not coming back from the dead anytime soon.
But unfortunatly some functionalities need applets to run, and what you can do really depends on those functionalities.
Statu-quo
They are still working in IE (not Edge), Firefox and Safari. If you control your clients environment you can maybe still use them as is. But for how long ?
Move to Server
You move your functionalities on the server. In your case, it would probably mean upload files on the server, execute your commands there and send the file back on the client. Javascript and HTML 5 can certainly help here improve the overall user experience.
Move to Desktop
If you are doing some pretty intensive stuff on the client (processing multiple files, accessing resources that cannot be used from a browser, etc), you should consider regrouping this into a desktop app. You can even launch your app from a browser and sends some parameters to it by registering a Custom Protocol Handler, a la iTunes. Again, this is certainly not an easy replacement, as functionalities will often be spread out between the desktop app and the web app, which makes for some interesting scratch head moments trying to link the 2.
I am looking to start a java web applet, as I need something that doesn't need downloaded (saved to computer) and for the most part will work for Windows and OSX.
I have never done anything with java, so my question is can you do everything you can do with a normal java jar file on the web?
More specifically, can you write a web applet that detect window titles (Like the title of an active window), running processes, look in the windows registry, or find hard drive serial numbers?
The applet needs special permissions for these type of actions. It needs to be signed and trusted by the user.
Have you considered using Java Web start? If the communication with the browser from which the applet is run is crucial, then applets are probably the way to go. Otherwise Java Web start is preferred as you'll face less compatibility problems with browsers' Java plugins and different JVM versions.
Yes, but your applets must be trusted by user (user change some browser security settings)