Windows integration of the JRE and JDK

[Stefan Ram]

What could be reasons that Sun did never implement
the following behaviour upon installation of the JDK
(or possibly, the JRE) on Windows, which after all
is an important plattform. (Similar things might be
possible under other operating systems, too.)

The following behaviors seem so obvious to me:

- The directory with the commands »java« and
»javac« is added to the Windows »path«.

- When a *.class file is »opened« in the explorer
and this file has a static main method it is
opened with the java command (when it extends
Applet/JApplet it could be opend with appletviewer
and a default HTML wrapper file; when it contains
a reference to Swing or AWT, it is opened with javaw.)
When it needs other classes, they are compiled
if this is necessary.

- When a *.java file is »opened« in the explorer
it is compiled to a *.class file, which is kept
in memory and then treated as described above.

- (if possible)When »example ...« is typed on the
command line and a file »example.class ...« exists
but no file »example« exists then this treated as
if »java example ...« would have been typed
(I don't know if this is possible).

- All of the above options are indicated with a
checked checkmark in the installation program,
so that a user can deselect them, if he does not
want them.

 

[Arne Vajhøj]

What could be reasons that Sun did never implement
the following behaviour upon installation of the JDK
(or possibly, the JRE) on Windows, which after all
is an important plattform. (Similar things might be
possible under other operating systems, too.)

The following behaviors seem so obvious to me:

- The directory with the commands »java« and
»javac« is added to the Windows »path«.

JRE java.exe is copied to somewhere in PATH.

Putting JDK bin dir in PATH and setting JAVA_HOME could
make sense.

But then Java and Windows was never that integrated.

- When a *.class file is »opened« in the explorer
and this file has a static main method it is
opened with the java command (when it extends
Applet/JApplet it could be opend with appletviewer
and a default HTML wrapper file; when it contains
a reference to Swing or AWT, it is opened with javaw.)
When it needs other classes, they are compiled
if this is necessary.

Probably too little benefits. Most real world apps require
various classpaths to be defined.

- When a *.java file is »opened« in the explorer
it is compiled to a *.class file, which is kept
in memory and then treated as described above.

Nothing else does that on Windows. At least not something I know.

- (if possible)When »example ...« is typed on the
command line and a file »example.class ...« exists
but no file »example« exists then this treated as
if »java example ...« would have been typed
(I don't know if this is possible).

That may be very closely related to the explorer option.

- All of the above options are indicated with a
checked checkmark in the installation program,
so that a user can deselect them, if he does not
want them.

Except for the auto compile and run option then I would not
complain.

Arne

 

[markspace]

The following behaviors seem so obvious to me:

- The directory with the commands »java« and
»javac« is added to the Windows »path«.

Could be bad if you already have a PATH for Java set. Programmers can
deal with this, messing up the PATH of a normal user probably is not the
best idea.

- When a *.class file is »opened« in the explorer
and this file has a static main method it is
opened with the java command (when it extends
Applet/JApplet it could be opend with appletviewer
and a default HTML wrapper file; when it contains
a reference to Swing or AWT, it is opened with javaw.)
When it needs other classes, they are compiled
if this is necessary.

This works with Jar files on my system. I'm not sure extending it to
..class files is needed, but it should be possible to do. Note that to
test the interface type of a .class file you'll need a launcher, because
the neither java.exe nor java.exe -jar do this now.

- When a *.java file is »opened« in the explorer
it is compiled to a *.class file, which is kept
in memory and then treated as described above.

Pernicious. When I open a .java file, I want to edit the text. Get an IDE.

- (if possible)When »example ...« is typed on the
command line and a file »example.class ...« exists
but no file »example« exists then this treated as
if »java example ...« would have been typed
(I don't know if this is possible).

This works now for Jar files. Again I'm not sure of the value of doing
this for .class files too. It might create some confusion if the user
misspells a .class file name, or at least might provoke a lot of
unneeded searching amongst bazillions of loose .class files on the
average developer hard drive.

- All of the above options are indicated with a
checked checkmark in the installation program,
so that a user can deselect them, if he does not
want them.

Fair enough.

 

[Roedy Green]

The following behaviors seem so obvious to me:

- The directory with the commands »java« and
»javac« is added to the Windows »path«.

It would have to be optional because developers so often keep several
JDK and JRE versions installed.

The path is not needed for Browser use which is what most casual users
are doing. They are not clever enough to run anything from the
command line, much less Java's awkward java.exe -jar .

 

[Roedy Green]

- When a *.class file is »opened« in the explorer
and this file has a static main method it is
opened with the java command (when it extends
Applet/JApplet it could be opend with appletviewer
and a default HTML wrapper file; when it contains
a reference to Swing or AWT, it is opened with javaw.)
When it needs other classes, they are compiled
if this is necessary.

see http://mindprod.com/jgloss/extension.html

I could see this for a jar -- automatically setting up the .jar
extensions -- something I have asked for many times myself. It then
can work both in browsers and on the command line.

There is not as good an argument for a bare class file. It needs a
corresponding classpath, usually provided by the invoking .bat file.

 

[Roedy Green]

- When a *.java file is »opened« in the explorer
it is compiled to a *.class file, which is kept
in memory and then treated as described above.

That would require distributing Javac in the JRE. Users already balk
at the size of the JRE. You would also need some way to provide all
the options of Javac.exe and Java.exe. One way out of that would be
for Oracle to twist arms of computer manufacturers to preinstall
JDK/JRE and to have a transparent INCREMENTAL way of keeping them up
to date.

 

[Roedy Green]

- (if possible)When »example ...« is typed on the
command line and a file »example.class ...« exists
but no file »example« exists then this treated as
if »java example ...« would have been typed
(I don't know if this is possible).

I fooled around trying to make that work back in the 1990s. I
discovered that Windows extensions mechanism was not clever enough to
generate the needed effect. Unfortunately Microsoft feels about Java
the same way the Republicans feel about Obama. They are willing to do
anything to make it fail.

See http://mindprod.com/project/kicker.html

As my kludge.

 

[Roedy Green]

- All of the above options are indicated with a
checked checkmark in the installation program,
so that a user can deselect them, if he does not
want them.

There are two kinds of user
1. a developer who wants micro control over everything.
2. an end user who wants it all to work automagically without asking
any questions, preferably without even putting up a dialog box.

There probably be separate download links for both.

 

[Roedy Green]

The following behaviors seem so obvious to me:

- The directory with the commands »java« and
»javac« is added to the Windows »path«.

It would have to be optional because developers so often keep several
JDK and JRE versions installed.

The path is not needed for Browser use which is what most casual users
are doing. They are not clever enough to run anything from the
command line, much less Java's awkward java.exe -jar .

 

[Roedy Green]

- When a *.class file is »opened« in the explorer
and this file has a static main method it is
opened with the java command (when it extends
Applet/JApplet it could be opend with appletviewer
and a default HTML wrapper file; when it contains
a reference to Swing or AWT, it is opened with javaw.)
When it needs other classes, they are compiled
if this is necessary.

see http://mindprod.com/jgloss/extension.html

I could see this for a jar -- automatically setting up the .jar
extensions -- something I have asked for many times myself. It then
can work both in browsers and on the command line.

There is not as good an argument for a bare class file. It needs a
corresponding classpath, usually provided by the invoking .bat file.

 

[Roedy Green]

- (if possible)When »example ...« is typed on the
command line and a file »example.class ...« exists
but no file »example« exists then this treated as
if »java example ...« would have been typed
(I don't know if this is possible).

I fooled around trying to make that work back in the 1990s. I
discovered that Windows extensions mechanism was not clever enough to
generate the needed effect. Unfortunately Microsoft feels about Java
the same way the Republicans feel about Obama. They are willing to do
anything to make it fail.

See http://mindprod.com/project/kicker.html

As my kludge.

 

[Arne Vajhøj]

see http://mindprod.com/jgloss/extension.html

Why ?

It does not contain anything relevant for the thread.

I could see this for a jar -- automatically setting up the .jar
extensions -- something I have asked for many times myself. It then
can work both in browsers and on the command line.

It already does.

Arne

 

[Arne Vajhøj]

That would require distributing Javac in the JRE.

Not necessarily - the feature could require JDK.

Arne

 

[Lew]

Not necessarily - the feature could require JDK.

A good point made somewhere upthread, apologies for deliberate laziness in
researching by whom: The Java platform already provides packaging systems to
run under various JRE configurations (SE, EE, ...). Windows and Unices can
run JAR files as executables if configured similarly to how Excel spreadsheets
automatically bring up their commander. JARs have mechanisms to deliver all
needed dependencies, although setup is required in many scenarios. (For what
programs is that not true?) For complex installations there are installer
programs. Java even provides Java WebStart.

The segregation of the runtime from the JDK was deliberate to facilitate
widespread deployment. Java has enough handicaps in that area as it is, some
might say. It isn't all that outré really. Java certainly didn't invent the
notion of a separate runtime engine.

Often Java's delivery and deployment mechanisms are primitive and clunky.
OTOH they do run under unprivileged logins just about anywhere. "jar" and its
kin suffice to create self-contained packages. The packaging and deployment
primitives can in turn be packaged and deployed more elegantly, as they are
for some well-known Java products already. It ain't perfect, but the
compromises aren't egregious and can be ameliorated.