I have about 6-7 months left of my Applet-based project. I wonder if it will even run by the time I'm finished?

As long as plugins are up-to-date they should be allowed to run. Give a warning if not, suggest upgrade, or block if its too old. Java is just as established as Flash, and there's no reason to discriminate because of security issues. Flash is just as riddled with security flaws as Java. Concerning signed applets, I think there's ground for extra security warnings.The best thing would be for Oracle to a major redesign of the warning system though.

I think a lot of these problems could be resolved with a better security dialog. Even I find it a little vague. An alternative could be a multi-page wizard dialog that tells the user what rights the applet is asking for and tells of their security implications, and where the user must manually enable each right. Self-signed applets should be restricted to the domain where it's distributed from and its certificate should convey this information.

deleted: wrong button

Wasn't that only until recently? Java applications used to be associated with ugly user-interfaces and poor performance. Applets only became useful (atleast for me) since update 1.6.10, which was probably a last-ditch effort by Sun to remain relevant on the desktop. It's a shame it took so long.

I think this Oracle lawsuit is a good thing. It will motivate Google to work on their Portable Native Client technology, which I think can be quite exciting for all kinds of platforms. At the very least, it'll give Oracle some competition as a browser vm (I dont find Javascript + WebGL + canvas particularly convincing).

Remember, it only takes Oracle one patch to remove those signed applets. 

Also, I'm getting a SSL certificate from Thawte for my domain. These don't work for signing jars right? The seller also adverticed certificates for jars, but they were very expensive. Is self-signed that display my domain name just as good?

I also have a lot of message passing going between the applet and javascript. Would a foreign webpage over http, that includes my signed jars on https, be able to communicate with an instance of the applet?

Info on my project: I'm making a "traditional application" and is using the webbrowser for UI. Javascript does message passing between the applet and the browser. When I want to load a file, I message the applet to show the file dialog, but I was thinking of adding a disk browser (read/traverse only) in the webpage instead. That's why I'm worried if other reference my jars and can get the same scripting capabilities on foreign sites.

I'm a little disturbed that by signing my jars and publishing them on the net, when users have accepted the certificate, any website can reference these jars with the certificate auto-accepted. Would hosting these by https help here? As I understand, you cannot mix webpages that use http and https.

I have serious regrets betting on applets, but right now it's the only way to get "full-access" to hardware in a web-browser. I think it's an excellent technology for distributing games on the web. Too bad it stagnated under Sun's leadership, and probably even worse under Oracle's.

I don't know if it's an omen, but I just recently ordered "The D programming language". Not exactly an alternative though and I love my Scala. 

I've just started adding JOGL to a webpage I'm working on using multiple applets using JNLPAppletLauncher to run the applets. It links to Sun for retrieval of the actual jars, so I'm wondering, is it possible to host these yourself? I use signed applets and it would be nice to have a common notice for all. JOGL2 with 3.1 is what I'd prefer to use.

Also, what alternatives are the to the JNLPAppletLauncher for applets? Can you trim the size of the jars even more with the new compression?

Ed:
After some testing by including the Gears applet, I seem to have some stability problems in Firefox 3.0.11 (WinXP 32-bit). For example, if I move the applet sometimes rectangles with the webpage's background color get draw in-front of the applet (like a mask over the applet). Also, resizing the applet produces flickering where I believe there's a delay between the canvas redraw until the OpenGL redraw (the background get erased twice). Even Java2d have this problem, so it's probably related to Firefox instead.

Yeah, it's a combo of everyones favourite technologies. It's an image processing app with multiple applet/flash for displaying data. I guess it's a very unusual use-case for applets, but I believe it might be possible to pull off. Just want to check first if someone else have experienced with this use-case. Everything is running dandy except for the bottleneck between java<->flash. Data is base64 encoded so it's crazy inefficient. lol.

What would be the best route to having multiple applets, each using OpenGL and sharing the same data? I'm currently using multiple Flash objects, but data transfer with the master applet is ultraslow and I need to replace them with applets supporting OpenGL. Ordinary usage will require applets to be able to be created and destroyed quickly (in ms). I see there is a caching mechanism for JARs, but I'm uncertain if startup time will still be slow. Also, could it be possible to let the master applet use OpenGL while the other applets acts as "dummies" (ie. not loading the OpenGL jars)?

Also, the latest Java 1.6 will be required by my app.

It would be real shame if the Java VM dies for the browser. I believe it's the best way forward for integrating "real" applications into the browser, if only they managed to modularize it and improve startup-time. Sadly, in terms for graphics, Flash is king.

Having add/remove programs flooded with java webstart stuff is a bit annoying.

Try and move

into resize() and add an attribute for canvas.

Now, I'm not sure about encrypting with LZMA is a good thing , but LZMA compression/decompression uses alot of memory. That's the price you pay for better compression ratio. You can to some degree control the memory usage by experimenting with the compression parameters (which control the size of the dictionary used by LZMA during decompression).

That (for the java code included) only gives you the ability to pack/unpack a single file with lzma. Handling the 7z archive format need additional code. The format is described though in 7zFormat.txt if you want to do it yourself.

ed: an easier way is to: your files -> uncompressed jar/zip -> lzma pack -> include in your program -> unpack lzma -> handle further as ordinary jar/zip

I've been trying to implement a custom classloader with applets but I'm having some performance problems.

If I create the classloader with the ClassLoader.getSystemClass() as parent, using defineClass (with bytecode) is fast. Problem then is that the instances I create from classes defined cannot find any class defined in the classloader used with the applet class.

When I use the  classloader from the applet class as parent in my custom classloader, the performance of defineClass get very slow (like 3-4 defineClass pr second).

I'm currently using the first method and using reflections to get around the problem, but it's a bit hacky, so any suggestions would be appreciated.

I couldn't find any java files in the sources jar.

How do you load the jar content? Do you use a custom ClassLoader?

ed: stupid me, trying to load a 7z file with the lzma decoder.

Java can't read the LZMA compressed jar. I was thinking of something along the line:
main jar -> applet + lzma decompressor + lzma-packed jars -> decompress and load jars -> run as normal

Is it possible to make decompression and linking usable within a signed applet? I'm currently at 5MB ultra-zipped, but with LZMA it gets down to 2.5MB.

Peculiar dilemma. I'm pretty sure that would be impossible, or else you'd be able to monitor keystrokes outside the webpage. You'd could probably use threads to build up a buffer for choords, but it seems like much work for the request.

That would be cool. I used to use the Virtual Piano with my Yamaha DB50XG, though it's not particulary touch-sensitive. It's pretty much hammering the keys.

Very cool synth (can I request virtual-piano mapping from keyboard? ). I've always wondered why audio-processing in game seem to be living in the stone-age while 3d-graphics have moved beyond imagination.

I atleast have no problem with requiring 1.6 update 10 and fallback on Flash with limited functionality.

Update 10 have the separate_jvm parameter. Maybe that could help (with refreshes too). link

Concerning your users: inform them that your program is much more stable with update 10 and include some instructional text on how to install the update. Needless to say, the java updater is a horrible openoffice pushing bastard. They got alot to learn from how Adobe have handle Flash, though I suspect Adobe will start pushing AIR more agressivly too (as in Adobe Reader).

I just discovered this too and been able to push memory up to atleast 800mb. Needless to say, ranting mode off.

Wonder if JavaFX pushed this into the update (or maybe I should say, Adobe pushing into the Application domain)?

I need ALOT more. I'm doing image processing and my current implemention in Flash can use up to a gigabyte or more of memory. Who the hell thought 64mb of memory should be enough (640K is Enough For Anyone)!!! I'd actually like to stay in Flash, but the JavaVM allows for so much more so it's a bit fustrating walking into the Applet world.

I'm doing a port of some Flash code to an applet, but stumbled upon a little problem: the heap size of an applet. Some surfing suggested that the heap size for applets are a static size and it can be changed with each user speficying the size in their control panel. Is this right (in which case the responsible ought to be shot! )

Are there any work-around for this (like a signed applet etc.)? My entire interface relies on the webbrowser.

In Firefox, the browser will ask if executing a jar. Maybe you have turned this on auto-accept at a previous time?