JOGL + Applets or JavaFX

OpenGL Development JOGL Development
#1

So the last time I had a look at trying to use an applet to do some JOGL stuff, things were not looking too stable.
What’s the latest take on the situation?

1 Are people using this combination in production?
2 Is it any more stable than 6-12 months ago when I last investigated?
3 Does JOGL 2 address this topic in anyway?
4 Is it running all browsers all platforms? if not which ones have problems?

The reason I’m interested is that many of my users seem reluctant to work with Java (either applets or webstart), but are quite happy with flash. I played a game this week via facebook called FarmTown. It’s flash based and can be a bit slow, but it just seems to work pretty good in each environment I’ve tried. There are no popups, ugly dialogs, certificates, warning bars about being an applet etc, and it can even go into full screen.

So what’s between the current state of Java, and getting a JOGL application running in as user friendly manner. I mean JOGL is crying out to replace flash based games, how do we enable that?

I don’t want to upset anyone, but the whole JavaFX thing just seems to be a big distraction from fixing the known issues with applets and webstart. And from what I last saw, was nowhere near production ready. Or is the plan to abandon the issues with webstart and applets and focus only on JavaFX. If so, how is JOGL fitting into that picture? Can I realistically release a game that’s going to run in all environments across mac, linux and windows?

Sorry to ask so many questions in a single post! And I know the JOGL team is not responsible, but many of the readers here must surely be having similar issues / considerations?

Peter

PS From the mac side the current applet security flaw isn’t helping with many users disabling Java alltogether.

#2

Well, one of the reasons I left JOGL for LWJGL was because of the applet launcher having a tendency to be quite buggy and every now and then launching two instances of my applet instead of one, making the FPS unbearable.

Other than that, it works on all platforms I tried it on and it seems stable (except for the bug mentioned above).

The best thing now is that it doesn’t ask for any permission at all when starting up, really wonderful.

#3

[quote]The best thing now is that it doesn’t ask for any permission at all when starting up, really wonderful.
[/quote]
heu… have you got a demo that does not ask ? I never seen such

#4

have a look here https://jogl-demos.dev.java.net/applettest.html

#5

6u10 or later is precondition, otherwise you will still get sec dialogs

#6

yup, I still got the warning here

#7

Hi!

JavaFX is a big joke, it is far from stable.

Yes of course but not yet with an applet. Wakfu is an excellent example as it uses JOGL. I use Java Webstart and it works just fine. In October 2006, I hesitated in using applets with JOGL as it was already a bit buggy but I had even not noticed the bug you mentioned.

#8

I guess you are aware of the following, ie Applet JNLP integration using JOGL.
https://jdk6.dev.java.net/plugin2/jnlp/#EXAMPLES_WORLDWIND

True, this is JNLP integration is currently not available on MacOSX, I guess.
We don’t know about the timeline there …

1 Are people using this combination in production?
Worldwind, JavaFX, …

2 Is it any more stable than 6-12 months ago when I last investigated?
We are working on the JOGL2 branch, as you know. Sure it shall be more stable.

3 Does JOGL 2 address this topic in anyway?
Not really.
JOGL has nothing to do with deployment, it’s a language wrapper :slight_smile:
Sure, you can deploy it as you wish, using JNLP or the other techniques.
The difficulty is more the lack of appropriate deployment of the utilizing platform,
ie no JNLP / plugin2 support etc.
If more workarounds are necessary to achive true usability … let’s talk about it.

4 Is it running all browsers all platforms? if not which ones have problems?
All plugin2 / JNLP-Applet supported platforms can utilize JOGL in applets in a seamless way
without any hassles.

Regarding JavaFX … well, you are right, it’s another product where we don’t have any
political responsibility. Let’s not talk about it in the JOGL forum, it’s futile :slight_smile:

Long story short answer, if any deployment mechanisms are a showstopper for your product,
let’s find a solution. Since it is not a JOGL feature to hinder you from deploying your stuff in applets.

#9

as the new plugin seems to be the ultimate solution for nice applet deployment, is there any plan to propagate it (and further version) as fast as flash in a seamless manner ?

because IMO there was two problem for java applet :
1 - plugin was too much buggy and not user friendly => solved by new plugin
2 - update of java plugin on client platforms take age => not yet solved

may be one solution could be to enable a very smooth installation of java new plugin when requiered, something really fast and with clear explanation of why it is requiered without any advertisments or complexe setting => just “Install Java” => Ok => “Install finished”.

#10

something like:

    
    /**
     * Triggers a JRE installation.  The exact effect of triggering an 
     * installation varies based on platform, browser, and if the 
     * Deployment Toolkit plugin is installed.
     *
     * In the simplest case, the browser window will be redirected to the 
     * java.com JRE installation page, and (if possible) a redirect back to 
     * the current URL upon successful installation.  The return redirect is 
     * not always possible, as the JRE installation may require the browser to 
     * be restarted.
     *
     * In the best case (when the Deployment Toolkit plugin is present), this
     * function will immediately cause a progress dialog to be displayed 
     * as the JRE is downloaded and installed.
     */
    installLatestJRE: function() {...}

http://java.com/js/deployJava.txt
http://java.com/js/deployJava.js

for initial deployments you could even try this on windows (have to admit, i havent tried it yet)

   
<script src="http://java.com/js/deployJava.js"></script>
<script>
deployJava.setInstallerType('kernel');
    // required jre packages for startup
    deployJava.setAdditionalPackages('javax.swing, javax.xml');

    var attributes = {codebase:'...',
                      code:'....class',
                      archive:'....jar',
                      width:710, height:540} ;
    var parameters = {} ;
    var version = '1.6' ;
    deployJava.runApplet(attributes, parameters, version);
</script>
#11

Wow that generated quite some feedback, thanks all! So some follow up:

[quote]Well, one of the reasons I left JOGL for LWJGL was because of the applet launcher having a tendency to be quite buggy
[/quote]
Is the situation with LWJGL any better? or do they have a deployment method that JOGL doesn’thave access to?

[quote]have a look here https://jogl-demos.dev.java.net/applettest.html
[/quote]
The mentioned demo relies on Java 6u10, something mac users don’t have. Also when I tried this demo it was drawing over every tab content in firefox and still scrolls above the address bar etc.

[quote]Wakfu is an excellent example as it uses JOGL. I use Java Webstart and it works just fine
[/quote]
I’m using webstart also, and yes it does the job, but I still have to have 2 certificates (suns and mine) and a possible download / ugly popup of some nature before a user can play. And we haven’t got to the fullscreen issues that java was supposed to support several versions ago. Compare this to how a flash game works. Yes it works, but it’s not user friendly.

[quote]I guess you are aware of the following, ie Applet JNLP integration using JOGL.
https://jdk6.dev.java.net/plugin2/jnlp/#EXAMPLES_WORLDWIND
[/quote]
As you said, it’s windows only. But also when I click the “Click here to get the new Java plugin” I get a less then user friendly page “https://jdk6.dev.java.net/6uNea.html”. And maybe it’s a good time to point out that JOGL is using 1.4 syntax (btw, fine by me) but then it’s enabling technologies reply on 1.6 update 10. In fact it feels like for the last n years since even GL4Java and all through JOGL’s lifecycle I’ve been waiting for the magic Java release were all this will pull together in a useable fashion. Fullscreen support would be a good example. But mainly from the users perspective.

[quote]> 1 Are people using this combination in production?Worldwind, JavaFX, …
[/quote]
JavaFX seems to be Sun’s attempt to make up for failing to capitalise on applets and playing catchup with Flash. It looks like another half baked solution that isn’t going to help us.

[quote]Long story short answer, if any deployment mechanisms are a showstopper for your product,
let’s find a solution. Since it is not a JOGL feature to hinder you from deploying your stuff in applets.
[/quote]
I know this isn’t the fault of anyone here, or of the JOGL technology, but rather it’s enabling technologies. But without a really strong solution, JOGL is going to fade away. Maybe it’s already too late? Overall JOGL2 is looking great and it’s good to see things like ES1.1 and ES2 being added. Maybe the approach here is imagine how a JOGL/Java ES1.1 app would run on Android for example. What would be the enabling technology? It has to be very light weight and just work. Then take that solution for all JVM1.4 environments across the desktops.

[quote]may be one solution could be to enable a very smooth installation of java new plugin when requiered, something really fast and with clear explanation of why it is requiered without any advertisments or complexe setting => just “Install Java” => Ok => “Install finished”
[/quote]
This is what I’m getting at. Flash just works, all platform, all browsers, no work arounds and from a user experience it’s super fast.

I can’t say I’ve looked at using Flash, and don’t really want to go down that road. Java was built for this :slight_smile: Just off the top of my head, could the community manage to write their own broswer plugin for Java & JOGL? What applets should have been, with a focus on the user experience. ie fast startup, ultra simple installation. JOGL is 1.4 compatible? So all we need is a bridge between the browser and whatever JVM/pluggin the client currently has installed. Or does JOGL have 1.6 dependencies? (thinking fullscreen here). Or could the new plugin be extracted as a standalone lightweight 1.4 pluggin?

On the other hand, if Sun hasn’t managed to acheive this in 14 years what chance does the community have.

#12

[quote]could the community manage to write their own broswer plugin for Java & JOGL?
[/quote]
this is what 3DzzD do 8), it perform its own JOGL installation at runtime :

once loaded, pressing H will install JOGL at runtime, M key will load the Robot class that also requiere signed rights.

http://demo.dzzd.net/FPSSample9/

no security warning or long download at Applet startup, this is also a way that we (with Thijs) have suggested to the JOGL community, while working on a JOGL runtime loader that finally become a quite anoying JOGLAppletLauncher


#13

the startup is very nice and clean, and fast!, but:

[quote]once loaded, pressing H will install JOGL at runtime
[/quote]
still pops up a secutiry dialog for certificate.

Also I had a quick look at the code at it seems I’d need to pull in your entire framework to be able to do something similar. It’s nice that you’ve made it a generic approach, but I’m looking for something that just gets JOGL up and running as fast as possible with minimal code but also without the certificate popup. Good work though! I hope you continue to push it forwards.

#14

Isn’t possible without u10. But If you use the JOGL extension in webstart you can at least leave your code unsigned (as long as you don’t access the users harddrive I think) and the security dialog only displays a certificate from SUN which might look more trustworthy. Also if you are lucky, the user already checked “trust always” for the sun certificate on another occasion (but that’s not very likely :/).

That’s best as it gets. Even if you would implement an active-x plugin or a firefox add-on, you would have to convince the user to install it, which might not be any easier than to convince him/her to approve the security warning with webstart.

#15

There’s nothing wrong with a security pop-up per se. It’s just that the current crop of security dialogs are bloody scary looking things. When they look a lot more friendly it’ll be a whole lot better.

Cas :slight_smile:

#16

[quote]As you said, it’s windows only.
[/quote]
Works on Linux 32/64 bit for me very well.

[quote]But also when I click the “Click here to get the new Java plugin” I get a less then user friendly page “https://jdk6.dev.java.net/6uNea.html”.
[/quote]
You sure need one of the new JRE’s installes >=1.6.10 aka 6uN aka 6u10.

BTW these plugin2 JNLP demos show you exactly how to use it with JOGL.
And since it the JNLP libs are cached, the security dialogue is popping up only once.

Well, even though Ken wrote the whole MacOSX plugin2 port, it is still not available, sorry.

[quote] And maybe it’s a good time to point out that JOGL is using 1.4 syntax (btw, fine by me) but then it’s enabling technologies reply on 1.6 update 10.
[/quote]
The reason is for mobile/embedded devices with some old Java version.
And this will not change for sure.

[quote] In fact it feels like for the last n years since even GL4Java and all through JOGL’s lifecycle I’ve been waiting for the magic Java release were all this will pull together in a useable fashion. Fullscreen support would be a good example. But mainly from the users perspective.
[/quote]
Give me a break :slight_smile:
Fullscreen just works, AWT or even Newt on embedded devices.

Remember, JOGL is not a deployment strategy :slight_smile:

So, use the new plugin, and/or Webstart, or write your own.

The new plugin is automatical available if using Sun’s JRE … see above.

#17

[quote]Well, even though Ken wrote the whole MacOSX plugin2 port, it is still not available, sorry.
[/quote]
No problem, I understand this is the fault of Apple and their switch in focus to objective-c. It seems they have done a good job of crippling Java under OSX (eclipse, 32bit, applet bug, java6 updates etc). So any chance the plugin2 could be bundled as a separate Java 1.5 additional download & install .dmg??

[quote]Fullscreen just works, AWT or even Newt on embedded devices.
[/quote]
Not on OSX, when in full screen, any popup dialog just results in a black non-responsive GUI and has done for a long time. ( I posted somewhere about that a long time ago and as a result had a few people contact me with the same issue). But it sounds like NEWT might be a good alternative. Is NEWT something worth me investigating more for cross platform fullscreen support? or is it still a risky undertaking for production usage? If it’s a reference implementation does that mean it’s not supported or won’t be fixed?

[quote]‘Cas’ There’s nothing wrong with a security pop-up per se. It’s just that the current crop of security dialogs are bloody scary looking things. When they look a lot more friendly it’ll be a whole lot better.
[/quote]
Yes I think that’s more the point I was trying to make. To consider this whole issue from a users perspective, and Java can be scary :slight_smile:

So how can we make webstart-ed JOGL as painless as possible for the end user? That means keeping JOGL at 1.4, and possibly making it’s enabling technology (plugin2?) available to anyone still running 1.4 and up?? this would then detach JOGL from it’s dependence on 6update10. NEWT sounds like a good step in abstracting some of those dependencies. btw. Do we have updated user manual for JOGL2 someplace that covers NEWT usage and all the JOGL2 migration changes? Reading though JavaDoc isn’t much fun :wink:

Anyway nice to see the nightly builds returned! I wish I had a bit more time to migrate my game across already.

#18

[quote]So how can we make webstart-ed JOGL as painless as possible for the end user?
[/quote]
you can just load it at runtime…

#19

[quote]you can just load it at runtime…
[/quote]
I had a look at your project, and to be honest I was a bit lost with how you were doing this because of the rest of the engine you have wrapped around it. How about extracting out the guts of the runtime loading into a small standalone package? I’d be happy to test :slight_smile:

#20

you can find detailed informations on how to here :

but seems that the boring JNLP version has been prefered :stuck_out_tongue:

https://jogl.dev.java.net/issues/show_bug.cgi?id=312