> Personally, I think this suX0rs. I don't know much about the state of
> Free JVMs on Windows, but I'm pretty damn sure that none of them are
> going to support JDK 1.3 stuff.
They don't need to.
> Freenet is an Open Source Java project. We should support people who
> want to use Open Source Java systems. Mandating a particular
> proprietary JVM is lame.
It is. We're working on it but currently the only JVM that we _know_ (and
I mean _really know_) works under Windows is the Sun JRE 1.3.1 . Name any
other and we'll give you a list of the problems we've encountered trying to
use it / get it to work.
> If we can't manage to add two or three more strings ("kaffe.exe",
> "japhar.exe", "jre.exe" etc.) to the JVM search facility in the
> Windows install, we suck.
Oh, if only it were that simple.
jre.exe is INCOMPATIBLE with java.exe
java.exe uses the 'CLASSPATH' environment variable
jre.exe REQUIRES that we use "-cp" and/or "-classpath" on the command line.
jre.exe does NOT use (or, if it does, does not use RELIABLY) the 'CLASSPATH'
environment variable
"-cp" and "-classpath" are compatible with java.exe but incompatible with
jview.exe, which requires instead that we use "/cp" and/or "/classpath"
...
you see the can of worms?
Like I said, we're working on it. But to build a list of different jre
executable files AND an internal structure that describes how each one
should be run and its arguments ... THAT sucks.
If they were all compatible, it wouldn't be a problem.
And there's other issues too. java.exe (Sun JRE 1.3.1), for example, can
create an ugly black console window. On windows 2000 we can close this
window programatically. On Win9X and Win ME we cannot. javaw.exe is the
correct Win32 version of the JRE. But what is the situation with kaffe.exe?
Or japhar.exe? Do they create console windows? Can they be shut
programmatically? Do they run in the Windows subsystem? If so, do they
automatically close down when we send child windows the
WM_SYSCOMMAND[SC_CLOSE] message?
I hear that Sun JRE 1.1.xxx does not include the Swing libraries - we (or
the user more likely) would need to install these separately. Another
potential installation to perform. So much for user-friendliness or
intuiutive-installation-process.
I mean, gimme some time and I'll literally try all of the JREs I can get my
hands on. But I can't do all the testing myself. I've been on the project,
what, a month and a half? Most of the current support problems are due to
installation process problems (now that I've fixed all of the freenet.exe
bugs and rewritten the old assembler stuff into maintainable C) and it is
these that I am currently concerned about. By limiting to one JRE
**currently** we can concentrate on other issues, while users get on with
**using** freenet, and we get on with evaluating alternative JREs.
Jeeez.
Anyways, it's easy enough (for users, you, me, everybody) to do testing with
an alternative JRE for Windows once Freenet is installed. Just substitute
the path to your jre in the keys
Javaw=
Javaexec=
in the "Flaunch.ini" file. Preferably, use Javaw= to specify a proper
windows subsystem JRE (no 'dos' windows) and javaexec= to specify a 'dos' or
Win32 console subsystem JRE.
Then exit freenet (if it was already running) and reload it. This forces it
to reload flaunch.ini and from this point it will use your JRE instead of
the Sun JRE 1.3.1 thing.
Do some testing, try various combinations of EVERYTHING, then get back to
me.
We have a release test lying around somewhere - a bullet-pointed checklist
for evaluation of Windows freenet releases. I don't see why we couldn't
reuse this to evaluate alternative JREs, assuming the existence of a fully
working freenet as a base point.
Dave
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
