"plord" == Phillip Lord <[EMAIL PROTECTED]> writes:
>>>>> "rchase" == rchase <[EMAIL PROTECTED]> writes:
rchase> I haven't had to work with both JDKs yet but I may have to
rchase> soon. I was thinking that I would be able to switch easily
rchase> between JDK 1.1.x and JDK 1.2 by defining all the necessary
rchase> settings and saving them in a project file. Wouldn't this
rchase> provide an easy way to switch JDKs? Of course, that's
rchase> assuming that you're not using both JDKs for the same
rchase> project. (Would anyone actually want to do that?)
plord> An applet project.
plord>
plord> What ever people say if you want to write code which
plord> works on all browsers you still write in 1.0 code (let alone 1.1).
plord> However there is no reason to write the server side in 1.0. Hence my
plord> first project was 1.1/1.0. Some classes were used both sides, some
plord> server only, some client only. The packages didnt work out as either
plord> 1.1, or 1.0 when I wrote this, hence I didnt find "projects" that
plord> helpful. What I ended up doing was writing a 1.1 prj.el, and a 1.0
plord> prj.el and then loading them from a menu which I gave the rather
twee
plord> name of "JDE+". This way I switched JDK when I wanted rather then
when
plord> JDE noted a changed project.
Never thought of this. I guess I figure if I was doing a project
where I wanted to use one
JDK for the server side and another for the client side, I'd have two
different project files, but not everyone will want to work that way. And
of course that doesn't address the issue of classes used in both sides.
rchase> With regards to your hopes that JDK 1.1.x will just go away,
rchase> well, I'm a little skeptical. Many Java developers (such as
rchase> myself) live in a world where things like multi-platform
rchase> browser support is a prime concern, and I'm not convinced
rchase> that multi-platform browser support for JDK 1.2 is that
rchase> close.
plord> This is fairly irrelevant though. Developers have a choice
plord> over what tools they use. Most people coding java will have a 1.2
JDK
plord> on their machine. Theres nothing to stop you using 1.2 with the
plord> changed command line tools, to compile 1.1, or 1.0 code. In fact all
plord> you need to do to "switch" JDK's is alter the (boot)classpath to
point
plord> to the older classes. At least this is more or less what I used to
do
plord> with 1.0/1.1. I image it will still work with 1.1/1.2.
You're right, I could compile all my code with the JDK 1.2, and just
use the command line options to specify my target JVM and the classpath to
use. But I'm not confident enough that that will actually work to ship
code compiled that way. When we moved from swing1.0.3 to swing1.1, we had
quite a few problems with code that would no longer compile against
swing1.1 classes that did compile against swing1.0.3 changes. Imagine if I
had compiled those classes from the beginning with JDK 1.2 and then shipped
it to customers running in an (imaginary) browser with Swing support. (I
say imaginary because there is not such thing yet...). Sure it might work,
but I have my doubts. Who knows what else the folks at Java had to break
(wrt backwards compatability) to make JDK 1.2 work?
Ryan Chase
DB2 UDB Administration Tools
[EMAIL PROTECTED], (416) 448 4035
IBM Toronto Lab
