Archived

This topic is now archived and is closed to further replies.

Cedric

[java] Developping for 1.1.x

Recommended Posts

I''m sure that this has already been answered, but... you know. Anyway, I want to do an applet for the largest common denominator, so it must be 1.1.x-friendly. 1. If I use the Java 1.4.0 SDK, and never use any class designed for Java 1.2 and up, is it safe? 2. How do I know the version of Java that supports a given class? Sometimes, in the SDK, there is a small note in the description of a function "Since 1.2", but I''ve never seen such note for a whole class. 3. If I do have to download the old SDK, could anyone tell me which one it is exactly? Sun has a pretty big list of 1.1.x SDK. 4. While I''m at it, are there two parallel version numbers for Java? One for the actual Java technology, and one for the SDK? Could it be that I''m working on the Java 2 platform, with the 1.4.0 SDK? This has always been confusing to me. Thank you, Cédric

Share this post


Link to post
Share on other sites
1. jdk 1.4 compiler will give you "deprecated api" warnings, but I''ve had no problems. Its not guranteed though obviously; although I don''t see them abandoning the Applet class anytime soon.

2. the 144 megabytes (unzipped) of documentation (should you choose to download it) always tell you when a given class was instituted.

3. I''d say you''d be perfectly safe with anything 1.3 and lower.

4. don''t know.

Share this post


Link to post
Share on other sites
1. You may want to checkout the documentation on the 1.4.x SDK tools. Specifically, look at the Cross-Compilation Options for javac: http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html

In 1.4.x, they try to provide a mechanism for doing what you are attempting. If you have to use earlier versions of the JDK (e.g., 1.2.2 or 1.3.x), then Sun''s stance has been that it "should work," but they did not formally test all the various permutations of JDK''s and compiled classes. So do so at your own risk.

2. Add the -deprecation option to your compiler command line.

3. To an extent, this depends on your platform. However, if you''re just on a Solaris box or Windows machine, go with the latest point release of whichever JDK you need (i.e., 1.1.x, 1.2.x, 1.3.x, 1.4.x, where x is the highest available). Just don''t get anything marked as a beta or candidate release as those are versions that are still in testing and such. For Linux, you may consider the latest offerings by Blackdown as well. For embedded systems like VxWorks, just be afraid. Be very afraid.

4. The simple answer is that Java 1 refers to JDK 1.0.x and JDK 1.1.x. When the 1.2.x family of JDKs were released, they included a fairly significant overhaul to how some packages worked along with the formal inclusion of other packages such as Swing. Yes, Swing was available for JDK 1.1.x, but it was offered as a separate jar, an add-on library of sorts. At the time of 1.2.x, they adopted a number of new naming conventions. The new versions of Java made reference to the Java Foundation Classes and Java 2 technology. So in Sun''s world, 1.2 = 2, 1.3 = 2, etc. Just chalk it up to marketting and move on. Also, they started calling things Software Development Kits (SDK) instead of Java Development Kits (JDK).

My guess is that it was part of Sun''s attempts to gain more respect for the language as there were a lot of "Can Java Handle Real Software" debates going on at that time. That''s just speculation on my part though.

Your Friendly Neighborhood Java Coder,
Lawerence

Share this post


Link to post
Share on other sites
The javac compiler has a -target option that you can use to specify your target JDK when you want to use earlier versions than that of the JDK of your compiler.

Share this post


Link to post
Share on other sites
quote:
Original post by HenryApe
The javac compiler has a -target option that you can use to specify your target JDK when you want to use earlier versions than that of the JDK of your compiler.

Ahhh... Nice. So, if I use the -target option, I am 99% guaranteed that my applet will run on a 1.1 JVM?

Cédric

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Nope, you can use any classes at all and using target will not tell you anything about it. However, if you don''t use target, the bytecode will be in a format that older JREs cannot read at all, so it is necessary if you intend to run it on one.

Best answer: have your users download a new JRE if they need it, you can automatically detect what they have available with a script, if it doesn''t have whatever features you want you can give them a message and then send them to the "Get Java" page. This happens all the time with Flash (and any other plugin, for that matter).
I think the best analogy came from someone in these forums: people don''t code exclusively for DirectX 3 just because they know it''ll already be installed; why limit yourself to 3-4 year old technology when it''s so easy to have people download an update and it''s something they do all the time with other stuff?

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
why limit yourself to 3-4 year old technology when it''s so easy to have people download an update and it''s something they do all the time with other stuff?

Because it defeats the purpose of doing an applet: that anyone can start playing it within 1 minute. The JVM is a pretty big download on a 56k modem, and it''s bound to put off some people.

Last year, I was looking for a summer job, and I sent my demo along with my resume. It required DirectX 8, and I am doubtful that many people got it working. That''s another thing that I don''t want to happen again.

Thanks for your answer,

Cédric

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Best answer: have your users download a new JRE if they need it, you can automatically detect what they have available with a script, if it doesn''t have whatever features you want you can give them a message and then send them to the "Get Java" page. This happens all the time with Flash (and any other plugin, for that matter).



That''s an easy way to make poor design a habit. The main reason to go with bleeding edge technology is to make first use of features that were not previously available. You use them when your application requirements specifically call for those features. If there''s no pressing need for bleeding edge technology, it''s much safer to go with established technology and the stuff most likely to be available to your target audience. This would apply to software development in general, be it games, corporate applications, etc. Meet your requirements and maximize the size of your target audience. If your requirements call for the latest and greatest, fine. If not, there''s no reason to hamstring your work.

Inconveniencing users is never a good design. Users are fickle and have short attention spans. This is true of application users as well as web surfers. You have precious few seconds to win their interest and support. For years, decent web design dictated that your pages load in 7 to 11 seconds (depending on connection type). If your page had not loaded by then, your user would likely move on. There''s enough competition out there that someone else has done it cleaner and faster. If you are looking for applications to add to your resume, the same rules apply. Unless you are targetting a specific feature known to be in demand with that employer, giving them applications that require system maintenance will land your resume on the bottom of the pile or in the trash bin.

Never make a user account for your lazy programming. Stick with your plan and good luck with the project Cédric.

Lawerence

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The Java 2 Platform is not "bleeding edge" in any way. Swing is going to be such a boon for so many programs that it''s silly not to take advantage of it. If you''re using Java applets for some trivial purpose like navigation on a web page or whatever where the 7-10 second rule applies, you should probably be using another technology anyway (or you''re just writing some kind of button effect, and not posting on a gamedev forum)

Yeah maybe if you''re writing Pong3000/MahJohng3000 you might get someone who is on the fence to play your game once instead of leaving if they happen to not have a J2SE plugin installed... but there are thousands, maybe tens or hundreds of thousands of those applets out there written for 1.1. If you are going to stand out, you need a feature-rich libarary that you will only get in 1.1 if you have your own framework. hotmetalwizard, you mention competition, and if you are going to compete with all of those other Java game applets out there, you need to step up to the plate and get past the year 1996.

(note to self: register for this forum. this anonymous posting feature is making me lazy)

Share this post


Link to post
Share on other sites
Hmm, I had not intended it to sound as though Java 2 was bleeding edge. Certainly, it is not. Rather, I was commenting on your (?) statement of requiring users to download the latest stuff or every plugin under the sun. As I said, go with your requirements and target audience. If your requirements are to show off the latest and greatest, then go for it. If your audience/consumer/etc. doesn''t mind jumping through a few hoops to see the best, new stuff, that''s great. Give it to them. Many game companies make a decent living out of the bleeding edge. That''s their goal. Others choose to stay with stuff that''s a bit more tested and a bit more known. It lowers certain types of risk and that''s part of their goal. Both can work.

My point is that you shouldn''t pick a technology simply because the point release is a big number. Pick it because your goal is to wow your customers. Pick it because you want to be an early adopter and cater to early adopters. Pick it because your release is a year from now and today''s bleeding edge will have saturated the market by then. More often than not, new is not better. New is often unstable and incompatible, as Cédric already found.

Share this post


Link to post
Share on other sites
(Hey! I registered!)

I agree 100% with what you''re saying about using the right tools for the right job. The current version of Star Dart, my hobby project, is built for 1.1 because that''s all it needs. The next release I will be switching to 1.4 because I intend to take advantage of it''s features.

You mention stability, and there are very stable, widely tested and run releases of 1.2 and 1.3. It''s not about having the biggest number -- I know that 1.4 isn''t ready for wide use right now, but by the time I learn enough to finish what I''m working on I think it will be just fine.

The troubling thing that I don''t think I''ve done a good job of pointing out here is the fact that, more than in other languages, people who are coding "for the common denominator" are using particularly old standards. I tried to make a point about DirectX -- both DirectX 3.0 and Java 1.1 came out in the same year, but people who are developing for the features available on the majority of PCs have moved to more recent versions of DirectX, while a pervasive trend of only using Java 1.1 has a paralyzing grip on Java developers.

The initial post did not sound like someone was trying to decide what sort of tools they would need to complete their job and then selecting the Java platform based on the amount of additional tools they would have to roll in order to get it to work on the most systems, which is how it should be I feel. I think that if you are writing a game where you need only a couple of things that you can''t get with 1.1, then it is probably going to be appropriate to just write your own and not worry about it. Otherwise, I think some deep thought about what you''re going to be competing with (and, if you''re using technology that has been available for *six years*, this encompases a LOT of games) and take a look at one of the J2SE releases.

Share this post


Link to post
Share on other sites
quote:
The troubling thing that I don''t think I''ve done a good job of pointing out here is the fact that, more than in other languages, people who are coding "for the common denominator" are using particularly old standards. I tried to make a point about DirectX -- both DirectX 3.0 and Java 1.1 came out in the same year, but people who are developing for the features available on the majority of PCs have moved to more recent versions of DirectX, while a pervasive trend of only using Java 1.1 has a paralyzing grip on Java developers.

You probably know more than I do, but the big difference between DX 3 and Java 1.1 is that DirectX 4 (or 5?) was bundled with Windows 95, and every subsequent version of Windows had an up-to-date version of DirectX, whereas Windows XP only supports Java 1.1 out of the box.
quote:
Original post by markuskidd
The initial post did not sound like someone was trying to decide what sort of tools they would need to complete their job and then selecting the Java platform based on the amount of additional tools they would have to roll in order to get it to work on the most systems, which is how it should be I feel.

I chose to learn Java specifically because the DirectX approach didn''t meet my needs. I began learning Java a month ago, so it''s not like I''m "stuck in the past".
quote:
I think that if you are writing a game where you need only a couple of things that you can''t get with 1.1, then it is probably going to be appropriate to just write your own and not worry about it. Otherwise, I think some deep thought about what you''re going to be competing with (and, if you''re using technology that has been available for *six years*, this encompases a LOT of games) and take a look at one of the J2SE releases.

I want to do an applet to compete with the likes of Popcaps. AFAIK, Popcaps uses Java 1.1, so if they don''t think that they have enough appeal to force users to download a recent JVM for their latest game, then surely, I won''t have that appeal either.

Cédric

Share this post


Link to post
Share on other sites
It sounds like 1.1 probably *is* the tool for you :D I hope you don't take my comments as a personal affront, especially since no one knew your requirements. As I mentioned, my project has used only Java 1.1 up until very recently. I'm really only a Java newbie myself, so I've not got much more of a background than you do. The popcaps thing may be more of an appropriate subject for my comments though; I think that has a lot to do with the 'Java mentality' (as opposed to the 'DirectX mentality', I suppose) than their appeal.

[edited by - markuskidd on November 10, 2002 11:07:58 PM]

Share this post


Link to post
Share on other sites
Hey,

what about the linux users! I personally do not care if some lazy user just bought windows XP and was unable to download a Java2 compatible browser, that MSIE 6.0 (thanx to Microsoft) is NOT!

If you say "I'll gladly use JDK 1.1.x" do you actually know what that does mean for you - the programmer ???

You can forget (compared to J2SDK 1.4.0) about using:

  • Collections
  • ImageIO
  • Java2D
  • java.text
  • regular expressions
  • XML
  • and a whole (enormous ) lot of others

And using that kind of TOTALLY outdated libraries you're gonna exceed ANY acceptable limits for the completion of your project. That can only lead to:

  • enormous costs - if you're a pro (time = money)
  • enormous demotivation - if you're coding for fun


So if your target audience is THAT LAZY (the can not even press 'ok' to download & install a java plug-in), they won't be able to cover your costs, or give you the feedback you need when working for fun ... but that's just my opinion of course.

P.S.: Use pre-Java2 JDKs only if your boss insists

and have fun ...

Petr Stedry

[edited by - Petr Stedry on November 11, 2002 8:11:28 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by markuskidd
It sounds like 1.1 probably *is* the tool for you :D I hope you don't take my comments as a personal affront

Certainly not.
quote:
The popcaps thing may be more of an appropriate subject for my comments though; I think that has a lot to do with the 'Java mentality' (as opposed to the 'DirectX mentality', I suppose) than their appeal.

quote:
Original post by Petr
So if your target audience is THAT LAZY

The Java plug-in is 5 megs . That's a lot for a 56K user. Furthermore, a big chunk of the applet market are people who play at work. They might not be too keen on installing anything on their computer, for fear of being caught.

Thanks for your list of "stuff that isn't supported in 1.1". I didn't know that I would lose collections, but I was intending to rewrite my collections anyway to avoid the casts (if profiling shows it to be a bottle-neck, of course).

If my code is well-structured, I think that I can write it using the latest Java features, and then convert it back to Java 1.1. This has two advantages:
- Development will be faster
- I can provide a "fast" version for the users willing to download the plug-in

I only have to watch out for unnecessary coupling between the sub-systems, or else, converting back to 1.1 will be a nightmare.

Cédric

[edited by - cedricl on November 11, 2002 4:26:25 PM]

Share this post


Link to post
Share on other sites
Well,

I didn't say, that writing java 1.1 compliant applets is impossible.
Heck even I made some java 1.1 applets. This one's called "Joseph Mason" and it's a logical game. Your goal is simple: fill the most of the rectangular area with bricks, Joseph moves using cursor keys.

But the thing is, that you can go without collections if you do a simple game, because you'll probably need just some sort of list that keeps your object together (you can even use a vector, of course). That's pretty easy to code, but in case of a larger project, well you'll end up writing libraries instead of the desired functionallity.

If you intend to use just custom graphics (no AWT or Swing) you will surely miss classes like BufferedImage (you lose java2D, remember?) and that's not good, because you'll have to provide buffering by yourself.

BTW if the people that should play your applet work at a place like I do, the won't be able to install the JRE, but that's not the reason they're not able to run any applet at all. The firewall I'm behind blocks almost ANY communication - not even my simple Joseph Mason applet is not allowed to open an HTTP connection!

Here's what the plug-in (v1.4.1_01) says:

load: class JosephMason not found.
java.lang.ClassNotFoundException: JosephMason
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:153)
at sun.plugin.security.PluginClassLoader.findClass(PluginClassLoader.java:168)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:506)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:566)
at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1775)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:495)
at sun.applet.AppletPanel.run(AppletPanel.java:292)
at java.lang.Thread.run(Thread.java:536)

Caused by: java.io.IOException: open HTTP connection failed.
at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:252)
at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:42)
at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:143)
at java.security.AccessController.doPrivileged(Native Method)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:140)
... 10 more

So you're free using java 1.1, but those issues apply even to YOU. And the companies will surely try to protect themselves, like the one I'm at now (I eventually acquired local administrative rights to install things, but I will be never able to influence the firewall settings).

that's all folks, have fun using JAVA ( any version )

Petr Stedry

[edited by - Petr Stedry on November 12, 2002 3:14:24 AM]

Share this post


Link to post
Share on other sites
Thanks for your post.
quote:
Original post by Petr Stedry
If you intend to use just custom graphics (no AWT or Swing) you will surely miss classes like BufferedImage (you lose java2D, remember?) and that''s not good, because you''ll have to provide buffering by yourself.

What do you mean by "custom graphics"? Is the class Graphics considered to be a part of AWT?

Cédric

Share this post


Link to post
Share on other sites
Well, I just got a whole boatload of experience with writing an applet for the lowest common denominator; My ludum dare entry is written to be 1.1 compliant and it runs so wildly different on different vms its pretty amazing. On a win 98 with the ms vm it gets anywhere from 5-15 fps and on Linux with conquerer (not sure which vm) it runs at ~20 fps. With JDK 1.4 (which I developed on) it runs at 50 fps. The worst I''ve seen is ~3-5 fps, the particles weren''t drawn to the applet and massive numbers of frames were skipped.

I did the compo in java to get more exposure for my entry and the result is it gets less exposure than the other entries. This has been very discouraging. I doubt I''ll continue to develope games with java.

Share this post


Link to post
Share on other sites
It sounds like you got less exposure because you developed to the lowest common denominator in a competiton to see how much "wow" you can code in a limited amount of time. Were you competing against people who were working with DirectX 3.0? If not, then you started out at a disadvantage by limiting yourself to old technology.

Share this post


Link to post
Share on other sites
Hi,

Cedricl: I meant any gui-like features (ingame menus, dialog boxes, text areas and similar) that aren't done using AWT or Swing. And even if graphics is a part of the java.awt package, when mentioning AWT, then I have other things in mind - the GUI components, the event model and the like.

Petr Stedry

[edited by - Petr Stedry on November 13, 2002 4:02:42 AM]

Share this post


Link to post
Share on other sites