Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34342 > unrolled thread

making jars clickable

Back to article view | Back to comp.lang.java.programmer

Contents

  making jars clickable Roedy Green <see_website@mindprod.com.invalid> - 2016-05-18 12:48 -0700
    Re: making jars clickable Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-05-19 08:41 +0200
      Re: making jars clickable Roedy Green <see_website@mindprod.com.invalid> - 2016-05-20 13:04 -0700
    Re: making jars clickable Andreas Leitgeb <avl@logic.at> - 2016-05-19 09:28 +0000
      Re: making jars clickable Roedy Green <see_website@mindprod.com.invalid> - 2016-05-20 13:06 -0700
        Re: making jars clickable Eric Douglas <e.d.programmer@gmail.com> - 2016-05-20 13:13 -0700

#34342 — making jars clickable

If you have W10-32 and W10-64, you can reinstall the JRE or JDK which
will set up a link from jars to that jvm. Then use regedit.exe to find
the jar link to javaw.exe in the registry, and modify it to java.exe.
The link looks like this: Computer : HKEY_CLASSES_ROOT : jarfile :
shell : open : command : "C:\Program
Files\java\jre1.8.0_92\bin\javaw.exe" -jar "%1" %*. Then run under
administrator assoc .jar=jarfile Though in theory this should work, I
cannot get it to.

1. does this work for other people?
2. why should it fail?
3. have you a method that works?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Incorrect documentation is often worse than no documentation.
~ Bertrand Meyer (born:1950 age 65)

[toc] | [next] | [standalone]

#34344

On 18.05.16 21.48, Roedy Green wrote:
> If you have W10-32 and W10-64, you can reinstall the JRE or JDK which
> will set up a link from jars to that jvm. Then use regedit.exe to find
> the jar link to javaw.exe in the registry, and modify it to java.exe.
> The link looks like this: Computer : HKEY_CLASSES_ROOT : jarfile :
> shell : open : command : "C:\Program
> Files\java\jre1.8.0_92\bin\javaw.exe" -jar "%1" %*. Then run under
> administrator assoc .jar=jarfile Though in theory this should work, I
> cannot get it to.
>
> 1. does this work for other people?

Probably yes.

> 2. why should it fail?

A jar file could be one of:
1. Java GUI executable
2. Java command line executable
3. Java library including plugin, EJB etc.
4. Java browser applet

Your solution only works only for case #1.
In case #2 you will not get any reasonable output unless you invoke 
java.exe instead of javaw.exe, i.e. open a terminal.
In case #3 you will usually get a Java exception.
I never tested case #4 but it probably won't work either.

Furthermore many Java Application need a properly set classpath to find 
its referenced Java libraries on your disk. They may fail too, since the 
classpath in the manifest cannot reflect a path on the local disk.
This especially applies to third party libraries like database drivers 
or JMS providers.

And last but not least some Java applications need a specific Java 
version to run. While most things work when you use a never Java some 
others fail. E.g. a SAP JCO 2.x client may trigger a dump in the RFC 
layer of the SAP server if run with a newer Java because the XML 
serialization has changed a little in the Java Runtime. Other Java 
applications might only work with 32 bit Java, even on 64 bit hardware.

> 3. have you a method that works?

A wrapper executable (or Java program) could check whether the target 
jar file is case #1, #2, #3 or #4. Unfortunately it is not that easy. 
I.e. sometimes a class library file (#3) may have a main class too, 
although it is not intended to be invoked in general. It might contain 
test code for example.
And #1 vs. #2 is also not straight forward. You might check for 
references to swing libraries to distinguish. But sometimes Java 
programs are only partially GUI driven.
No idea for case #4 because I never used it.
There is finally no work around for a required environment setup or a 
specific Java version. Normally it is up to an installer to prepare this 
appropriately.

So at the end whatever you do some files will work as expected others 
will fail. It still could be helpful to you if you often use small Java 
programs delivered as raw jar file (typically open source or self 
created). But for a general solution there are too many pitfalls.

I usually create an individual link with the appropriate command line 
parameters and Java executable for each jar file I want to start 
directly. It could use the JAVA_HOME environment if it should 
automatically refer to the most recent runtime.


Marcel

[toc] | [prev] | [next] | [standalone]

#34354

On Thu, 19 May 2016 08:41:22 +0200, Marcel Mueller
<news.5.maazl@spamgourmet.org> wrote, quoted or indirectly quoted
someone who said :

>A jar file could be one of:
>1. Java GUI executable
>2. Java command line executable
>3. Java library including plugin, EJB etc.
>4. Java browser applet

these are command line and GUI jars, all of which worked fine
as 
xxx.jar in Windows 7. Now they have stopped working in Windows 10
They still work as

java -jar xxx.jar

Logically javaw.exe -jar xxx.jar should give identical results to
xxx.jar
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Incorrect documentation is often worse than no documentation.
~ Bertrand Meyer (born:1950 age 65)

[toc] | [prev] | [next] | [standalone]

#34345

Roedy Green <see_website@mindprod.com.invalid> wrote:
> If you have W10-32 and W10-64, you can reinstall the JRE or JDK which
> will set up a link from jars to that jvm. Then use regedit.exe to find
> the jar link to javaw.exe in the registry, and modify it to java.exe.

It is not entirely clear to me whether you really want to change
some original javaw.exe towards java.exe (which you seem to have 
written, but makes no sense), or the other way round, from some
original java.exe towards javaw.exe (which would make me wonder
why it was wrong "originally").

For some legacy reasons, windows doesn't support programs that inherit
stdin,stdout,stderr from where they're started from AND still can open
graphical windows as well. (except by spawning a subprocess, perhaps.)
It's just two separate worlds.

Therefore, there are two versions of java program for windows, java.exe
and javaw.exe one of which supports console mode with inherited stdin,
stdout,stderr, whereas the other one allows programs to open windows.

The defaut binding for .jar files is usually used when clicking icons from
file manager, but also possibly by calling "start myprog.jar" from cmd.exe
but even then it is expected to spawn a GUI process and let cmd.exe return
to accept more commands.

[toc] | [prev] | [next] | [standalone]

#34355

On Thu, 19 May 2016 09:28:05 -0000 (UTC), Andreas Leitgeb
<avl@logic.at> wrote, quoted or indirectly quoted someone who said :

>It is not entirely clear to me whether you really want to change
>some original javaw.exe towards java.exe 

Why would you want to throw the output away from a program?  Javaw.exe
makes no sense  most of the time. So I want to run jars with Java.exe
not javaw.exe.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Incorrect documentation is often worse than no documentation.
~ Bertrand Meyer (born:1950 age 65)

[toc] | [prev] | [next] | [standalone]

#34356

On Friday, May 20, 2016 at 4:06:11 PM UTC-4, Roedy Green wrote:
> Why would you want to throw the output away from a program?  Javaw.exe
> makes no sense  most of the time. So I want to run jars with Java.exe
> not javaw.exe.

Because in a Windows program, the output sent to System.out could be just log messages for developers. This goes to Java Console.  We run our in house programs in webstart.  Java Console is normally hidden for end users.

javaw.exe is the GUI default, what you should want if you double click a jar.
java.exe is the old method, if you want the user to interact in a command window.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web