prerelase of icedtea-web 1.8

Jiri Vanek jvanek at redhat.com
Thu Mar 7 14:02:30 UTC 2019


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