|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Mark Pierson Expert
Joined: 03 Aug 2003 Posts: 3017 Location: Connecticut, USA |
Posted: Sun Jan 31, 2021 8:40 pm Post subject: |
|
|
andyross wrote: | Are versions newer than 8 only for developers? If you go to Java.com, they only offer version 8 update 281 for download.
Also, does RMIR work with 64-bit Java yet under Windows? I remember there was in issue in the past, but don't know if it was fixed. |
Appears the Java runtime is version 8 and the SDK is up to 15. Two different things, correct? _________________ Mark |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Mon Feb 01, 2021 4:17 am Post subject: Bug found in Setup.vbs |
|
|
I tried to use IrScrutinizer's embedded Java with RMIR, i.e. setting JAVA_HOME to C:\Program Files\IrScrutinizer\jre-x86-windows. Does not work. Looking in the Setup.vbs reveals that JAVA_HOME is expected to contain the string "Java", which is not true here.
I suggest instead using the existence of %JAVA_HOME%\bin\javaw.exe as sanity test. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Mon Feb 01, 2021 9:17 am Post subject: |
|
|
Mark Pierson wrote: | Appears the Java runtime is version 8 and the SDK is up to 15. Two different things, correct? |
Not really. It looks as if Oracle is no longer bothering to produce a separate runtime JRE as the JDK serves both purposes. Users with no interest in development can use the JDK as if it were a JRE. The original distinction goes way back to when memory was a scarce resource and the JRE took significantly less than the JDK. That is no longer the case so perhaps Oracle considers it no longer worth the bother to make the distinction. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Mon Feb 01, 2021 9:31 am Post subject: Re: Bug found in Setup.vbs |
|
|
Barf wrote: | I tried to use IrScrutinizer's embedded Java with RMIR, i.e. setting JAVA_HOME to C:\Program Files\IrScrutinizer\jre-x86-windows. Does not work. Looking in the Setup.vbs reveals that JAVA_HOME is expected to contain the string "Java", which is not true here.
I suggest instead using the existence of %JAVA_HOME%\bin\javaw.exe as sanity test. |
Thanks for this observation. Yes, I see that for the JAVA_HOME value to be recognised by RMIR, its path must contain a subdirectory called Java (with that capitalization). I will look into amending this for the next release in the way you suggest. _________________ Graham |
|
Back to top |
|
|
Mark Pierson Expert
Joined: 03 Aug 2003 Posts: 3017 Location: Connecticut, USA |
Posted: Mon Feb 01, 2021 9:06 pm Post subject: |
|
|
mathdon wrote: | Mark Pierson wrote: | Appears the Java runtime is version 8 and the SDK is up to 15. Two different things, correct? |
Not really. It looks as if Oracle is no longer bothering to produce a separate runtime JRE as the JDK serves both purposes. Users with no interest in development can use the JDK as if it were a JRE. The original distinction goes way back to when memory was a scarce resource and the JRE took significantly less than the JDK. That is no longer the case so perhaps Oracle considers it no longer worth the bother to make the distinction. |
When I go here https://www.java.com/en/download/ I can only download 64-bit Java version 8 update 281 (which is what's currently installed on my laptop). This is not a JDK. _________________ Mark |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3365
|
|
Back to top |
|
|
Lurker
Joined: 11 Apr 2004 Posts: 120
|
Posted: Tue Feb 02, 2021 1:14 pm Post subject: |
|
|
Thank you for this explanation. I too was stuck on Java 8 with no idea how to upgrade. After installing Java 15, RMIR is SO much easier to use!
However, I am now getting the following messages:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.hifiremote.jp1.RemoteMaster to method java.lang.ClassLoader.findLoadedClass(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.hifiremote.jp1.RemoteMaster
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Appears to cause no problems now, but may do so "in a future release". |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Wed Feb 03, 2021 2:54 am Post subject: |
|
|
I am not very convinced about how the magnification factor is handled. The better way would be for the user to select the magnification factor from the GUI in the installed program. Requiring the user to restart the program is ok. Using the presently known technology, this would mean that a wrapper does the job (relatively easy on Linux, harder on Windows) which would not be a portable solution. For this reason, there is no direct user support in IrScrutinizer. (There is a possibility to enable it in the Linux wrapper in a comment, though.) So I hope (and believe) we will find a better solution in the future.
The only supported and reliable method to get the version of the user's JVM is to invoke java[w].exe with the -version parameter. Trying to infer the version from the text of the pathname is awfully error prone. But actually, since a magnification parameter to a JVM that does not support it is just ignored, the simplest way would be just to put it in, possibly warning the user that it will only work with "new" JVMs.
Please also consider the case (I will argue that it is the normal case) that the user wants to use the system's current default JVM, and this should not break if Java decides to update itself. (Possibly this is alredy so?) |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Wed Feb 03, 2021 6:48 am Post subject: |
|
|
Barf wrote: | The only supported and reliable method to get the version of the user's JVM is to invoke java[w].exe with the -version parameter. Trying to infer the version from the text of the pathname is awfully error prone. |
I agree, but could find no other way to do it when adding the JAVA_HOME facility to Setup.vbs. Any attempt to use java -version produced no output in the Vbs code. I have now found out what is happening and think I can fix it and use that method. It appears, for reasons that I cannot comprehend, that the java -version command writes its output to the StdErr stream, not to StdOut which is what I expected and never questioned in my earlier attempts.
Quote: | Please also consider the case (I will argue that it is the normal case) that the user wants to use the system's current default JVM, and this should not break if Java decides to update itself. |
I don't understand what this means. As far as I can tell, there are at least three ways that Java programs identify the location of the Java executable. There is from JAVA_HOME, there is from finding the Java folder in the Path environment variable and there is from the Windows Registry entry created by a Java installer. Setup.vbs will use JAVA_HOME if it is present (the new way added by me) or otherwise the Registry entry (the previous way, which I believe was written by Greg). If you start RMIR by double-clicking, or any other way that does not use a short-cut, I presume it finds the Java executable from the Path environment variable. If you use a short-cut created by Setup.vbs then in all cases RMIR will use whatever Java is set in that short-cut, regardless of any Java update that may have occurred. You can, of course, run Setup.vbs multiple times to update the short-cuts if you so wish. If you start it by double-clicking it will use what it finds in the Path, which is presumably what you mean by the default. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Wed Feb 03, 2021 7:05 am Post subject: |
|
|
Lurker wrote: | I am now getting the message:
WARNING: Illegal reflective access by com.hifiremote.jp1.RemoteMaster to method java.lang.ClassLoader.findLoadedClass(java.lang.String) |
This method is used exactly once, when RMIR starts, to determine whether or not to set the parameter java.util.Arrays.useLegacyMergeSort to True. If the call to the method concerned fails then RMIR simply ignores it, leaving the parameter set to False. I cannot recall what this parameter does, but I will look into it and see if a fix is needed.
I don't have Java 15, only Java 14 and haven't seen this message. Where does it appear? _________________ Graham |
|
Back to top |
|
|
Lurker
Joined: 11 Apr 2004 Posts: 120
|
Posted: Wed Feb 03, 2021 12:37 pm Post subject: |
|
|
mathdon wrote: | Lurker wrote: | I am now getting the message:
WARNING: Illegal reflective access by com.hifiremote.jp1.RemoteMaster to method java.lang.ClassLoader.findLoadedClass(java.lang.String) |
This method is used exactly once, when RMIR starts, to determine whether or not to set the parameter java.util.Arrays.useLegacyMergeSort to True. If the call to the method concerned fails then RMIR simply ignores it, leaving the parameter set to False. I cannot recall what this parameter does, but I will look into it and see if a fix is needed.
I don't have Java 15, only Java 14 and haven't seen this message. Where does it appear? |
It appears in the console window immediately upon launching, before the RMIR window opens. It causes no problems now, but the warning message says "All illegal access operations will be denied in a future release". |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Wed Feb 03, 2021 2:06 pm Post subject: |
|
|
I have posted a revised Setup.vbs for testing that now makes no assumptions about the path given in JAVA_HOME. Please try it ad report your findings.
Barf wrote: | I am not very convinced about how the magnification factor is handled. ... So I hope (and believe) we will find a better solution in the future. |
This revision does not change the way the magnification factor is handled. That will have to wait for the better solution you believe will come in future. What it does do is use java -version to determine the version and identifies three possibilities: (a) the version is less than 11, (b) the version is 11 or higher, (c) the version could not be determined. The option to set a scale factor is given in both (b) and (c).
Users may notice a command window briefly opening and closing during the processing of Setup.vbs that did not occur before. This is because it now calls a Java command to read the Java version reliably, while previously it read the version unreliably from the Java path.
Edit: I have now further revised the file at the link above to get rid of the transient appearance of a command window during processing. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Thu Feb 04, 2021 2:21 pm Post subject: |
|
|
I have now posted development build 6 of RMIR v2.12 in the RMIR Development folder on SourceForge. This has two changes from build 5, the current release build. It is intended to eliminate the warnings seen by Lurker, see his posts above, and it also includes the (further) revised Setup.vbs described in the preceding post.
Please report any issues found with this development build. It is possible that the fix for the warnings may have introduced some new bugs. My testing has not revealed any, but confirmation from other users would be welcome. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1402 Location: Munich, Germany |
Posted: Fri Feb 05, 2021 5:56 am Post subject: |
|
|
I have downloaded and tested in (not extensively). I can confirm that it works with using IrScrutinizer's embedded Java (which is AdoptOpenJDK 11.0.5 btw).
Starting a device editor from RMIR does not preserve the magnification, but I think I have told you before about that problem of firing up another instance of the JVM.
Also, I would propose to ask the user for the location of javaw.exe instead of requesting a system variable JAVA_HOME. That environment variable is not used for anything else, and might even be unwanted. It is also illogical to recommend against installing in a system location and then ask for a system (as opposed to a user) environment variable. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4515 Location: Cambridge, UK |
Posted: Fri Feb 05, 2021 9:16 am Post subject: |
|
|
I did not invent JAVA_HOME for RMIR. I quote from stackoverflow.com here Quote: | JAVA_HOME is a environment variable (in Unix terminologies), or a PATH variable (in Windows terminology). A lot of well behaving Java applications (which need the JDK/JRE) to run, looks up the JAVA_HOME variable for the location where the Java compiler/interpreter may be found. |
so I do not think I am doing anything out of the ordinary. Setting JAVA_HOME is also part of these instructions for manually installing Java 11, so although the stackoverflow thread is old, JAVA_HOME is still in current use.
Barf wrote: | Starting a device editor from RMIR does not preserve the magnification, but I think I have told you before about that problem of firing up another instance of the JVM. |
Thanks for reminding me of this. I had forgotten, but I don't see how to fix it. It's the same issue as how to set a scale factor if RMIR is opened by double-clicking RemoteMaster.jar, to which I have no solution. _________________ Graham |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|