14

I have some non-trivial computational code that need to be applied on data already downloaded into the browser DOM and captured from user interactions. I do not wish to expose this code. I am wondering if:

  1. Write a webservice and communicate with the browser over websocket or HTTP. The trade-off is speed of interaction (from slick to poor) and higher traffic costs.
  2. Write a Java applet (signed to hide the code) that encapsulates logic within the page and let JavaScript interact with the Java API. I read elsewhere that the Java and JavaScript engine can deadlock in certain scenarios. However, since I am only computing, this is a non-issue. Maybe, on multi-core machines I could divvy up my work using a few more threads.
  3. Write in JavaScript. But JavaScript is difficult to test, and it's all in public eye.

Q&A such as Usability of Java applets on the web and several others are also discouraging.

Are Java applets a dead technology? There aren't even Q&A on this topic these days! Additionally, Java may not always be bundled with all browsers (desktop, tablet or mobile)?

Are there better ways to accomplish the same like hide code, utilize client CPU/RAM, minimize data traffic?

The web pages are on JavaScript, HTML5, and CSS. The server only dishes out JSON and XML. The data packets are 10-20 KB and updated frequently. The computations are expensive and client-specific, so I would really like to use the client to do all that.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dinesh
  • 4,437
  • 5
  • 40
  • 77
  • Applets aren't in vogue as it were , but if they are a good choice for you they why not use them. If you need access from mobile browsers then applets are not the right choice - put your code on the server. Of course if you write your logic in Java and deploy using an applet , you could always run the same code on the server , either at the same time as your applet version is in use, or at a later date if people don't like your applet version for whatever reason. – davidfrancis Jul 15 '12 at 22:58
  • 1
    Have you considered using Flash? – LisMorski Jul 16 '12 at 05:53
  • david, a very insightful remark, thanks. – Dinesh Jul 16 '12 at 13:06
  • Lis, I had considered flash but I really don't want to support it. My visualization is on the canvas, therefore the flash object must be put away in some obscure corner, probably sized 0x0. Users w/o flash (such as flashblocker fans which includes yours truly) will miss several whole functions without even realizing it. – Dinesh Jul 16 '12 at 13:16
  • Well no they are not dead. They may be dead to you or dead to what you are doing but that doesn't mean they are dead. The icedtea-web project are still getting daily source commits and Firefox ESR still supports it. In RHEL and all derivatives it runs without problem. It is not at all as dead as for example silverlight as that never became popular in the first place. – user1657170 Mar 14 '19 at 14:34

6 Answers6

19

I thinks the biggest disadvantage of an applet is that it assumes you have a JRE installed on a client machine. Is it really a viable assumption?

Of course, you can offer to download and install JRE as well, but why bother doing all this only for making some computation? Another question I would ask myself, can your clients be mobile phones, tablets and so on? If so, maybe JavaScript is a better option to go with.

And yet another two cents :) You mentioned 'opened to eye JavaScript' You should understand that the only real way of protecting your computation code is putting the computation on server. I mean, that even if you have a compiled binary code, Java's assembly is easy-to-understand for a skilled attacker. And obfuscation that you mentioned (it's obfuscation, not signing a JAR file) makes it slightly harder, but still not impossible.

The only concern I see here is that if you have a lot of clients that are running the computation simultaneously and you put the burden of computation on your server it can collapse eventually.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
  • Oh, the inflation :) But really, very thoughtful comments, thanks. – Dinesh Jul 16 '12 at 13:02
  • For the moment, I will to take the cost hit and move the key compute elements to the server. Plus have a rethink. – Dinesh Jul 16 '12 at 13:25
  • *"can your clients be mobile phones, tablets and so on?"* Good point. A growing market that applets are unlikely to (ever) run on.. – Andrew Thompson Jul 16 '12 at 13:40
  • True enough, Andrew. I have been talked out of using applets. – Dinesh Jul 16 '12 at 18:51
  • @Dinesh It's good that you were talked out of them. I added an answer (pretty late to the party) but as of September 2015 they are dead. Including Silverlight. The fact that a browser with a pretty huge percentage (if not the most) of desktop users stopped supporting them. They are dead – John Demetriou Nov 04 '15 at 15:25
  • I'm still developing and using them. No they're not dead. Why miss out on the best way for rapid rich client development and deployment. RHEL and CentOS still support Applets by default and the mailing list of the development group for IcedTea-web is still very active. Sure if are depends on getting users with mixed devices to use your app then I'd suggest a different solution but in an enterprise setting that's not an issue. If I want an employee to use windows 3.1 the employee will use windows 3.1. – user1657170 Jun 06 '20 at 08:23
13

As of September 2015 they are dead to me. There are pros and cons for using applets. But Chrome stopped supporting them, so by using them you simply don't support Chrome for desktop and when it comes to mobile browsers, which of them support NPAPI?

Official Oracle announcement:

Chrome no longer supports NPAPI (technology required for Java applets) The Java plug-in for web browsers relies on the cross platform plugin architecture NPAPI, which has been supported by all major web browsers for over a decade. Google's Chrome version 45 (scheduled for release in September 2015) drops support for NPAPI, impacting plugins for Silverlight, Java, Facebook Video and other similar NPAPI based plugins.

Java applications are offered through web browsers as either a web start application (which do not interact with the browser once they are launched) or as a Java applet (which might interact with the browser). This change does not affect Web Start applications, it only impacts applets.

If you have problems accessing Java applications using Chrome, Oracle recommends using Internet Explorer (Windows) or Safari (Mac OS X) instead.

UPDATE 1 Microsoft Edge also does not support them. So another blow against the already dying Java applets.

UPDATE 2

Announcement from Mozilla

Important: The new 64-bit version of Firefox for Windows does not recognize or support this plugin. See this Mozilla blog post for details.

So yeah. Java applets are dead.

UPDATE 3 Oracle officially killed them with Java 9.

UPDATE 4 Java Web Start is also dead. From Java 11

John Demetriou
  • 4,093
  • 6
  • 52
  • 88
  • *"Google's Chrome version 45 ... drops support for NPAPI"* Last time I heard, FF had similar plans. I also hear IE 10 does not support them.. What's that leave (in terms of 'major' browsers')? .. Safari? Opera? If applets weren't dead before, they're looking more like corpses with every passing minute.. – Andrew Thompson Nov 05 '15 at 05:04
  • 3
    Applets were officially sentenced to dead by Oracle: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free – Vadzim Nov 01 '16 at 15:41
  • 2
    Your **EDIT**, **EDIT 2** and **EDIT 3** seems like `Slow Death`. Hilarious. :D – Faizan Mubasher Mar 16 '18 at 06:26
  • 1
    @FaizanMubasher Well it kinda was. I mean one by one the browsers stopped supporting them, so I was editing my answer. Then oracle themselves killed them so that was the final nail in the coffin :) – John Demetriou Mar 16 '18 at 06:28
  • 1
    @JohnDemetriou Its good keep updating answers but that made me laugh. And still laughing while writing this comment :D – Faizan Mubasher Mar 16 '18 at 06:31
  • 1
    isn't Java Web Start (Java 11) killed too? (at least by Oracle) – user85421 Feb 16 '20 at 09:31
4

..write a Java applet (signed to hide the code)

Code signing is for the user's protection, not ours (or for protecting the code). It simply adds extra files. Perhaps you are thinking of obfuscation, which makes it mildly more difficult to steal the code. In fact, obfuscated JavaScript code would be harder to decipher than digitally signed (but not obfuscated) Java classes.

The only real solution here to protect the code is to leave the important parts on the server. JavaScript could probably handle most, if not all, of the user/browser/server interaction, so the only part a Java applet might play in this is for visualizing the returned (calculated) data. Even, then, I'd probably look for ways to show the result in an HTML 5 Canvas.

So the answer to your question...

Java applets - is it a wrong choice today?

Yes, for this use-case. An applet adds little or nothing over what could be supplied in pure JavaScript/Canvas with the grunt work being done on the server.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • I agree, JS can get so much harder to read. Also, I am not planning to use applet for any visualization. – Dinesh Jul 16 '12 at 13:04
1

John Demetriou presented very good information.

Additionally now (July 2017) only Firefox and Internet Explorer (and maybe Safari not sure) is allowing the usage of applets. You can use them if you meet the following three requirements:

  1. You allow the HTML site which accessing the .class applet file as an exception in the Java control panel
  2. Java is updated to the version the browser supports (most likely latest version)
  3. The .class file is located in the same location as your HTML file!

You access the java applet, by typing the HTML content's location in your browser. You still may receive a prompt, requesting whether to run Java, so just accept.

I only presented this information just to let people that there is a way to run applets. However, applets were disabled for a reason. They allow many security leaks. Use them only to learn their technology and gain some insight. They are not recommended elsewhere.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
KeyC0de
  • 4,728
  • 8
  • 44
  • 68
-2

Applets will always be a good choice, when you have to use the client machine, i.e.: using biometric solutions or hardware stuff like.

But if you need only cosmetics or computing power, I guess a better way is for refactoring the code, make it light and clean, with as few conditions as possible. Maybe using some views or stored procedures should help if you have separate server machines (DB and IIS for example).

I'm locked in a project for which the only solution was the applet... Another choice was ActiveX, but it locks my client to Internet Explorer and we don't want it.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Angelo Simonato
  • 124
  • 4
-2

Well, first of all Java applets are a growing technology and far from dead. Secondly, browser and user installs are declining. Some use the declining installs to claim that Java is dying, but that claim is false, as there always have been a lot less actual use of Java applets than there have been installed plugins.

But with your description I would probably not choose applets. It's a powerful technology that I would use with a user base that I know would install whatever they need in order to use it. It's good for games, intranet sites, etc. On an intranet, the IT department can make sure that the applet works on all desktops that need to use it.

But in your case I would use Vaadin. It transforms a Java application into a web applications using JavaScript. Furthermore, it protects your code which is a main feature in Vaadin. Most of your code would run as Java code on the server, and only the GUI frontend is run in the browser.

As a result, Vaadin is much slower than applets (because of JavaScript). It is also much slower than most other web frameworks, because it relies heavily on running code on the server. This of course also means that your calculations will not be translated into JavaScript and transmitted to the client computer.

However, you will not have access to the powerful Swing API. Vaadin has its own Swing-like API that only covers a small portion of what Swing can do. But on the other hand so there are no other web framework that can do what Swing can do.

There really isn't any way to grant all your wishes. If you use the client for computation you will expose your calculations. There isn't any way around that. Not even if you write a native application in C++. It can still be reverse engineered and extract your calculation. Therefore I recommend that you run your calculations on the server, and find a way to bill the user. That's exactly what you do if you use Vaadin.

If you, on the other hand, want to do calculations on the client you really should use Java applets. Java is way faster than JavaScript when it comes to making calculations. Flash is faster than JavaScript, but Java are still way faster.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user1657170
  • 318
  • 2
  • 7
  • thanks. Vaadin has been around of course. And we ended up doing all computations on the server side - also the consensus opinion here. It is expensive, while the client cpu is burning electricity on screen savers :( – Dinesh Oct 02 '14 at 00:00
  • Well if you want to protect your algorithms they simply can't run on the client. Anything that run on the client are open for reverse engineering. Even with Vaadin you can push work to the client but by creating a GWT-based control, but that would of course expose your algorithms to the client. – user1657170 Oct 20 '14 at 12:58
  • 1
    As of a month ago. To me they are dead. Chrome topped supporting them. So simply use html5 and js, or do it on the server – John Demetriou Nov 04 '15 at 14:39
  • I still use them a lot and RHEL (and various other Linux distributions) also still support them. When building UI:s Swing are superior to anything that HTML and JS can do. Web Assembly looks like a promising replacement which I will look at once it has threads and garbage collections. However I'm not going to rewrite my applet code unless I have a very good reason. Another candidate has been Vaadin but it's to slow. The only alternative I see right now is something not running in the browser. That however requires rolling out client software. – user1657170 Oct 20 '18 at 08:51