Although the current logic is good and works in almost
all cases, it would be nice to improve it. There are
several new considerations.
- We need to check for jdk<version> as well as
j2sdk<version>, since 1.5 will install there by default.
- The default location for jdk 1.4.2_04 installations
is %ProgramFiles%\Java\j2sdk1.4.2_04 rather than
C:\j2sdk1.4.2_04 (I'm pretty sure this holds for all
the recent versions of the jdk), so for users who
accept the default installation, DrJava will fail to
find their tools.jar. A good location to check, given
the default install directories, would be <Java
Home>\..\j2sdk<version>.
- The current logic only looks in C:\j2sdk<version>,
and will not check any other drives. I'm not sure if
there's a way to check for other fixed disks, but it
makes sense to check some more locations, including
%homedrive% and the drives from in %windir% and
%programfiles%.
I wrote these in order of importance, as I see it. I
think supporting jdk1.5 in this way is important (and
easy). We also shouldn't have trouble just because of
more recent installations of the jdk, and this is also
a pretty easy change. The last one is pretty
unimportant, as it only affects people who have a
non-default windows installation (or java
installation), and people who install their programs in
a non-default location are probably people who can
handle locating their own tools.jar. Still, it'd be
nice to make the ToolsJarClassLoader a little more
robust, so I figured I'd include it here.
Logged In: YES
user_id=1075744
If tools.jar is not found using the means we have right now,
we should check in a few default location -- I don't believe
checking in common locations like "C:\Program
Files\Java\jdk1.5.0\lib\tools.jar", etc. can hurt us.
If those guesses fail as well, we could display the "Locate
tools.jar" dialog we have right now, but extend it with a
"Scan" button. That "Scan" button brings up a dialog that
recursively scans the user's hard drive. It displays the
directory it is currently processing, just so the user gets
some sense of progress. The dialog also provides a "Cancel"
button that cancels scanning and takes the user back to the
"Locate tools.jar" dialog. We should probably save the
directory where cancel was pressed and continue our scan
from that directory if the user presses "Scan" again...
otherwise we end up unsuccessfully scanning the same part of
the directory tree multiple times.
Logged In: YES
user_id=666678
Originator: NO
The search locations have been extened in recent versions.