prerelase of icedtea-web 1.8
Jiri Vanek
jvanek at redhat.com
Thu Mar 7 14:30:14 UTC 2019
So we can go without push of "" O?-)
On 3/7/19 3:26 PM, Lars Herschke wrote:
>>> Not always, I just recall problems with this in case of cygpath. Do you mind to try it without?
>>> If you do mind, I will push like it is. But would rather avoid double slash in jre_home\\bin\java
>
> I can not confirm or imitate that.
>
> The following little test program:
>
> fn main()
> {
> let mut p1 = std::path::PathBuf::from(r"C:\Program Files");
> p1.push("");
> println!("{}", p1.display());
>
> let mut p2 = std::path::PathBuf::from(r"C:\Program Files\");
> p2.push("");
> println!("{}", p2.display());
> }
>
> gives out:
>
> p1: C:\Program Files\
> p2: C:\Program Files\
>
>
>
>
> Mit freundlichen Grüßen
>
> Lars Herschke
>
> Data-Service GmbH
> Beethovenstraße 2a
> 23617 Stockelsdorf
> Amtsgericht Lübeck, HRB 318 BS
> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
> e-mail: lhersch at dssgmbh.de
>
>
> Jiri Vanek schrieb:
>> On 3/7/19 2:59 PM, Lars Herschke wrote:
>>> So i set, the final directory separator, automatically as a slash or
>>> backslash, matching the operating system. If one is already present,
>>> that is harmless.
>>
>> Not always, I just recall problems with this in case of cygpath. Do you mind to try it without?
>> If you do mind, I will push like it is. But would rather avoid double slash in jre_home\\bin\java
>>
>> Imho every path.push(x) is actually doing \x or /x.
>>
>>
>> J.
>>>
>>>
>>> Mit freundlichen Grüßen
>>>
>>> Lars Herschke
>>>
>>> Data-Service GmbH
>>> Beethovenstraße 2a
>>> 23617 Stockelsdorf
>>> Amtsgericht Lübeck, HRB 318 BS
>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>> e-mail: lhersch at dssgmbh.de
>>>
>>>
>>> Jiri Vanek schrieb:
>>>> Thanx!
>>>>
>>>> Why the:
>>>> + jre_dir.push("");
>>>>
>>>> ?
>>>>
>>>> I cant see wher eit iterates over 11, 1.8 and so on, but I trust it does :)
>>>>
>>>> Except the empty push, Althouh it is hard to read itm I'm ok with the patch, and will push it for
>>>> you (once the mepty push is justified/removed)
>>>> On 3/7/19 2:37 PM, Lars Herschke wrote:
>>>>> forgot patch
>>>>>
>>>>> Mit freundlichen Grüßen
>>>>>
>>>>> Lars Herschke
>>>>>
>>>>> Data-Service GmbH
>>>>> Beethovenstraße 2a
>>>>> 23617 Stockelsdorf
>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>> Tel. (0451) 49 00-188
>>>>> Fax. (0451) 49 00-123
>>>>> e-mail: lhersch at dssgmbh.de
>>>>>
>>>>>
>>>>> Lars Herschke schrieb:
>>>>>> So, here is the new patch.
>>>>>>
>>>>>> This patch tries to get JavaHome out of the registry with the following
>>>>>> priosrization.
>>>>>>
>>>>>> - JRE 1.8
>>>>>> - JDK 1.8
>>>>>> - max JDK >= 9
>>>>>> - JDK 1.8
>>>>>> - max JDK >= 9
>>>>>> - max JRE >= 9 (only 9 or 10 possible)
>>>>>> - max JDK < 1.8
>>>>>> - max JRE < 1.8
>>>>>>
>>>>>> The highest minor version within the major version is always preferred.
>>>>>>
>>>>>> In addition, the method find_jre checks with this patch whether it makes
>>>>>> sense to append the jre directory.
>>>>>>
>>>>>>
>>>>>> Mit freundlichen Grüßen
>>>>>>
>>>>>> Lars Herschke
>>>>>>
>>>>>> Data-Service GmbH
>>>>>> Beethovenstraße 2a
>>>>>> 23617 Stockelsdorf
>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>> Tel. (0451) 49 00-188
>>>>>> Fax. (0451) 49 00-123
>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>
>>>>>>
>>>>>> Lars Herschke schrieb:
>>>>>>> Hi Jiri.
>>>>>>>
>>>>>>>>> - in addition I was unable to verify against jdk8. The ojdkbuild of jdk8 never put anything into
>>>>>>>>> "my" registry.
>>>>>>>
>>>>>>> This can be selected and deselected in the installer. That's why I'm
>>>>>>> testing JAVA_HOME and PATH so hard.
>>>>>>>
>>>>>>> I am currently testing a new version of my patch. I hope to be able to
>>>>>>> make it available today.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mit freundlichen Grüßen
>>>>>>>
>>>>>>> Lars Herschke
>>>>>>>
>>>>>>> Data-Service GmbH
>>>>>>> Beethovenstraße 2a
>>>>>>> 23617 Stockelsdorf
>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>> Tel. (0451) 49 00-188
>>>>>>> Fax. (0451) 49 00-123
>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>
>>>>>>>
>>>>>>> Jiri Vanek schrieb:
>>>>>>>> Hi Again.
>>>>>>>>
>>>>>>>> Attached is the workig version of my patch from yesterday.
>>>>>>>>
>>>>>>>> I realised that my approach requires: java_registry_path("SOFTWARE\\JavaSoft\\JDK\\11.0.2")
>>>>>>>> - note the security number. This it is no go.
>>>>>>>> - in addition I was unable to verify against jdk8. The ojdkbuild of jdk8 never put anything into
>>>>>>>> "my" registry.
>>>>>>>>
>>>>>>>> From what I seen, your patch is ok with jdk11,12 and onwards untill the registry changes again, right?
>>>>>>>>
>>>>>>>> J.
>>>>>>>>
>>>>>>>> On 3/6/19 6:47 PM, Lars Herschke wrote:
>>>>>>>>>> What are the regQuery and RegEnumKeyExW for?
>>>>>>>>>
>>>>>>>>> RegQueryInfoKeyW gives me the number of subkeys, so I can get directly
>>>>>>>>> the last subkey with RegEnumKeyExW.
>>>>>>>>>
>>>>>>>>>> I do tt see versions in the query.. What is the pooled order? SHould be
>>>>>>>>>> jre8->jdk8->jdk11->jdkAnythingElse
>>>>>>>>>
>>>>>>>>> I try to get Java in the following order.
>>>>>>>>>
>>>>>>>>> - latest pre JMPS-JRE
>>>>>>>>> - latest pre JMPS-JDK
>>>>>>>>> - latest JMPS-JDK
>>>>>>>>> - latest JMPS-JRE
>>>>>>>>>
>>>>>>>>> I always try to get the latest Java, favoring the pre JPMS Java.
>>>>>>>>> However, so I may prefer a Java 7 to a Java 11.
>>>>>>>>>
>>>>>>>>>>> Do you mind to comapre with mine patch? (and honestly say that it is garbage and yours is more
>>>>>>>>>>> bulletproof - I do not expect more)
>>>>>>>>>
>>>>>>>>> I dont't understand on your patch, how jdkX_registry_path,
>>>>>>>>> jreX_registry_path and jdk11plus_registry_path should work. There is no
>>>>>>>>> JavaHome-key on these levels.
>>>>>>>>>
>>>>>>>>>>> I disagree with Your change to JAVA_HOME and PATH - because it can already be jre. On contrary, if
>>>>>>>>>>> it si jdk, then it is already valid. HAve that part bitten you somewhere?
>>>>>>>>>
>>>>>>>>> You are right, but on Windows, JAVA_HOME is only set by ojdkbuild and
>>>>>>>>> this set JAVA_HOME to his jdk root-directory. Oracle-Java don't set
>>>>>>>>> JAVA_HOME, but writes registry keys ever.
>>>>>>>>> The PATH is set from ojdkbuild to [jdk-root]\bin, so my changes also
>>>>>>>>> works. The PATH from Oracle-Java is complete outside the java directory
>>>>>>>>> (C:\Program Files (x86)\Common Files\Oracle\Java\javapath). In this path
>>>>>>>>> you will not find any library.
>>>>>>>>> Everything said so far, only applies to Java 8. As of Java 9, there is
>>>>>>>>> no more jre directory around jdk.
>>>>>>>>> In the end, you can not know if PATH or JAVA_HOME is a jdk or a jre,
>>>>>>>>> without checking it.
>>>>>>>>> It did not bother me, I just tried to be more compatible with the
>>>>>>>>> standard installations under windows
>>>>>>>>> Last but not least, the method is called find_jre.:-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>
>>>>>>>>> Lars Herschke
>>>>>>>>>
>>>>>>>>> Data-Service GmbH
>>>>>>>>> Beethovenstraße 2a
>>>>>>>>> 23617 Stockelsdorf
>>>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>>>> Tel. (0451) 49 00-188
>>>>>>>>> Fax. (0451) 49 00-123
>>>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jiri Vanek schrieb:
>>>>>>>>>> On 3/6/19 5:16 PM, Lars Herschke wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> attached a new separate windows registry patch.
>>>>>>>>>>
>>>>>>>>>> Wou. Interesting approach. As you had not replied if you will elaborate on it, I had in meantime
>>>>>>>>>> did simialr patch (attached, not tested, literally just finished writing right now, and started to
>>>>>>>>>> warm up windows VM) - absed on yours, jsut with the pooling of registry.
>>>>>>>>>>
>>>>>>>>>> My patch looks a bit more rustlike - especailly it uses chain of match instead of loop, and TBH I
>>>>>>>>>> do not understand half of yours :)
>>>>>>>>>> What are the regQuery and RegEnumKeyExW for?
>>>>>>>>>> I do tt see versions in the query.. What is the pooled order? SHould be
>>>>>>>>>> jre8->jdk8->jdk11->jdkAnythingElse
>>>>>>>>>> Do you mind to comapre with mine patch? (and honestly say that it is garbage and yours is more
>>>>>>>>>> bulletproof - I do not expect more)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I disagree with Your change to JAVA_HOME and PATH - because it can already be jre. On contrary, if
>>>>>>>>>> it si jdk, then it is already valid. HAve that part bitten you somewhere?
>>>>>>>>>>
>>>>>>>>>> Really thanx!
>>>>>>>>>> J.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>>>
>>>>>>>>>>> Lars Herschke
>>>>>>>>>>>
>>>>>>>>>>> Data-Service GmbH
>>>>>>>>>>> Beethovenstraße 2a
>>>>>>>>>>> 23617 Stockelsdorf
>>>>>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>>>>>> Tel. (0451) 49 00-188
>>>>>>>>>>> Fax. (0451) 49 00-123
>>>>>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jiri Vanek schrieb:
>>>>>>>>>>>> On 3/5/19 2:29 PM, Lars Herschke wrote:
>>>>>>>>>>>>>> Ok. Then I would suggest the following steps:
>>>>>>>>>>>>>> - Does it have sense to check both jre and jsk keys? jre first, and jdk as fallback? If not, then
>>>>>>>>>>>>>> I'm happy with ou jre from registy patch. Do you mind to post it as separate patch? In both cases
>>>>>>>>>>>>>> (jre->jdk fallback, jre search only) I will push for you asap.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you plan to check more than one regkey than you should check in the
>>>>>>>>>>>>> following order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
>>>>>>>>>>>>> 2. HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit
>>>>>>>>>>>>> 3. HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK
>>>>>>>>>>>>> 4. HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. for the last pre-JPMS-jre (max Java 9)
>>>>>>>>>>>>> 2. for the last pre-JPMS-jdk (max Java 8)
>>>>>>>>>>>>> 3. for the last JPMS-jdk ( Java 11+)
>>>>>>>>>>>>> 4. for the last JPMS-jre (max Java 10)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Starting with Java 11 you have to check the jdk first, because there is
>>>>>>>>>>>>> nor jre anymore.
>>>>>>>>>>>>
>>>>>>>>>>>> Are you willing to code that? I would promiss you a beer on fosdem :)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lars Herschke
>>>>>>>>>>>>>
>>>>>>>>>>>>> Data-Service GmbH
>>>>>>>>>>>>> Beethovenstraße 2a
>>>>>>>>>>>>> 23617 Stockelsdorf
>>>>>>>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>>>>>>>> Tel. (0451) 49 00-188
>>>>>>>>>>>>> Fax. (0451) 49 00-123
>>>>>>>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jiri Vanek schrieb:
>>>>>>>>>>>>>> On 3/5/19 1:54 PM, Lars Herschke wrote:
>>>>>>>>>>>>>>> Hi Jiri.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm wondering why the acinclude hunk is necessary - Do you intend to ship..or whatever custom
>>>>>>>>>>>>>>>>> itw-binaries built on windows? The build is the only thing I do seriously on windows, and thus I'm
>>>>>>>>>>>>>>>>> wondering why I had never needed it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have installed my jdk direct in windows and not inside cygwin. So my
>>>>>>>>>>>>>>> path inside cygwin is /cygdrive/c/Program\
>>>>>>>>>>>>>>> Files/ojdkbuild/java-1.8.0-openjdk-1.8.0.201-1. This path isn't found by
>>>>>>>>>>>>>>> configure without jdk-home-configure-switch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have it installed to in windows, but something must go differently. Will push this hunk for you asap
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The unittest++ targets are for plugin only,. You should not even hit them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Without my changes i get the following error when i make "make clean".
>>>>>>>>>>>>>>> "make: *** No rule to make target 'clean-unittest++', needed by
>>>>>>>>>>>>>>> 'clean-tests'. Stop."
>>>>>>>>>>>>>>> clean-unittest++ is commented out in the generated Makefile because i
>>>>>>>>>>>>>>> build without native plugin.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hm interesting, I'm running cleanow and iot works. Anyway will test you changeset, and if ti do not
>>>>>>>>>>>>>> break anything (which I dubt) will push it for you asap.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Dunce is an problem - ITW, being distribution friendly, can not rely on random cargo pulled from
>>>>>>>>>>>>>>>>> web. Sorry. If it is really doing such a troubles, then I'm afraid it must go in in way, it can be
>>>>>>>>>>>>>>>>> ifouted on linxu. Do you mind to elaborate on this?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you have an jdk on windows without registry entries and set without
>>>>>>>>>>>>>>> JAVA_HOME, than jdk from path is trying. This path is canonicalized and
>>>>>>>>>>>>>>> leads to an unc-path. I have in a test spawn() persuaded (with
>>>>>>>>>>>>>>> current_dir) to use this unc-path, but java.exe don't like unc-path in
>>>>>>>>>>>>>>> his classpath.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Last hint - if I install JDK on windows. Will it still be found in registry in way you changed the
>>>>>>>>>>>>>>>>> search?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When you install openjdk with ojdkbuild it will be found. When you
>>>>>>>>>>>>>>> install oracle-jdk and you don't disable "Public JRE" in the installer,
>>>>>>>>>>>>>>> than it would also be found.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok. Then I would suggest the following steps:
>>>>>>>>>>>>>> - Does it have sense to check both jre and jsk keys? jre first, and jdk as fallback? If not, then
>>>>>>>>>>>>>> I'm happy with ou jre from registy patch. Do you mind to post it as separate patch? In both cases
>>>>>>>>>>>>>> (jre->jdk fallback, jre search only) I will push for you asap.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Please provide dunce changeset as separate changeset. We have to discuss, how to make it
>>>>>>>>>>>>>> disable-able.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please reconsider fx patch. I dont think it is necessary. If it is, I would liek to know your case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanx!
>>>>>>>>>>>>>> J.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lars Herschke
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Data-Service GmbH
>>>>>>>>>>>>>>> Beethovenstraße 2a
>>>>>>>>>>>>>>> 23617 Stockelsdorf
>>>>>>>>>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>>>>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>>>>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>>>>>>>>>> Tel. (0451) 49 00-188
>>>>>>>>>>>>>>> Fax. (0451) 49 00-123
>>>>>>>>>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jiri Vanek schrieb:
>>>>>>>>>>>>>>>> Hi Lars!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you very much for eyballing the windows state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm wondering why the acinclude hunk is necessary - Do you intend to ship..or whatever custom
>>>>>>>>>>>>>>>> itw-binaries built on windows? The build is the only thing I do seriously on windows, and thus I'm
>>>>>>>>>>>>>>>> wondering why I had never needed it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The unittest++ targets are for plugin only,. You should not even hit them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dunce is an problem - ITW, being distribution friendly, can not rely on random cargo pulled from
>>>>>>>>>>>>>>>> web. Sorry. If it is really doing such a troubles, then I'm afraid it must go in in way, it can be
>>>>>>>>>>>>>>>> ifouted on linxu. Do you mind to elaborate on this?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Last hint - if I install JDK on windows. Will it still be found in registry in way you changed the
>>>>>>>>>>>>>>>> search?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hmm. The jfxrt is shameful bug, as the path is crippled also in shell and bat launchers an I keep
>>>>>>>>>>>>>>>> wondering how it could hapened it was not hit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> again, thanx a lot for this set of fixes!
>>>>>>>>>>>>>>>> J.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/5/19 11:32 AM, Lars Herschke wrote:
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> attached a patch that cause the following changes.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> acinclude.m4:
>>>>>>>>>>>>>>>>> - configure-switch --with-jdk-home acts on windows
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Makefile.am:
>>>>>>>>>>>>>>>>> - windows-fix for changeset 1565:7010aa9d9309
>>>>>>>>>>>>>>>>> - fixes for make clean with native plugin disabled
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> rust-launcher:
>>>>>>>>>>>>>>>>> 1. Use cannonicalize from crate dunce, because std::fs:canonicalize
>>>>>>>>>>>>>>>>> return on windows unc-paths like this \\?\C:\foo. This paths doesn't
>>>>>>>>>>>>>>>>> work with spawn() from std::process::Command.
>>>>>>>>>>>>>>>>> 2. Correct path for jfxrt.jar
>>>>>>>>>>>>>>>>> 3. Use JRE-path instead of JDK-path from registry and don't panic if
>>>>>>>>>>>>>>>>> this regkey doesn't exist, because jfxrt.jar, rt.jar and nashorn.jar
>>>>>>>>>>>>>>>>> are only in the JRE-directory on openjdk. In addition users, that
>>>>>>>>>>>>>>>>> have only installed JRE don't have the JDK-regkey in your registry.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mit freundlichen Grüßen
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Lars Herschke
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Data-Service GmbH
>>>>>>>>>>>>>>>>> Beethovenstraße 2a
>>>>>>>>>>>>>>>>> 23617 Stockelsdorf
>>>>>>>>>>>>>>>>> Amtsgericht Lübeck, HRB 318 BS
>>>>>>>>>>>>>>>>> Geschäftsführung: Wilfried Paepcke, Dr. Andreas Longwitz,
>>>>>>>>>>>>>>>>> Dr. Uwe Szyszka, Dr. Hans-Martin Rasch
>>>>>>>>>>>>>>>>> Tel. (0451) 49 00-188
>>>>>>>>>>>>>>>>> Fax. (0451) 49 00-123
>>>>>>>>>>>>>>>>> e-mail: lhersch at dssgmbh.de
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jiri Vanek schrieb:
>>>>>>>>>>>>>>>>>> TYVM. Pushed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Prerelase binraries will be updated on demand.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> J.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2/25/19 10:39 AM, Olesya Gerasimenko wrote:
>>>>>>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please find attached the updated Russian translation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 22.02.2019 14:15, Jiri Vanek пишет:
>>>>>>>>>>>>>>>>>>>> Hello all!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Please see the pre-release of icedtea-web 1.8: https://jvanek.fedorapeople.org/itw1.8/
>>>>>>>>>>>>>>>>>>>> If you can push it through your cases, it would be awesome. There are native portable builds for
>>>>>>>>>>>>>>>>>>>> both win and Linuxes. There is also multiplatform portable build based on shell/bat launchers only.
>>>>>>>>>>>>>>>>>>>> I had also updated (not released!) fedora builds to this pre - see "fedora" text file:
>>>>>>>>>>>>>>>>>>>> While this prerelase is in testing, I would like to call alive translators - Russian and Czech - to
>>>>>>>>>>>>>>>>>>>> update theirs translations in
>>>>>>>>>>>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/file/tip/netx/net/sourceforge/jnlp/resources/. In
>>>>>>>>>>>>>>>>>>>> addition, I will start backporting of non-native patches to 1.7 so 1.7.2 can follow 1.8 very soon.
>>>>>>>>>>>>>>>>>>>> 1.8 will be released once translations are in place. Of course anything wrong reported with
>>>>>>>>>>>>>>>>>>>> pre-released tarballs will be fixed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Windows testing:
>>>>>>>>>>>>>>>>>>>> * icedtea-web-1.8pre.portable.bin.zip
>>>>>>>>>>>>>>>>>>>> * icedtea-web-1.8pre.win.bin.zip
>>>>>>>>>>>>>>>>>>>> * itw-installer.msi
>>>>>>>>>>>>>>>>>>>> + icedtea-web-1.8pre.tar.gz (sources for custom builds - optional)
>>>>>>>>>>>>>>>>>>>> + https://jvanek.fedorapeople.org/itw1.8/icedtea-web-docs/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Linux testng:
>>>>>>>>>>>>>>>>>>>> * iccedtea-web-1.8pre.linux.bin.zip
>>>>>>>>>>>>>>>>>>>> * icedtea-web-1.8pre.portable.bin.zip
>>>>>>>>>>>>>>>>>>>> * icedtea-web-1.8pre.tar.gz (sources for distributions and custom builds - mandatory)
>>>>>>>>>>>>>>>>>>>> * fedora
>>>>>>>>>>>>>>>>>>>> + https://jvanek.fedorapeople.org/itw1.8/icedtea-web-docs/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note for JRE search:
>>>>>>>>>>>>>>>>>>>> * windows shell scripts reads java_home or or registry
>>>>>>>>>>>>>>>>>>>> * linux shell scripts reads java_home or defualt system jdk
>>>>>>>>>>>>>>>>>>>> * native launchers reads in addition system paths
>>>>>>>>>>>>>>>>>>>> TBH, I doubt I covered all combinations when I run my suites
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Cases (if you have lack of them, but many of them may be already dead):
>>>>>>>>>>>>>>>>>>>> * https://icedtea.classpath.org/wiki/IcedTea-Web-Tests#javaws
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>>> https://icedtea.classpath.org/wiki/IcedTea-Web-Tests#IcedTea-Web_webstart_.28javaws.29_test_applications
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Known bugs:
>>>>>>>>>>>>>>>>>>>> 3705 --- Webstarted application tries to load resources from server incorrectly
>>>>>>>>>>>>>>>>>>>> 3704 --- IcedTeaWeb doesn't run SAP PI web start interface - LAZY_CLASSLOADING_FAILED
>>>>>>>>>>>>>>>>>>>> 3697 --- Custom JRE/JDK within UTF-8 folder name ( key deployment.jre.dir in in
>>>>>>>>>>>>>>>>>>>> deployment.properties ) are not properly handled
>>>>>>>>>>>>>>>>>>>> 3689 --- DownloadService2 not implemented
>>>>>>>>>>>>>>>>>>>> 3672 --- Classloader doesn't load jar correctly from JNLP extension
>>>>>>>>>>>>>>>>>>>> 3461 --- (still) Cannot run HP ILO4 remote console application
>>>>>>>>>>>>>>>>>>>> Windows desktop shortcuts are suspected to not work with jdk11 and up
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Linux side, except native launchers and few bug fixes, not much changed. But for windows support
>>>>>>>>>>>>>>>>>>>> this is giant leap to be finally proper replacement for oracle javaws.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For 1.9 the plan is to remove plugin completely, and to move to github and under the wings of
>>>>>>>>>>>>>>>>>>>> AdoptOpenJDK....
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Looking forward for both positive and negative feedbacks
>>>>>>>>>>>>>>>>>>>> J.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com M: +420775390109
More information about the distro-pkg-dev
mailing list