Which Java version to use in an applet?

Networking & Multiplayer
#1

Hi,

if somebody wants you to program an applet so that users can use/play it in their Browsers (like a Flash animation): which version of Java are you allowed to use?

I’ve to confess I don’t know much about Applets and Java in browsers. As an (satisfied) Opera user my browser always uses the installed Java which is … 1.4.2 in my case. :slight_smile: However what’s with those Netscape browser users, and especially those “few” Internet-exploder users? Does the WinXP IE contain Java at all?

#2

As for now, the standard IE config still uses Microsofts (broken) 1.1 VM

However, this VM will cease to exist and people are migrating to the next best thing ™
So sun 1.4 is a good guess.
If the user doesn’t have a VM yet, they should go for the newest anyways

#3

Sun has been making a strong (successful) push to get a proper JDK installed on new PCs. We currently have deals in place that will mean that something like 50% of all new PCs shipped now will come with the latest Sun JDK.

Between our pushing to get real Java out there, and MSFT’s threat/promise to be dropping distriubtion of MSVM, I’d target 1.4 or so if I wasn’t shipping immediately OR shipping to a market of primarily older machines.

One compromise for web based apps is to use Java Web Start rather then Applet. Java Web Start JNLP files allow you to specify the requirements for your app, inlcuidng VM type, and it will coordinate downloading VMs and such if they aren’t already resident.

Java Web Start applications also can have all the capabilities of Applications rather then the (limited) Applet model. They have sophisticated class cahcing so, unlike applets, the Java code is only downloaded once and not downloaded again unless its been updated. And after they have been run twice by the user, they can install shortcuts such that the user doesnt even have to open their web browser to launch your app.

About the only thing you can’t do better in a Java Web Start app then an Applet is embedding the Java in an HTML page. Only Applets can do that, Java Web Start apps open a new frame to run in.

#4

Thank you for your helpful answers.
Good news, Java 1.4.0 is pretty OK. I’ve been afraid to use Java 1.1 or such which I would hate. :wink:

I think Webstart isn’t an option because the one who asked me for an applet wants it to run inside the browser (like a Flash .swf codlet).

Java on 50% of the new PCs is going to be really good. Helps deploying real Java games (standalone applications, no applets) a lot, too. :slight_smile:

#5

Another good thing about getting such a significant number of machines with “real” Java is that there will be some trickle effect to those without it simply because they see it on some other system and choose to upgrade their own… the numbers for that will be small though, unless WE generate some compelling content that REQUIREs modern Java.

#6

quote unless WE generate some compelling content that REQUIREs modern Java.
[/quote]
Very true. So it’s up to us… :slight_smile:
Cas did contribute his bits already, so that mean :slight_smile:

#7

[quote]I think Webstart isn’t an option because the one who asked me for an applet wants it to run inside the browser (like a Flash .swf codlet).
[/quote]
Yeah if you want it to actually run as part of the web page as oppsoed to just being launched from the web page and then running in its own window, you probably want to use JDK1.4 and the Java Plug-in. BUT that means your in the Applet security sandbox which can be an annoying limitation so before you commit yourself to it make sure its really a requirement.

#8

My answer: use both :stuck_out_tongue:

From recently launching some browser games, we had very disappointing figures for people installing Java 1.4. Only about 25% of our visitors managed to get to the game. Since we built a hybrid 1.1/1.4 version, that has rocketed to over 75% of visitors being able to see the game.

This does depend on the audience though, but the vast majority of web users just have the default 1.1 VM installed. Its sad, they all install the new Flash, but don’t like doing it with Java.

We learnt the hard way, & lost around 500 customers in 3 days.

  • Dom
#9

[bump!]

Okay, I know I just popped into this discussion way late - but this brings up the question that I really need the answer to:

[quote]My answer: use both :stuck_out_tongue:

From recently launching some browser games, we had very disappointing figures for people installing Java 1.4. Only about 25% of our visitors managed to get to the game. Since we built a hybrid 1.1/1.4 version, that has rocketed to over 75% of visitors being able to see the game.
[/quote]
Yeah, that’s exactly what I want to do - a 1.4 / 1.1 hybrid. The only problem is: How? ???

I’ve taken my original 1.4 code and made sure that I’m only using 1.1 API method calls, or else I have the newer calls in a “try - catch” block with an alternate version for 1.1. It compiles and runs great under 1.4, but MSIE using the infamous MS 1.1.4 VM “can’t find” the main class.

I gather there’s some compiler switch I missing - or is there more to it than that? (I’m using NetBeans 3.6 IDE, BTW) Either way, I have no idea what to try next.

Thanks in advance for any help!! :smiley:

#10

I haven’t tried mixing 1.1 and 1.4 code, but “-target 1.1” when you compile should ensure the applet can run under the Microsoft JVM.

Hope this helps.

#11

[quote]The only problem is: How?
[/quote]
You need to get the best of both worlds.
We had a base ‘CSGraphics’ class that when initialised creates either a ‘CSGraphics11’ or a ‘CSGraphics14’. the 11 used software rendering, the 14 used buffered images and simply forwarded the draw calls onto the normal Graphics object. The Sprite was wrapped up in the same way as a ‘CSSprite’, as was BufferStrategy and the Audio - although the audio is a bit buggy at the moment - 1.1 audio sucks bad! >:(

Here is the code to detect the current VM version:


// parse version, if less than 1.4 then use 1.1 compatibility
byte version[] = javaVersion.getBytes();
try
{
      if (version[0] >= '1')
      {
            if (version[1]=='.')
            {
                  if (version[2]>='4')
                        javaVersion1 = false;
            }
      }
}
catch (java.lang.ArrayIndexOutOfBoundsException e)
{
}

In the Java spec, it says that Java can only reference classes when the code is executed - so JIT compilers shouldn’t (& don’t) complain about 1.4 code being in your app unless it is executed.

Here is the code from our old CSGraphics class:


public abstract class CSGraphics
{
      static CSGraphics alloc(int w, int h)
      {
            if (CSInfo.javaVersion1)
                  return new CSGraphics11(w, h);
            else
                  return new CSGraphics14(w, h);
      }

      abstract boolean drawImage(CSSprite s, int x, int y, ImageObserver observer);

                // etc...

By abstracting all the business bits into two seperate classes and using a factory class to create the right one at runtime, ensures that your code will work on 1.1 and 1.4 and you don’t take any speed penalty.

Hope this helps :slight_smile:

  • Dom

PS: We have since removed this and just use the software rendering now as we do more interesting things. Take a look at Traffic Jammer JX (Blatant plug: http://www.crystalsquid.com/games/traffic_jx.php)- it is rendered with a static z-buffer and stored background frame. The only thing rendered each frame are the cars and the particles, everything else is a single arraycopy from an image generated at the start of each level. You can’t do that with a BufferedImage ;D

[edit] And you do need the -target 1.1 too :wink:

#12

Thanks a million!! Those tips did the trick! My game now runs in both 1.4.2 and MS 1.1!! :smiley:

Although I did hit a couple of other “gotchas”, and I want to share them so that others don’t have to struggle with the same things I did:

  1. The current JDK API (1.4.2) documentation tells you in which version a new method or class was added to the API - but don’t trust it! It missed at least one case: apparently the “getX()”, “getY()”, “getHeight()” and “getWidth()” methods were not part of the “Rectangle” class in JDK 1.1 so this killed the execution under the Microsoft VM. If you’re going to develop for 1.1, I highly recommend you download the 1.1 JDK API docs from Sun and use that to make sure the methods you call are supported.

  2. Sound support - It doesn’t seem to say anywhere, but 1.1 only supports “.au” files that use u-law, 8000 Hz., mono data files. I used GoldWave v5.06 to convert my “.wav” files.

BTW - My game is called “JobHunter”, and when I get a little further I’ll put it up for feedback. It’s based on the skills I learned over the past 3 years unsuccessfully trying to find a job here in the Silicon Valley… >:(

#13

Hi all,
I’m new at this forum. This post is about Walkal’s previous post:
" I haven’t tried mixing 1.1 and 1.4 code, but “-target 1.1” when you compile should ensure the applet can run under the Microsoft JVM. "
I’m assuming you are suggesting compiling the source code with SDK 1.1. If that is the case, where can I go to find a copy of SDK 1.1. (I have looked almost everywhere and could not find it).
Thanks in advance.
Erica

#14

Holy Cow! This thread has been necroed 2x!

-target 1.1 doesn’t require the 1.1 sdk. The 1.1 vm’s don’t recognize class files compiled with 1.4+. Using -target 1.1 makes the class files ‘visible’ to the older vms like MS.

Simply ensure you don’t use any non-1.1 classes/features and it’ll run fine.