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

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.

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

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.

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

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?

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

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

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)

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.