From christoph.langer at sap.com Sun Oct 2 09:54:59 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 2 Oct 2016 09:54:59 +0000 Subject: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: Vote: yes Best regards Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Dmitry Fazunenko > Sent: Freitag, 30. September 2016 12:34 > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK9 Committer: Michail Chernov > > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at > Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount= > 500 > > > From serguei.spitsyn at oracle.com Sun Oct 2 13:18:54 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 2 Oct 2016 06:18:54 -0700 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: Vote: yes From tobias.hartmann at oracle.com Mon Oct 3 07:06:29 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 3 Oct 2016 09:06:29 +0200 Subject: Result: New JDK9 Committer: Rahul Raghavan Message-ID: <57F20375.6020602@oracle.com> Voting for Rahul Raghavan is now closed [1]. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004898.html From tobias.hartmann at oracle.com Mon Oct 3 07:06:44 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 3 Oct 2016 09:06:44 +0200 Subject: Result: New JDK9 Committer: Jamsheed Mohammed Message-ID: <57F20384.2080206@oracle.com> Voting for Jamsheed Mohammed is now closed [1]. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Tobias [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004899.html From kirill.zhaldybin at oracle.com Mon Oct 3 12:38:57 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Mon, 3 Oct 2016 15:38:57 +0300 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: <73dc9697-ff2f-4bc9-335f-0df2d1afbb2f@oracle.com> Vote: yes Regards, Kirill On 30.09.2016 13:34, Dmitry Fazunenko wrote: > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at > Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount=500 > > > > From tatiana.pivovarova at oracle.com Mon Oct 3 13:26:33 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 3 Oct 2016 16:26:33 +0300 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: Vote: yes -- Tatiana On 09/30/2016 01:34 PM, Dmitry Fazunenko wrote: > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at > Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount=500 > > > > From eric.caspole at oracle.com Mon Oct 3 14:44:02 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 3 Oct 2016 10:44:02 -0400 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: <54d00016-5d3d-4fc7-400a-612f1ab826f7@oracle.com> Vote: yes Eric On 09/30/2016 06:34 AM, Dmitry Fazunenko wrote: > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at > Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount=500 > > > > > From pavel.punegov at oracle.com Tue Oct 4 14:34:08 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Tue, 4 Oct 2016 17:34:08 +0300 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: Vote: yes ? Thanks, Pavel Punegov > On 30 Sep 2016, at 13:34, Dmitry Fazunenko wrote: > > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount=500 > > > > From srinivas.dama at oracle.com Wed Oct 5 14:21:10 2016 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 5 Oct 2016 07:21:10 -0700 (PDT) Subject: RFR:8055033: Shell tests for jrunscript don't pass through VM options Message-ID: <89ec1fe4-5e9c-4013-bc15-cfc142aebd2a@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8055033/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8055033 When launching java and javac from shell script, ${TESTVMOPTS}, ${TESTJAVAOPTS} and ${TESTTOOLVMOPTS}, ${TESTJAVACOPTS} should be passed in respectively since jtreg sets these environment variables. Regards, Srinivas From goetz.lindenmaier at sap.com Wed Oct 5 15:32:41 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 5 Oct 2016 15:32:41 +0000 Subject: Proposed schedule change for JDK 9 In-Reply-To: <20160913155640.71291CD3B6@eggemoggin.niobe.net> References: <20160913155640.71291CD3B6@eggemoggin.niobe.net> Message-ID: <8108f1615ee546b7b210334e46443692@DEWDFE13DE50.global.corp.sap> Hi, it's now about three weeks that the jdk9 has been postponed. Are there already more precise dates known? It would be helpful to have an update of the jdk9 milesones, as we need to communicate these dates: http://openjdk.java.net/projects/jdk9/ Best regards, Goetz. > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Mark Reinhold > Sent: Dienstag, 13. September 2016 17:57 > To: jdk9-dev at openjdk.java.net > Subject: Proposed schedule change for JDK 9 > > Eighty-five JEPs are targeted to JDK 9 [1]. Most of those are done, or > very nearly so. We are not, unfortunately, where we need to be relative > to the current schedule. > > We've made a lot of progress on Project Jigsaw [2], the key feature of > the release, over the last eight months. In March 2016 we published a > major update to the proposed design of the module system [3] and merged > it into the JDK 9 master forest [4]. Since then many developers have > downloaded the EA builds and sent in feedback (thanks!), both on the > module system itself and on its impact upon the rest of the JDK. > > Despite this progress, at this point it's clear that Jigsaw needs more > time. We recently received critical feedback that motivated a redesign > of the module system's package-export feature [5], without which we'd > have failed to achieve one of our main goals. There are, beyond that, > still many open design issues [6], which will take time to work through. > > Looking at the release as a whole, the number of open bugs that are new > in JDK 9 is quite a bit larger than it was at this point in JDK 8. The > maintainers of many popular projects are now actively testing against > the JDK 9 EA builds [7], but we'd like to see even more in order to be > confident that potential issues have been found and reported. > > For these reasons I hereby propose a four-month extension of the JDK 9 > schedule, moving the General Availability (GA) milestone to July 2017. > I'll make a more detailed proposal for that date and other milestones > in the next few weeks, but for now I suggest we defer the start of the > Rampdown process [8] and continue to operate with the previously-adopted > Feature Complete extension-request process [9]. > > Minor enhancements and even strongly-justified proposals to target new > JEPs to JDK 9 will be considered, so long as they do not add undue risk > to the overall release. As before, however, our main focus should be to > use this additional time to stabilize, polish, and fine-tune the features > that we already have rather than add a bunch of new ones. > > Comments on this proposal from JDK 9 Committers are welcome, as are > reasoned objections. If no such objections are raised by 16:00 UTC next > Tuesday, 20 September, or if they're raised and satisfactorily answered, > then per the JEP 2.0 process proposal [a] this will be adopted as the > new schedule for JDK 9. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/ > [2] http://openjdk.java.net/projects/jigsaw/ > [3] http://openjdk.java.net/projects/jigsaw/spec/sotms/ > [4] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > March/003877.html > [5] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016- > September/009365.html > [6] http://openjdk.java.net/projects/jigsaw/spec/issues/ > [7] https://wiki.openjdk.java.net/display/quality/Quality+Outreach > [8] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > August/004777.html > [9] http://openjdk.java.net/projects/jdk9/fc-extension-process > [a] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From lana.steuck at oracle.com Wed Oct 5 20:24:27 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 5 Oct 2016 20:24:27 GMT Subject: jdk9-b139: dev Message-ID: <201610052024.u95KORiK020827@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/7dcf453eacae http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/e3b11296395b http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/17a82cb0e4b4 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5518ac2f2ead http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/7a7aadf3c450 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/8991d71c5316 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/08492e67bf32 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/8c9da7fc5b07 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8165263 client-libs Remove code in MetaData that hacks into private fields of Collections JDK-8151179 core-libs address issues raised by JCK team on JEP 274 API JDK-8155760 core-libs Implement Serialization Filtering JDK-8162519 core-libs Remove ParallelPrefix.java from ProblemList.txt JDK-8165261 core-libs RMI API to export an object with a serialization filter JDK-8165466 core-libs DecimalFormat percentage format can contain unexpected % JDK-8165806 core-libs UnicastServerRef support to export an object with a filter JDK-8165944 core-libs jar utility doesn't process more than one -C argument JDK-8166287 core-libs MultiReleaseJarAPI.isMultiReleaseJar(): failure java.nio.file.AccessDe JDK-8166584 core-libs Remove obsolete utility function NET_ThrowSocketException in windows l JDK-8166739 core-libs Improve extensibility of ObjectInputFilter information passed to the f JDK-8166840 core-libs Synthetic bridge constructor in ArrayList$Itr blocks inlining JDK-8166841 core-libs Unused import causes test failure on compilation for java.text tests JDK-8166842 core-libs String.hashCode() has a non-benign data race JDK-8166850 core-libs No runtime error expected after calling NET_MapSocketOption JDK-8166866 core-libs (ch) Remove AIX specific implementation file java.base/aix/native/libn JDK-8166902 core-libs Nested object literal property maps not reset in optimistic recompilat JDK-8166993 core-libs typo in java.util.Locale javadoc JDK-8167037 core-libs Remove CALL_METHOD support from internal Nashorn linkers JDK-8167058 core-libs (fs) UnixDirectoryIterator::stream unused JDK-8153711 core-svc [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing inv JDK-8165017 core-svc Additional test coverage of the JDWP CLASSLOADER and MODULE commands JDK-8167026 core-svc Quarantine TestDaemonThread.java JDK-6648858 hotspot InvokeHangTest.java fails due to "failure: Debuggee appears to be hung JDK-8027920 hotspot SA: Add default methods to InstanceKlass JDK-8058229 hotspot heapdump/JMapHeapCore and heapdump/JMapMetaspaceCore fail due to SA no JDK-8078644 hotspot CDS needs to support JVMTI CFLH JDK-8136766 hotspot Enable ThreadStackSize range test JDK-8157952 hotspot Parallelize Memory Pretouch JDK-8159422 hotspot Very high Concurrent Mark mark stack contention JDK-8163406 hotspot The fixup_module_list must be protected by Module_lock when inserting JDK-8165192 hotspot [TESTBUG] runtime/signal/sigsegv01: SIGSEGV: signal_num=11, mode=sign JDK-8165489 hotspot Missing G1 barrier in Unsafe_GetObjectVolatile JDK-8165808 hotspot Add release barriers when allocating objects with concurrent collectio JDK-8166207 hotspot Use of Copy::conjoint_oops_atomic in global mark stack causes crashes JDK-8166228 hotspot Remove unused HeapRegion::object_iterate_mem_careful() JDK-8166229 hotspot Eliminate ParNew's use of klass_or_null() JDK-8166312 hotspot Backout 8165017 JDK-8166948 infrastructure Exploded image too slow to be usable JDK-8166965 infrastructure Some small java build tools are still running with big JVM configurati JDK-6946830 security-libs javax.crypto.Cipher.doFinal behavior differs depending on platform JDK-8149802 security-libs Signature.verify() doesn't reset the signature object on exception JDK-8164591 security-libs sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed JDK-8166378 security-libs Missing dependencies in several java/security tests JDK-8073844 tools fatal annotation processing errors do not stop compilation JDK-8152911 tools javac assertion error when compiling overlay sources JDK-8154714 tools jshell tool: add exports support JDK-8165735 tools jlink incorrectly accepts multiple --module-path and --limit-modules JDK-8166144 tools New javadoc options don't conform to JEP 293 (GNU style options) JDK-8166238 tools Update jdeps for GNU-style long form options JDK-8166363 tools Method with reordered type parameter bounds compiles with @Override an JDK-8166645 tools Include locales plugin throws InternalError with "*" specified. JDK-8166744 tools JShell: java.lang.IndexOutOfBoundsException for legal history access From alejandro.murillo at oracle.com Wed Oct 5 21:26:26 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Wed, 5 Oct 2016 15:26:26 -0600 Subject: jdk9-dev: HotSpot Message-ID: <2f0b8ac9-c4e7-47da-6404-37b6df1a031e@oracle.com> jdk9-hs-2016-09-28 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/a902e9316e39 http://hg.openjdk.java.net/jdk9/dev/corba/rev/8c9da7fc5b07 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/633725d9b0f7 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/dbdf839b7925 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/7a7aadf3c450 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/83d6bce162ea http://hg.openjdk.java.net/jdk9/dev/langtools/rev/076a0354bedb http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/7f5887b2f7a8 Component : VM Status : Go for integration Date : 10/04/2016 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-09-30-095324.amurillo.jdk9-hs-2016-09-28-snapshot Testing: 19 new failures, 2853 known failures, 14629278 passed. Issues and Notes: No stoppers have been detected. Go for integration CRs for testing: 8033552: Fix missing missing volatile specifiers in CAS operations in GC code 8078122: YMM registers upper 128 bits may get clobbered by a JNI call on windows 8129376: SPECjvm98-client performance regression in 9-b66 8146546: assert(fr->safe_for_sender(thread)) failed: Safety check 8147943: jvmti.h generated with GPL header 8150758: [TESTBUG] need jvmti tests for module aware agents 8154122: Intrinsify fused mac operations 8156852: Convert JSON_test to Gtest 8159818: Convert IHOP_test to GTest 8160987: JDWP ClassType.InvokeMethod doesn't validate class 8161085: PreserveFPRegistersTest fails with 'AssertionError: Final value has changed' 8161225: Assert failure in JVMTI GetNamedModule at JPLISAgent.c line: 792 8163969: Cyclic interface initialization causes JVM crash 8164011: --patch-module support for CDS 8164482: [REDO] G1 does not implement millis_since_last_gc which is needed by RMI GC 8164508: unexpected profiling mismatch in c1 generated code 8164852: Move slow tier1/tier2 runtime tests to later tiers 8164920: ppc: enhancement of CRC32 intrinsic 8164987: RTM jtreg tests failing due to unnamed module unable to access class jdk.internal.misc.Unsafe 8165235: [TESTBUG] RTM tests must check OS version 8165372: StackWalker performance regression following JDK-8147039 8165433: Convert Test_linked_list to Gtest 8165434: [JVMCI] remove uses of setAccessible 8165439: Convert Test_TempNewSymbol to GTest 8165457: [JVMCI] increase InterpreterCodeSize for JVMCI 8165537: runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointerException 8165565: Shorten branches causes incorrect code for SKX 8165601: Convert arrayOopDesc_test to Gtest 8165602: Convert TestChunkedList_test to GTest 8165613: Convert TestKlass_test to Gtest 8165755: [JVMCI] replace use of vm_abort with vm_exit 8165857: CMS _overflow_list is missing volatile specifiers. 8165858: heapRegionManager is missing volatile specifier for _claims. 8165860: WorkGroup classes are missing volatile specifiers for lock-free code 8166045: jdk/internal/misc/Unsafe tests fail due to timeout 8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME 8166096: variable tracking size limit exceeded in jvmciCompilerToVM.cpp 8166140: C1: Possible integer overflow in LIRGenerator::generate_address on several platforms 8166164: compiler/compilercontrol/share/processors/LogProcessor.java does not close Scanner 8166202: Tracefile gensrc cannot handle closed src dir in different location 8166433: AArch64: Fix for JDK-8163014 broke AArch64 build 8166483: gtest fmw should be updated to support null detection on SS >= 12u4 8166501: compilation error in stackwalk.cpp on some gccs 8166549: fix incorrectly @ignore-d hotspot/compiler tests 8166552: SA: Missed testcase for add default methods to InstanceKlass 8166583: Add oopDesc::klass_or_null_acquire() 8166663: Simplify oops_on_card_seq_iterate_careful 8166765: [ppc] Port "8163014: Mysterious/wrong value for long frame local variable on 64-bit" 8166777: [ppc] port "8164086: Checked JNI pending exception check should be cleared" -- Alejandro From iris.clark at oracle.com Thu Oct 6 21:00:17 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 6 Oct 2016 14:00:17 -0700 (PDT) Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name Message-ID: Hi. Please review changes to address the following bug: 8166799: ASSEMBLY_EXCEPTION contains historical company name https://bugs.openjdk.java.net/browse/JDK-8166799 http://cr.openjdk.java.net/~iris/8166799/webrev/ The ASSEMBLY_EXCEPION file [0] across all JDK releases and open repositories (, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn) contains multiple references to "Sun". We should stop using the historical company name. We should also remove reference to "openjdk.dev.java.net" which does not exist. Reformatting of the file causes more diffs than are strictly necessary so I've appended an unformatted diff to this message for your convenience. The same reformatted file is used across all repositories. Thanks, Iris [0] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/ASSEMBLY_EXCEPTION ----- unformatted diffs ----- diff -r 81435a812f59 ASSEMBLY_EXCEPTION --- a/ASSEMBLY_EXCEPTION Thu Oct 06 14:03:14 2016 +0200 +++ b/ASSEMBLY_EXCEPTION Thu Oct 06 13:09:44 2016 -0700 @@ -1,8 +1,8 @@ OPENJDK ASSEMBLY EXCEPTION -The OpenJDK source code made available by Sun at openjdk.java.net and -openjdk.dev.java.net ("OpenJDK Code") is distributed under the terms of the +The OpenJDK source code made available by Oracle America, Inc. (Oracle) at openjdk.java.net +("OpenJDK Code") is distributed under the terms of the GNU General Public License version 2 only ("GPL2"), with the following clarification and special exception. @@ -10,18 +10,18 @@ is making a combined work based on this library. Thus, the terms and conditions of GPL2 cover the whole combination. - As a special exception, Sun gives you permission to link this - OpenJDK Code with certain code licensed by Sun as indicated at + As a special exception, Oracle gives you permission to link this + OpenJDK Code with certain code licensed by Oracle as indicated at http://openjdk.java.net/legal/exception-modules-2007-05-08.html ("Designated Exception Modules") to produce an executable, regardless of the license terms of the Designated Exception Modules, and to copy and distribute the resulting executable under GPL2, provided that the Designated Exception Modules continue to be - governed by the licenses under which they were offered by Sun. + governed by the licenses under which they were offered by Oracle. -As such, it allows licensees and sublicensees of Sun's GPL2 OpenJDK Code to -build an executable that includes those portions of necessary code that Sun -could not provide under GPL2 (or that Sun has provided under GPL2 with the +As such, it allows licensees and sublicensees of Oracle's GPL2 OpenJDK Code to +build an executable that includes those portions of necessary code that Oracle +could not provide under GPL2 (or that Oracle has provided under GPL2 with the Classpath exception). If you modify or add to the OpenJDK code, that new GPL2 code may still be combined with Designated Exception Modules if the new code is made subject to this exception by its copyright holder. From mandy.chung at oracle.com Thu Oct 6 21:03:39 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 6 Oct 2016 14:03:39 -0700 Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name In-Reply-To: References: Message-ID: > On Oct 6, 2016, at 2:00 PM, Iris Clark wrote: > > Hi. > > Please review changes to address the following bug: > > 8166799: ASSEMBLY_EXCEPTION contains historical company name > https://bugs.openjdk.java.net/browse/JDK-8166799 > > http://cr.openjdk.java.net/~iris/8166799/webrev/ +1 Mandy From tim.bell at oracle.com Thu Oct 6 21:37:55 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 6 Oct 2016 14:37:55 -0700 Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name In-Reply-To: References: Message-ID: <5395cdec-9d26-f6f4-06f4-91bd3e739caa@oracle.com> On 10/06/16 14:00, Iris Clark wrote: > Please review changes to address the following bug: > > 8166799: ASSEMBLY_EXCEPTION contains historical company name > https://bugs.openjdk.java.net/browse/JDK-8166799 > > http://cr.openjdk.java.net/~iris/8166799/webrev/ Looks good to me. Tim From iris.clark at oracle.com Thu Oct 6 21:50:51 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 6 Oct 2016 14:50:51 -0700 (PDT) Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name In-Reply-To: References: Message-ID: <653ec54c-5deb-49a1-8ce9-d5dc27e07863@default> Hi, Mandy. Thanks for the Review! iris -----Original Message----- From: Mandy Chung Sent: Thursday, October 06, 2016 2:04 PM To: Iris Clark Cc: jdk9-dev at openjdk.java.net Subject: Re: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name > On Oct 6, 2016, at 2:00 PM, Iris Clark wrote: > > Hi. > > Please review changes to address the following bug: > > 8166799: ASSEMBLY_EXCEPTION contains historical company name > https://bugs.openjdk.java.net/browse/JDK-8166799 > > http://cr.openjdk.java.net/~iris/8166799/webrev/ +1 Mandy From iris.clark at oracle.com Thu Oct 6 21:51:00 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 6 Oct 2016 14:51:00 -0700 (PDT) Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name In-Reply-To: <5395cdec-9d26-f6f4-06f4-91bd3e739caa@oracle.com> References: <5395cdec-9d26-f6f4-06f4-91bd3e739caa@oracle.com> Message-ID: <1ce5ed33-1813-4fb0-8d4d-4f9fb5a07f22@default> Hi, Tim. Thanks so much for Reviewing. Can you Sponsor this change for me? Thanks, iris -----Original Message----- From: Tim Bell Sent: Thursday, October 06, 2016 2:38 PM To: Iris Clark; jdk9-dev at openjdk.java.net Subject: Re: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name On 10/06/16 14:00, Iris Clark wrote: > Please review changes to address the following bug: > > 8166799: ASSEMBLY_EXCEPTION contains historical company name > https://bugs.openjdk.java.net/browse/JDK-8166799 > > http://cr.openjdk.java.net/~iris/8166799/webrev/ Looks good to me. Tim From iris.clark at oracle.com Fri Oct 7 01:40:31 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 6 Oct 2016 18:40:31 -0700 (PDT) Subject: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name In-Reply-To: <1ce5ed33-1813-4fb0-8d4d-4f9fb5a07f22@default> References: <5395cdec-9d26-f6f4-06f4-91bd3e739caa@oracle.com> <1ce5ed33-1813-4fb0-8d4d-4f9fb5a07f22@default> Message-ID: Hi, Tim. Thanks for Sponsoring this change for me! iris -----Original Message----- From: Iris Clark Sent: Thursday, October 06, 2016 2:51 PM To: Tim Bell; jdk9-dev at openjdk.java.net Subject: RE: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name Hi, Tim. Thanks so much for Reviewing. Can you Sponsor this change for me? Thanks, iris -----Original Message----- From: Tim Bell Sent: Thursday, October 06, 2016 2:38 PM To: Iris Clark; jdk9-dev at openjdk.java.net Subject: Re: RFR (s) 8166799: ASSEMBLY_EXCEPTION contians historical company name On 10/06/16 14:00, Iris Clark wrote: > Please review changes to address the following bug: > > 8166799: ASSEMBLY_EXCEPTION contains historical company name > https://bugs.openjdk.java.net/browse/JDK-8166799 > > http://cr.openjdk.java.net/~iris/8166799/webrev/ Looks good to me. Tim From dmitry.dmitriev at oracle.com Mon Oct 10 14:05:42 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 10 Oct 2016 17:05:42 +0300 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: <10412385-1b92-1d3a-3837-4cb53c79d6d6@oracle.com> Vote: yes Dmitry On 30.09.2016 13:34, Dmitry Fazunenko wrote: > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > Michail is currently a JDK 9 Author and a member of the VM SQE team at > Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 14, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Dima > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/dev/hotspot/search/?rev=mchernov&revcount=500 > > > > From alexandr.scherbatiy at oracle.com Mon Oct 10 18:22:19 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Mon, 10 Oct 2016 21:22:19 +0300 Subject: Result: New JDK 9 Committer: Prem Balakrishnan Message-ID: <57FBDC5B.8060904@oracle.com> Voting for Prem Balakrishnan [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks, Alexandr. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004924.html From joe.darcy at oracle.com Tue Oct 11 02:11:43 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 10 Oct 2016 19:11:43 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 Message-ID: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Hello, Looking ahead to JDK 10, a group of JDK engineers have been exploring consolidating the large number of Hg repositories in an open JDK forest to a single one with the goal of using the consolidated arrangement for JDK 10. This message is being sent to jdk9-dev since a jdk10-dev alias to discuss JDK 10 doesn't exist yet. A JEP describing the project has been submitted : JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single repository https://bugs.openjdk.java.net/browse/JDK-8167368 The text of the JEP describes the motivation and current state of the work in more detail, including proposed changes to the file layout. Publication of the prototype consolidated repository is planned, but not done yet. The email below has a list of additional anticipated questions and answers. We feel this consolidated arrangement offers some significant structural advantages for managing the JDK's source code and we are now asking for feedback on this potential change. In particular, if you feel there is a show-stopper problem with making this change, please let us know! I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and Ingemar Aberg participating in discussions leading up to the prototype and I'd like to especially recognize the contributions of Erik Helin for savvy Hg manipulations and Erik Joelsson for skillful build wrangling in this project. Please send initial comments by October 18, 2016. Cheers, -Joe Q: What about the set of forests for JDK 10? Are we going to have master, dev, client, hotspot, etc. the same set as in 9? A: That is a separate question from the repository consolidation, but there will likely be simplifications here too. Discussions on that point will come later. Q: I usually just build the code in repo X today. Will I have have to build the *whole JDK* now? A: Not necessarily. The same top-level build targets should work in the consolidated forest. Q: Does disk usage change? A: The total disk usage of the current forest compared to the consolidated forest is nearly the same. Q: In more detail, how were the changesets imported? A: The scripts used for the consolidation conversion are attached to the JEP. Q: What happens to the Hg hashes? A: The conversion scheme used in the prototype does *not* preserve Hg hashes of changesets compared the current forests. However, the bug ids are preserved and can be searched for. In addition, one or more pre-consolidation forests should be archived in perpetuity so that URLs in bug comments continue to work, etc. A mapping of the old hashes to the corresponding new hashes might be generated and placed in the final new repo. Q: I'm allergic to tabs; what about jcheck? A: If history is preserved, the checking done by jcheck needs to be modified for the consolidated forest. One way to do this is to augment the white lists used in jcheck with the conflicting changesets. This approach may not be elegant, but it is effective and doesn't appear to appreciably impact jcheck running times. Q: Will the future 9 update forest also have this consolidation restructuring? A: The script used to do the consolidation conversion is deterministic and could be run to create the 9 update forest in the future at the discretion of the 9 update team. Q: For backports for forwardports, will there be a script to translate patch files across the consolidation boundary? A: That work is planned, but not yet done; see JDK-8165623: Create patch translator to update paths pre/post consolidation. Q: It's the 21st century and I develop using an IDE. That is still going to work, right? A: The prototype to date does include updating the various IDE support files, but bug JDK-8167142 has been filed to track that work. From weijun.wang at oracle.com Tue Oct 11 02:37:27 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Oct 2016 10:37:27 +0800 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <89999114-826e-dcd3-266d-a1bf5746186d@oracle.com> I am very glad to see history preserved. Is it possible to also merge the history for src files before modularization and after it with this magical script? I can call "hg log -f" on the command line but the web interface only shows partial history. Thanks Max On 10/11/2016 10:11, joe darcy wrote: > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK forest > to a single one with the goal of using the consolidated arrangement for > JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to > discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the > work in more detail, including proposed changes to the file layout. > Publication of the prototype consolidated repository is planned, but not > done yet. The email below has a list of additional anticipated questions > and answers. > > We feel this consolidated arrangement offers some significant structural > advantages for managing the JDK's source code and we are now asking for > feedback on this potential change. In particular, if you feel there is a > show-stopper problem with making this change, please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > Ingemar Aberg participating in discussions leading up to the prototype > and I'd like to especially recognize the contributions of Erik Helin for > savvy Hg manipulations and Erik Joelsson for skillful build wrangling in > this project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have > master, dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but > there will likely be simplifications here too. Discussions on that point > will come later. > > Q: I usually just build the code in repo X today. Will I have have to > build the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in the > consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the > consolidated forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to the > JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg > hashes of changesets compared the current forests. However, the bug ids > are preserved and can be searched for. In addition, one or more > pre-consolidation forests should be archived in perpetuity so that URLs > in bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be > generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be > modified for the consolidated forest. One way to do this is to augment > the white lists used in jcheck with the conflicting changesets. This > approach may not be elegant, but it is effective and doesn't appear to > appreciably impact jcheck running times. > > Q: Will the future 9 update forest also have this consolidation > restructuring? > A: The script used to do the consolidation conversion is deterministic > and could be run to create the 9 update forest in the future at the > discretion of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate > patch files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create patch > translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still going > to work, right? > A: The prototype to date does include updating the various IDE support > files, but bug JDK-8167142 has been filed to track that work. > From goetz.lindenmaier at sap.com Tue Oct 11 09:30:08 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 11 Oct 2016 09:30:08 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: Hi, I see several problems with this approach. 1.) Mercurial already has problems scaling with the current repositories. This will get worse with bigger repos. E.g. 'hg diff' takes 14 secs on jdk, but only 2 secs on jaxp: jdk: ~90000 files, 15000 changes, hg diff takes 14 secs jaxp: ~12000 files, 1000 changes, hg diff takes 2 secs 2.) Cloning the repo does not scale. Cloning the root repo and calling get_source.sh takes 20 min. I ususally only clone the root repo and hotspot. This only takes 3 min. I don't think merging the repos might improve the 20 mins. In contrary, as cloning the jdk repo takes most of the time, and the others run in parallel, cloning an even bigger repo will be slower. Alternatively, one could hold a 'master' repo and replicate that by local copy. But this shows similar timings (1:40 vs. 9min). 3.) Having to clone the full repos will require considerably more disk space. I'm working on various issues in hotspot and keep them seperated by doing this in individual repositories that only contain hotspot. These repos will require considerably more space. 4.) There will be additional merges because changes that are now done in two repos will then be done in a single repo. If I then sync back a few hotspot changes, a lot of files in the other subdirectories will get touched. This slows down sync and causes rebuilds. Sure this might just be what is intended, but currently I don't need to rebuild jdk etc. very often. 5.) It will get harder to monitor submitted changes that are relevant for a specific area. E.g., I might only want to see changes in hotspot. In the web frontend, you can not browse changes on subdirectory basis. Maybe this can be solved, as the commandline 'hg log' etc. already support this. 6.) A single repo will simplify making combined changes. So there will be more of these. But combined changes complicate handling of our licensed code. In our activities as licensee, we are consuming hotspot change-wise. This is because we modified a lot in hotspot, and merging hotspot changes step by step simplifies the merging. On the other side, we consume the changes to jdk etc. as chunks. This is because we changed much less in these directories so that merging causes less problems. Also, there are much more changes and we don't have the manpower to consume them change-wise. Having combined changes requires more synchronization between the two merging tasks. It's already an increasing effort in jdk9. Also, to follow these two different merging approaches for hotspot and the rest, we would have to first split the single repo into two parts. Comments to the JEP: I appreciate that the change history is kept as it makes research in old changes more easy. On the other side, dropping the history might speed up handling of the new repo. I also appreciate the changes in directory layout. If the repos are merged, this should be done this way. We find it difficult to keep the jtreg runner in sync with our current version of jdk9, especially as we have two of them (We test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and jdk often differ in a few builds.) I would appreciate if the runner could be included in the root/test directory. Best regards, Goetz. > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > joe darcy > Sent: Dienstag, 11. Oktober 2016 04:12 > To: jdk9-dev at openjdk.java.net > Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 > > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK forest > to a single one with the goal of using the consolidated arrangement for > JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to > discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the > work in more detail, including proposed changes to the file layout. > Publication of the prototype consolidated repository is planned, but not > done yet. The email below has a list of additional anticipated questions > and answers. > > We feel this consolidated arrangement offers some significant structural > advantages for managing the JDK's source code and we are now asking for > feedback on this potential change. In particular, if you feel there is a > show-stopper problem with making this change, please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > Ingemar Aberg participating in discussions leading up to the prototype > and I'd like to especially recognize the contributions of Erik Helin for > savvy Hg manipulations and Erik Joelsson for skillful build wrangling in > this project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have > master, dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but > there will likely be simplifications here too. Discussions on that point > will come later. > > Q: I usually just build the code in repo X today. Will I have have to > build the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in the > consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the > consolidated forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to the > JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg > hashes of changesets compared the current forests. However, the bug ids > are preserved and can be searched for. In addition, one or more > pre-consolidation forests should be archived in perpetuity so that URLs > in bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be > generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be > modified for the consolidated forest. One way to do this is to augment > the white lists used in jcheck with the conflicting changesets. This > approach may not be elegant, but it is effective and doesn't appear to > appreciably impact jcheck running times. > > Q: Will the future 9 update forest also have this consolidation > restructuring? > A: The script used to do the consolidation conversion is deterministic > and could be run to create the 9 update forest in the future at the > discretion of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate > patch files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create patch > translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still going > to work, right? > A: The prototype to date does include updating the various IDE support > files, but bug JDK-8167142 has been filed to track that work. From joe.darcy at oracle.com Tue Oct 11 17:30:47 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 11 Oct 2016 10:30:47 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> Hi Goetz, On 10/11/2016 2:30 AM, Lindenmaier, Goetz wrote: > Hi, > > I see several problems with this approach. > > 1.) Mercurial already has problems scaling with the current repositories. > This will get worse with bigger repos. E.g. 'hg diff' takes > 14 secs on jdk, but only 2 secs on jaxp: > jdk: ~90000 files, 15000 changes, hg diff takes 14 secs > jaxp: ~12000 files, 1000 changes, hg diff takes 2 secs By its nature, hg diff needs to walk the directory tree so a bigger tree will generally be slower. Doing a diff on a particular subdirectory, say for hotspot, should have comparable performance as today. The fsmonitor extension, https://www.mercurial-scm.org/wiki/FsMonitorExtension, could help in this case too. > 2.) Cloning the repo does not scale. > Cloning the root repo and calling get_source.sh takes 20 min. > I ususally only clone the root repo and hotspot. This only > takes 3 min. > I don't think merging the repos might improve the 20 mins. > In contrary, as cloning the jdk repo takes most of the time, > and the others run in parallel, cloning an even bigger repo > will be slower. > Alternatively, one could hold a 'master' repo and replicate that > by local copy. But this shows similar timings (1:40 vs. 9min). We've discussed this kind of use-case internally as well. The recommendation is to have a designated local master and then do local clones of that. On a unix system if the local clones are on the same disk, hard links are used with a copy-on-write policy so the clones are space-efficient and time-efficient to create. The local clone times we've seen are about 30 seconds in that case. > 3.) Having to clone the full repos will require considerably more > disk space. > I'm working on various issues in hotspot and keep them seperated > by doing this in individual repositories that only contain hotspot. > These repos will require considerably more space. If disk space is a concern, you can use mq or bookmarks against a single repo. > > 4.) There will be additional merges because changes that are now done > in two repos will then be done in a single repo. If I then sync back > a few hotspot changes, a lot of files in the other subdirectories > will get touched. This slows down sync and causes rebuilds. > Sure this might just be what is intended, but currently I don't > need to rebuild jdk etc. very often. While hotspot and the rest of the JDK can often be treated as approximately independent, they are not truly independent. > > 5.) It will get harder to monitor submitted changes that are relevant > for a specific area. E.g., I might only want to see changes in hotspot. > In the web frontend, you can not browse changes on subdirectory basis. > Maybe this can be solved, as the commandline 'hg log' etc. already support > this. We don't have plans to change the Hg web UI so I think a command line solution would be appropriate here. > > 6.) A single repo will simplify making combined changes. So there will be > more of these. But combined changes complicate handling of our licensed > code. > In our activities as licensee, we are consuming hotspot change-wise. > This is because we modified a lot in hotspot, and merging hotspot > changes step by step simplifies the merging. > On the other side, we consume the changes to jdk etc. as chunks. > This is because we changed much less in these directories so > that merging causes less problems. Also, there are much more > changes and we don't have the manpower to consume them change-wise. > Having combined changes requires more synchronization between > the two merging tasks. It's already an increasing effort in > jdk9. > Also, to follow these two different merging approaches for hotspot > and the rest, we would have to first split the single repo into > two parts. > > > Comments to the JEP: > > I appreciate that the change history is kept as it makes research > in old changes more easy. On the other side, dropping the history > might speed up handling of the new repo. We are aware that Facebook has developed Hg plugins to allow shallow clones, i.e. clones without all the history, but we haven't investigated using them yet. > > I also appreciate the changes in directory layout. If the > repos are merged, this should be done this way. > > We find it difficult to keep the jtreg runner in sync with our > current version of jdk9, especially as we have two of them (We > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and > jdk often differ in a few builds.) > I would appreciate if the runner could be included in the > root/test directory. I'm not quite sure what you are referring to by the jtreg runner. Thanks, -Joe From sean.mullan at oracle.com Tue Oct 11 18:20:24 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Oct 2016 14:20:24 -0400 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov Message-ID: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. Artem is a member of the Java SE Security Libraries team at Oracle and has been an active and productive JDK 9 Committer. He has contributed 64 changesets [3, 4] to the JDK 9 Project. Votes are due by 25 October 2016, 8:00 PM UTC. Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Sean Mullan [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 [4] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com From sean.mullan at oracle.com Tue Oct 11 18:31:53 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Oct 2016 14:31:53 -0400 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: yes On 10/11/2016 02:20 PM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From artem.ananiev at oracle.com Tue Oct 11 18:30:53 2016 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 11 Oct 2016 11:30:53 -0700 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <57FD2FDD.3090600@oracle.com> Vote: yes Artem On 10/11/16, 11:20 AM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From anthony.scarpino at oracle.com Tue Oct 11 18:35:03 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 11 Oct 2016 11:35:03 -0700 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <57FD30D7.2020509@oracle.com> Vote: yes On 10/11/2016 11:20 AM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From alexander.zuev at oracle.com Tue Oct 11 18:38:08 2016 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 11 Oct 2016 21:38:08 +0300 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <5477c135-96b3-f530-8924-5e5619b15977@oracle.com> Vote: yes On 11/10/16 21:20, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed > 64 changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com From gnu.andrew at redhat.com Tue Oct 11 19:22:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 11 Oct 2016 15:22:02 -0400 (EDT) Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <429375530.341868.1476213722652.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK forest > to a single one with the goal of using the consolidated arrangement for > JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to > discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the > work in more detail, including proposed changes to the file layout. > Publication of the prototype consolidated repository is planned, but not > done yet. The email below has a list of additional anticipated questions > and answers. > > We feel this consolidated arrangement offers some significant structural > advantages for managing the JDK's source code and we are now asking for > feedback on this potential change. In particular, if you feel there is a > show-stopper problem with making this change, please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > Ingemar Aberg participating in discussions leading up to the prototype > and I'd like to especially recognize the contributions of Erik Helin for > savvy Hg manipulations and Erik Joelsson for skillful build wrangling in > this project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have > master, dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but > there will likely be simplifications here too. Discussions on that point > will come later. > > Q: I usually just build the code in repo X today. Will I have have to > build the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in the > consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the > consolidated forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to the > JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg > hashes of changesets compared the current forests. However, the bug ids > are preserved and can be searched for. In addition, one or more > pre-consolidation forests should be archived in perpetuity so that URLs > in bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be > generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be > modified for the consolidated forest. One way to do this is to augment > the white lists used in jcheck with the conflicting changesets. This > approach may not be elegant, but it is effective and doesn't appear to > appreciably impact jcheck running times. > > Q: Will the future 9 update forest also have this consolidation > restructuring? > A: The script used to do the consolidation conversion is deterministic > and could be run to create the 9 update forest in the future at the > discretion of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate > patch files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create patch > translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still going > to work, right? > A: The prototype to date does include updating the various IDE support > files, but bug JDK-8167142 has been filed to track that work. > > As someone who regularly works with the whole set of repositories, and has experienced the pain that was the forest extension back in the day, I wholeheartedly welcome this change. For me, having to remember to check out or update all those separate trees is just additional pain. With the addition of yet another repo in OpenJDK 8 (nashorn), I thought things were going in the opposite direction, so this comes as a welcome surprise. While I can see the benefits of having HotSpot, langtools and jdk in separate repos - they are largely separate pieces with separate groups working on them - the reasoning to have JAXP, JAXWS and CORBA separate always seemed bizarre to me. I think this will also lower the headache for newcomers in getting hold of OpenJDK. Having to download all these separate repositories is unusual and confusing. Now if we only get rid of having both 7 and 7u, 8 and 8u, etc. as well... I'm curious as to how much the directory structure will change. The least disruptive would be to just have hotspot, jaxws, jaxp, jdk, langtools, corba and nashorn becomes regular subdirectories in the root repository, as this wouldn't require any build changes. However, the bug suggests that the tree structures will be merged. I hope this won't be as disruptive as the changes in 9, and will instead largely keep the same structure, but merged together. With 9, I find myself having to use find to locate where files have moved to, and I haven't really seen any gain from that change. I do think it's very important to retain as much history as possible. I appreciate that the changeset IDs will change - that happens in backporting too - but being able to trace individual changes to bug IDs is incredibly important. One concern I do share with Goetz is the speed of the resulting repository. The JDK repository is already pretty slow in operation. Is there an example converted repository available? I think this would answer a lot of questions. Incidentally, it may be helpful to leave this open for comments later than the 18th, as that's the date of the upcoming CPU. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From joe.darcy at oracle.com Tue Oct 11 20:55:46 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 11 Oct 2016 13:55:46 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <429375530.341868.1476213722652.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <429375530.341868.1476213722652.JavaMail.zimbra@redhat.com> Message-ID: <57FD51D2.90405@oracle.com> Hi Andrew, On 10/11/2016 12:22 PM, Andrew Hughes wrote: > > ----- Original Message ----- [snip] >> >> > As someone who regularly works with the whole set of repositories, > and has experienced the pain that was the forest extension back in the > day, I wholeheartedly welcome this change. For me, having to remember > to check out or update all those separate trees is just additional pain. > With the addition of yet another repo in OpenJDK 8 (nashorn), I thought > things were going in the opposite direction, so this comes as a welcome > surprise. While I can see the benefits of having HotSpot, langtools and > jdk in separate repos - they are largely separate pieces with separate > groups working on them - the reasoning to have JAXP, JAXWS and CORBA > separate always seemed bizarre to me. > > I think this will also lower the headache for newcomers in getting hold > of OpenJDK. Having to download all these separate repositories is unusual > and confusing. Now if we only get rid of having both 7 and 7u, 8 and 8u, etc. > as well... > > I'm curious as to how much the directory structure will change. The JEP describes this in more detail; copying the description from there: "In the prototype. the eight repositories have been combined into a single repository using an automated conversion script that preserves history on a per file level with the consolidated forest being synchronized at the tags used to mark JDK promotions. The changeset comments and creation date are also preserved. The prototype has another level of code reorganization. In the consolidated forests, code for Java modules is generally combined under a single top-level src directory. For example, today in the OpenJDK forest there are module-based directories like $ROOT/jdk/src/java.base ... $ROOT/langtools/src/java.compiler ... In the consolidated OpenJDK forest, this code is instead organized as $ROOT/src/java.base $ROOT/src/java.compiler ... An analogous but less aggressive reorganization is planned (but not yet fully implemented) for the test directories to go from $ROOT/jdk/test/Foo.java $ROOT/langtools/test/Bar.java to $ROOT/test/jdk/Foo.java $ROOT/tests/langtools/Bar.java Since the effort is currently a prototype, not all portions of it are entirely complete and the fit and finish can be improved in some areas. For example, there are still some files left in vestigial $ROOT/jdk, $ROOT/langtools, etc. directories, but these stray files should be relocated as part of follow-up work. The HotSpot C/C++ sources are moved to the shared src directory alongside the modularized Java code. Supporting updates to the jtreg configuration files are in progress (JDK-8165187)." > The least > disruptive would be to just have hotspot, jaxws, jaxp, jdk, langtools, corba > and nashorn becomes regular subdirectories in the root repository, as this > wouldn't require any build changes. However, the bug suggests that the tree > structures will be merged. I hope this won't be as disruptive as the changes > in 9, and will instead largely keep the same structure, but merged together. > With 9, I find myself having to use find to locate where files have moved to, > and I haven't really seen any gain from that change. > > I do think it's very important to retain as much history as possible. I appreciate > that the changeset IDs will change - that happens in backporting too - but > being able to trace individual changes to bug IDs is incredibly important. Yes, all the history has been preserved, including the changeset comments with the bug ids. > > One concern I do share with Goetz is the speed of the resulting repository. > The JDK repository is already pretty slow in operation. > > Is there an example converted repository available? I think this would answer > a lot of questions. We don't have one publicly available yet, but plan to do so. I'll make an announcement when it is available. Thanks, -Joe From weijun.wang at oracle.com Tue Oct 11 23:22:09 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 12 Oct 2016 07:22:09 +0800 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <531FACC6-DA59-400A-97DC-BDFF585D553F@oracle.com> Vote: yes --weijun > On Oct 12, 2016, at 2:20 AM, Sean Mullan wrote: > > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > From mark.reinhold at oracle.com Tue Oct 11 23:25:58 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 11 Oct 2016 16:25:58 -0700 Subject: Proposed schedule change for JDK 9 In-Reply-To: <8108f1615ee546b7b210334e46443692@DEWDFE13DE50.global.corp.sap> References: <20160913155640.71291CD3B6@eggemoggin.niobe.net> <8108f1615ee546b7b210334e46443692@DEWDFE13DE50.global.corp.sap> Message-ID: <20161011162558.444993640eggemoggin.niobe.net> 2016/10/5 8:32:41 -0700, goetz.lindenmaier at sap.com: > it's now about three weeks that the jdk9 has been postponed. > Are there already more precise dates known? Still working through the details. Stay tuned ... - Mark From bradford.wetmore at oracle.com Tue Oct 11 23:35:50 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 11 Oct 2016 16:35:50 -0700 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: Yes Brad On 10/11/2016 11:20 AM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From xuelei.fan at oracle.com Wed Oct 12 00:16:09 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 12 Oct 2016 08:16:09 +0800 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: Yes. On 10/12/2016 2:20 AM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From goetz.lindenmaier at sap.com Wed Oct 12 07:16:14 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 Oct 2016 07:16:14 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> Message-ID: <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> Hi Joe, thanks for your detailed answer. Unfortunately it doesn't dispel my concerns. > Hi Goetz, > > On 10/11/2016 2:30 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I see several problems with this approach. > > > > 1.) Mercurial already has problems scaling with the current repositories. > > This will get worse with bigger repos. E.g. 'hg diff' takes > > 14 secs on jdk, but only 2 secs on jaxp: > > jdk: ~90000 files, 15000 changes, hg diff takes 14 secs > > jaxp: ~12000 files, 1000 changes, hg diff takes 2 secs > > By its nature, hg diff needs to walk the directory tree so a bigger tree > will generally be slower. Yes, and that's bad! > Doing a diff on a particular subdirectory, say > for hotspot, should have comparable performance as today. The use case of hg diff is to find what was changed. Obviously, if I only do it on the subdir, I might miss something. > The fsmonitor extension, > https://www.mercurial-scm.org/wiki/FsMonitorExtension, could help in > this case too. > > > 2.) Cloning the repo does not scale. > > Cloning the root repo and calling get_source.sh takes 20 min. > > I ususally only clone the root repo and hotspot. This only > > takes 3 min. > > I don't think merging the repos might improve the 20 mins. > > In contrary, as cloning the jdk repo takes most of the time, > > and the others run in parallel, cloning an even bigger repo > > will be slower. > > Alternatively, one could hold a 'master' repo and replicate that > > by local copy. But this shows similar timings (1:40 vs. 9min). > > We've discussed this kind of use-case internally as well. The > recommendation is to have a designated local master and then do local > clones of that. On a unix system if the local clones are on the same > disk, hard links are used with a copy-on-write policy so the clones are > space-efficient and time-efficient to create. The local clone times > we've seen are about 30 seconds in that case. I would have to run the watchman on all the machines I happen to work on. A possible solution imposing work on every user. > > 3.) Having to clone the full repos will require considerably more > > disk space. > > I'm working on various issues in hotspot and keep them seperated > > by doing this in individual repositories that only contain hotspot. > > These repos will require considerably more space. > If disk space is a concern, you can use mq or bookmarks against a single > repo. I use mq a lot. But often for separate tasks separate repos are required. Say, I'm working on - testing a change of someone other against head revision to review it. - developing the s390 port with a mq that contains 10 patches - looking for a performance regression by syncing to older revisions, building and running benchmarks in a script. You can't combine such tasks with a mq in one repo. > > 4.) There will be additional merges because changes that are now done > > in two repos will then be done in a single repo. If I then sync back > > a few hotspot changes, a lot of files in the other subdirectories > > will get touched. This slows down sync and causes rebuilds. > > Sure this might just be what is intended, but currently I don't > > need to rebuild jdk etc. very often. > > While hotspot and the rest of the JDK can often be treated as > approximately independent, they are not truly independent. Yes, but they _are_ approximately independent. That suffices to avoid lot's of boilerplate work. In other SCM systems you can sync back only a subdirectory. Mercurial does not support that. > > 5.) It will get harder to monitor submitted changes that are relevant > > for a specific area. E.g., I might only want to see changes in hotspot. > > In the web frontend, you can not browse changes on subdirectory basis. > > Maybe this can be solved, as the commandline 'hg log' etc. already > support > > this. > > We don't have plans to change the Hg web UI so I think a command line > solution would be appropriate here. You should consider fixing this, maybe as a follow up. You can already browse file history, This should be also possible for directories. > > 6.) A single repo will simplify making combined changes. So there will be > > more of these. But combined changes complicate handling of our > > licensed code. > > In our activities as licensee, we are consuming hotspot change-wise. > > This is because we modified a lot in hotspot, and merging hotspot > > changes step by step simplifies the merging. > > On the other side, we consume the changes to jdk etc. as chunks. > > This is because we changed much less in these directories so > > that merging causes less problems. Also, there are much more > > changes and we don't have the manpower to consume them change- > wise. > > Having combined changes requires more synchronization between > > the two merging tasks. It's already an increasing effort in > > jdk9. > > Also, to follow these two different merging approaches for hotspot > > and the rest, we would have to first split the single repo into > > two parts. > > > > > > Comments to the JEP: > > > > I appreciate that the change history is kept as it makes research > > in old changes more easy. On the other side, dropping the history > > might speed up handling of the new repo. > > We are aware that Facebook has developed Hg plugins to allow shallow > clones, i.e. clones without all the history, but we haven't investigated > using them yet. > > > > > I also appreciate the changes in directory layout. If the > > repos are merged, this should be done this way. > > > > We find it difficult to keep the jtreg runner in sync with our > > current version of jdk9, especially as we have two of them (We > > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and > > jdk often differ in a few builds.) > > I would appreciate if the runner could be included in the > > root/test directory. > > I'm not quite sure what you are referring to by the jtreg runner. I mean the code in http://hg.openjdk.java.net/code-tools/jtreg As Andrew stated, some subdirectories are pretty stable. It might completely make sense to merge these into one repository, but I'm really concerned about jdk and hotspot. In general, I think those people that are highly specialized on complex subcomponents of the VM will suffer from this. They often are fine just working with hotspot / jdk etc.. In general, these people develop new components in the latest branch. Those people that have to maintain and test the VM really will profit from the new setup. They anyways always operate with the full repo tree. Having this said, I think it would make more sense to put the legacy code base into merged repos, and not the development branch? Best regards, Goetz. From vincent.x.ryan at oracle.com Wed Oct 12 08:29:33 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 12 Oct 2016 09:29:33 +0100 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: yes > On 11 Oct 2016, at 19:20, Sean Mullan wrote: > > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and has been an active and productive JDK 9 Committer. He has contributed 64 changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > [4] http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com From erik.helin at oracle.com Wed Oct 12 12:16:04 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Oct 2016 14:16:04 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> Message-ID: <20161012121604.GC19291@ehelin.jrpg.bea.com> Hi Goetz, thanks for looking through the JEP and providing us with feedback! Please see my replies inline. On 2016-10-12, Lindenmaier, Goetz wrote: > Hi Joe, > > thanks for your detailed answer. Unfortunately it > doesn't dispel my concerns. > > > Hi Goetz, > > > > On 10/11/2016 2:30 AM, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > I see several problems with this approach. > > > > > > 1.) Mercurial already has problems scaling with the current repositories. > > > This will get worse with bigger repos. E.g. 'hg diff' takes > > > 14 secs on jdk, but only 2 secs on jaxp: > > > jdk: ~90000 files, 15000 changes, hg diff takes 14 secs > > > jaxp: ~12000 files, 1000 changes, hg diff takes 2 secs > > > > By its nature, hg diff needs to walk the directory tree so a bigger tree > > will generally be slower. > Yes, and that's bad! > > > Doing a diff on a particular subdirectory, say > > for hotspot, should have comparable performance as today. > > The use case of hg diff is to find what was changed. Obviously, if I only > do it on the subdir, I might miss something. Are you ever running `hg tdiff` today? If not, then how do you know you are not missing sending out part of your patch for reivew? If you are comfortable doing `hg diff` in only the hotspot repository today, then I don't see how running `hg diff hotspot` would make you less comfortable. > > The fsmonitor extension, > > https://www.mercurial-scm.org/wiki/FsMonitorExtension, could help in > > this case too. > > > > > 2.) Cloning the repo does not scale. > > > Cloning the root repo and calling get_source.sh takes 20 min. > > > I ususally only clone the root repo and hotspot. This only > > > takes 3 min. > > > I don't think merging the repos might improve the 20 mins. > > > In contrary, as cloning the jdk repo takes most of the time, > > > and the others run in parallel, cloning an even bigger repo > > > will be slower. > > > Alternatively, one could hold a 'master' repo and replicate that > > > by local copy. But this shows similar timings (1:40 vs. 9min). > > > > We've discussed this kind of use-case internally as well. The > > recommendation is to have a designated local master and then do local > > clones of that. On a unix system if the local clones are on the same > > disk, hard links are used with a copy-on-write policy so the clones are > > space-efficient and time-efficient to create. The local clone times > > we've seen are about 30 seconds in that case. > > I would have to run the watchman on all the machines I happen to > work on. A possible solution imposing work on every user. Again, working with local clones does scale. Do you use an SSD on the machines you are working on? If so, then cloning the consolidated repository locally shouldn't take more than approx 30 sec. As for watchman, that is only used to speed up `hg status`, so running e.g. `hg diff` or `hg status` in a subdirectory as I explained will yield similar benefits. > > > 3.) Having to clone the full repos will require considerably more > > > disk space. > > > I'm working on various issues in hotspot and keep them seperated > > > by doing this in individual repositories that only contain hotspot. > > > These repos will require considerably more space. > > > If disk space is a concern, you can use mq or bookmarks against a single > > repo. > > I use mq a lot. But often for separate tasks separate repos are required. > Say, I'm working on > - testing a change of someone other against head revision to review it. > - developing the s390 port with a mq that contains 10 patches > - looking for a performance regression by syncing to older revisions, > building and running benchmarks in a script. > You can't combine such tasks with a mq in one repo. No, but you can with e.g. bookmarks (or branches) and the CONF feature of the build system. I, for example, have one CONF per bookmark. That means I can update my code to the feature/bug I'm currently working on, make some changes, and get an incremental compilation (instead of rebuilding). If you prefer separate repositories, then again, local clones will help decrease the overhead. If you are open to discussing/sharing your workflow and trying out some features of Mercurial and the build system, then I'm confident we can find an effective way for you to work with a consolidated forest. > > > 4.) There will be additional merges because changes that are now done > > > in two repos will then be done in a single repo. If I then sync back > > > a few hotspot changes, a lot of files in the other subdirectories > > > will get touched. This slows down sync and causes rebuilds. > > > Sure this might just be what is intended, but currently I don't > > > need to rebuild jdk etc. very often. > > > > While hotspot and the rest of the JDK can often be treated as > > approximately independent, they are not truly independent. > > Yes, but they _are_ approximately independent. That suffices to > avoid lot's of boilerplate work. > In other SCM systems you can sync back only a subdirectory. > Mercurial does not support that. If I understand, you seem to be working mostly in the hotspot repository (and sometimes in the top-level)? If that is the case, then you are not feeling the pain of doing dependent changes between top-level, hotspot and the jdk. Many other developers feel this pain clearly, particulary developers working with: - performance (often require dependent changes in both JDK and hotspot) - build (often require dependent changes in all repos) - runtime (the tools in the jdk, e.g. jstat, often require dependent changes in jdk and hotspot) - testing (test often needs to be updated in both jdk, hotspot and top-level) Furthermore, many of us are interested in all changes going in, because there might be performance or functional regressions introduced due to changes in another repository. Having a way to perform a bisect tremendously helps in those situations. Again, if you mostly work in one repository, then you will not have been exposed to these problems. However, many developers in the OpenJDK project tend to work across many repositories. > > > 5.) It will get harder to monitor submitted changes that are relevant > > > for a specific area. E.g., I might only want to see changes in hotspot. > > > In the web frontend, you can not browse changes on subdirectory basis. > > > Maybe this can be solved, as the commandline 'hg log' etc. already > > support > > > this. > > > > We don't have plans to change the Hg web UI so I think a command line > > solution would be appropriate here. > > You should consider fixing this, maybe as a follow up. You can already > browse file history, This should be also possible for directories. That is a feature request that needs to be sent to the Mercurial project. The web ui of the OpenJDK repositories comes from the `hg serve` command, that is not something that Oracle has developed. I know that Mozilla has awarded a grant to the Mercurial project recently to improve the web UI [0], the Mercurial developers are probably interested in this kind of feedback. > > > 6.) A single repo will simplify making combined changes. So there will be > > > more of these. But combined changes complicate handling of our > > > licensed code. > > > In our activities as licensee, we are consuming hotspot change-wise. > > > This is because we modified a lot in hotspot, and merging hotspot > > > changes step by step simplifies the merging. > > > On the other side, we consume the changes to jdk etc. as chunks. > > > This is because we changed much less in these directories so > > > that merging causes less problems. Also, there are much more > > > changes and we don't have the manpower to consume them change- > > wise. > > > Having combined changes requires more synchronization between > > > the two merging tasks. It's already an increasing effort in > > > jdk9. > > > Also, to follow these two different merging approaches for hotspot > > > and the rest, we would have to first split the single repo into > > > two parts. > > > > > > > > > Comments to the JEP: > > > > > > I appreciate that the change history is kept as it makes research > > > in old changes more easy. On the other side, dropping the history > > > might speed up handling of the new repo. > > > > We are aware that Facebook has developed Hg plugins to allow shallow > > clones, i.e. clones without all the history, but we haven't investigated > > using them yet. > > > > > > > > I also appreciate the changes in directory layout. If the > > > repos are merged, this should be done this way. > > > > > > We find it difficult to keep the jtreg runner in sync with our > > > current version of jdk9, especially as we have two of them (We > > > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and > > > jdk often differ in a few builds.) > > > I would appreciate if the runner could be included in the > > > root/test directory. > > > > I'm not quite sure what you are referring to by the jtreg runner. > > I mean the code in http://hg.openjdk.java.net/code-tools/jtreg > > As Andrew stated, some subdirectories are pretty stable. It > might completely make sense to merge these into one repository, but I'm > really concerned about jdk and hotspot. > > In general, I think those people that are highly specialized on complex > subcomponents of the VM will suffer from this. They often are fine > just working with hotspot / jdk etc.. In general, these people develop > new components in the latest branch. You mean working on tip? The OpenJDK repositories do not make use of branches (besides having the sole default branch). > Those people that have to maintain and test the VM really will profit > from the new setup. They anyways always operate with the full > repo tree. > Having this said, I think it would make more sense to put the legacy code > base into merged repos, and not the development branch? When you say branch, do you mean "forest" (the wording is important here for me to understand since branch also in a concept in Mercurial)? That is, do you think of jdk9/dev, jdk9/hs and jdk9/jdk9 as branches? I personally always work with the "full tree" since it is crucial to develop changes on top of a stable "tree configuration". Even though hotspot and the jdk ususally are compatible with each other give or take a few days, there have been plenty of situations where having the repositories in a non-tested configuration can result in rather funky behavior. Again, I'm pretty confident that we can find a way for you (and the rest of the SAP contributors) to work effectively with a consolidated OpenJDK repository. I just need to learn more about your particular use case to come up with a nice solution. And you guys of course have to be willing to change your workflow slightly :) Thanks, Erik [0]: https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/ > Best regards, > Goetz. > > > From alexander.zvegintsev at oracle.com Wed Oct 12 12:40:18 2016 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 12 Oct 2016 15:40:18 +0300 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: yes -- Thanks, Alexander. On 11.10.2016 21:20, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed > 64 changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com From yuri.nesterenko at oracle.com Wed Oct 12 13:04:40 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Wed, 12 Oct 2016 16:04:40 +0300 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <5d784896-9310-9857-2679-9234d92ceefd@oracle.com> Vote: yes -yan On 10/11/2016 09:20 PM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed 64 > changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From goetz.lindenmaier at sap.com Wed Oct 12 13:57:02 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 Oct 2016 13:57:02 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <20161012121604.GC19291@ehelin.jrpg.bea.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <20161012121604.GC19291@ehelin.jrpg.bea.com> Message-ID: <9d3422912a5948b1bf10c5bd0297b2fa@DEWDFE13DE50.global.corp.sap> Hi Erik and Joe, I added more comments inline below :) But to subsume and not discuss my personal work setup: The planned setup - is benefitial if your work spans the sub-repos - imposes overhead if the work concentrates in one sub-repo. It moves efforts from keeping repos in sync / doing spanning changes to managing development setups/builds (branches, local clones, CONF). Also, I really think it brings mercurial closer to its limits, and you need to work around these. The basic idea of git and mercurial was to quickly clone, edit, submit, discard. Not to setup a local master repo and be your own SCM admin. Best regards, Goetz. > -----Original Message----- > From: Erik Helin [mailto:erik.helin at oracle.com] > Sent: Mittwoch, 12. Oktober 2016 14:16 > To: Lindenmaier, Goetz > Cc: joe darcy ; jdk9-dev at openjdk.java.net > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > Hi Goetz, > > thanks for looking through the JEP and providing us with feedback! Please > see > my replies inline. > > On 2016-10-12, Lindenmaier, Goetz wrote: > > Hi Joe, > > > > thanks for your detailed answer. Unfortunately it > > doesn't dispel my concerns. > > > > > Hi Goetz, > > > > > > On 10/11/2016 2:30 AM, Lindenmaier, Goetz wrote: > > > > Hi, > > > > > > > > I see several problems with this approach. > > > > > > > > 1.) Mercurial already has problems scaling with the current repositories. > > > > This will get worse with bigger repos. E.g. 'hg diff' takes > > > > 14 secs on jdk, but only 2 secs on jaxp: > > > > jdk: ~90000 files, 15000 changes, hg diff takes 14 secs > > > > jaxp: ~12000 files, 1000 changes, hg diff takes 2 secs > > > > > > By its nature, hg diff needs to walk the directory tree so a bigger tree > > > will generally be slower. > > Yes, and that's bad! > > > > > Doing a diff on a particular subdirectory, say > > > for hotspot, should have comparable performance as today. > > > > The use case of hg diff is to find what was changed. Obviously, if I only > > do it on the subdir, I might miss something. > > Are you ever running `hg tdiff` today? If not, then > how do you know you are not missing sending out part of your patch for > reivew? > > If you are comfortable doing `hg diff` in only the hotspot repository > today, then I don't see how running `hg diff hotspot` would make you > less comfortable. I don't know about hg tdiff. I must run hg diff on the full repo to make sure there is not boguous code somewhere. I don't need to diff jdk, if I only make a webrev for hotspot. But hg diff is only the example for a command I already now find annoyingly slow. Also, I don't want to optimize my personal work setup, I just want to mention possible pain-points. Still, hints how to do something more efficient are always welcome :) > > > The fsmonitor extension, > > > https://www.mercurial-scm.org/wiki/FsMonitorExtension, could help in > > > this case too. > > > > > > > 2.) Cloning the repo does not scale. > > > > Cloning the root repo and calling get_source.sh takes 20 min. > > > > I ususally only clone the root repo and hotspot. This only > > > > takes 3 min. > > > > I don't think merging the repos might improve the 20 mins. > > > > In contrary, as cloning the jdk repo takes most of the time, > > > > and the others run in parallel, cloning an even bigger repo > > > > will be slower. > > > > Alternatively, one could hold a 'master' repo and replicate that > > > > by local copy. But this shows similar timings (1:40 vs. 9min). > > > > > > We've discussed this kind of use-case internally as well. The > > > recommendation is to have a designated local master and then do local > > > clones of that. On a unix system if the local clones are on the same > > > disk, hard links are used with a copy-on-write policy so the clones are > > > space-efficient and time-efficient to create. The local clone times > > > we've seen are about 30 seconds in that case. > > > > I would have to run the watchman on all the machines I happen to > > work on. A possible solution imposing work on every user. > > Again, working with local clones does scale. Do you use an SSD on the > machines you are working on? If so, then cloning the consolidated > repository locally shouldn't take more than approx 30 sec. We have approx. 100 servers available. I work on a filer visible on all these. Working on local discs is not an option. First, there is not enough space for everybody on the local disc (especially not for full repos). Second, I need to test my changes on different architectures/oses. Remember, I can not use jprt (Volker said that might be changed, soon, which would be great!). > As for watchman, that is only used to speed up `hg status`, so running > e.g. `hg diff` or `hg status` in a subdirectory as I explained will > yield similar benefits. > > > > > 3.) Having to clone the full repos will require considerably more > > > > disk space. > > > > I'm working on various issues in hotspot and keep them seperated > > > > by doing this in individual repositories that only contain hotspot. > > > > These repos will require considerably more space. > > > > > If disk space is a concern, you can use mq or bookmarks against a single > > > repo. > > > > I use mq a lot. But often for separate tasks separate repos are required. > > Say, I'm working on > > - testing a change of someone other against head revision to review it. > > - developing the s390 port with a mq that contains 10 patches > > - looking for a performance regression by syncing to older revisions, > > building and running benchmarks in a script. > > You can't combine such tasks with a mq in one repo. > > No, but you can with e.g. bookmarks (or branches) and the CONF feature > of the build system. I, for example, have one CONF per bookmark. That > means I can update my code to the feature/bug I'm currently working on, > make some changes, and get an incremental compilation (instead of > rebuilding). > > If you prefer separate repositories, then again, local clones will help Well, to use local clones I first need local 'masters'. If you switch around between 7, 8, 9/hs, 9/dev, 9/client etc, that's already more space for masters than I currently use overall to keep 10 hotspot repos around. > decrease the overhead. If you are open to discussing/sharing your > workflow and trying out some features of Mercurial and the build system, > then I'm confident we can find an effective way for you to work with a > consolidated forest. I guess if you actually merge the repos, I need to change my workflow :) I'll try if the example merged repo is available. > > > > 4.) There will be additional merges because changes that are now done > > > > in two repos will then be done in a single repo. If I then sync back > > > > a few hotspot changes, a lot of files in the other subdirectories > > > > will get touched. This slows down sync and causes rebuilds. > > > > Sure this might just be what is intended, but currently I don't > > > > need to rebuild jdk etc. very often. > > > > > > While hotspot and the rest of the JDK can often be treated as > > > approximately independent, they are not truly independent. > > > > Yes, but they _are_ approximately independent. That suffices to > > avoid lot's of boilerplate work. > > In other SCM systems you can sync back only a subdirectory. > > Mercurial does not support that. > > If I understand, you seem to be working mostly in the hotspot repository > (and sometimes in the top-level)? If that is the case, then you are not > feeling the pain of doing dependent changes between top-level, hotspot > and the jdk. Many other developers feel this pain clearly, particulary > developers working with: > - performance (often require dependent changes in both JDK and hotspot) > - build (often require dependent changes in all repos) > - runtime (the tools in the jdk, e.g. jstat, often require > dependent changes in jdk and hotspot) > - testing (test often needs to be updated in both jdk, hotspot and > top-level) > Furthermore, many of us are interested in all changes going in, because > there might be performance or functional regressions introduced due to > changes in another repository. Having a way to perform a bisect > tremendously helps in those situations. Well I understand all these issues. You could also argue that the Bisect is slower. Before, you could easily do the bisect only on hotspot... until you reach an incompatibility. It drills down to - if you do work in several repos the same time it's better - if you don't, it's not better. > Again, if you mostly work in one repository, then you will not have been > exposed to these problems. However, many developers in the OpenJDK > project tend to work across many repositories. > > > > > 5.) It will get harder to monitor submitted changes that are relevant > > > > for a specific area. E.g., I might only want to see changes in hotspot. > > > > In the web frontend, you can not browse changes on subdirectory > basis. > > > > Maybe this can be solved, as the commandline 'hg log' etc. already > > > support > > > > this. > > > > > > We don't have plans to change the Hg web UI so I think a command line > > > solution would be appropriate here. > > > > You should consider fixing this, maybe as a follow up. You can already > > browse file history, This should be also possible for directories. > > That is a feature request that needs to be sent to the Mercurial > project. The web ui of the OpenJDK repositories comes from the `hg > serve` command, that is not something that Oracle has developed. I know > that Mozilla has awarded a grant to the Mercurial project recently to > improve the web UI [0], the Mercurial developers are probably interested > in this kind of feedback. OK. > > > > 6.) A single repo will simplify making combined changes. So there will be > > > > more of these. But combined changes complicate handling of our > > > > licensed code. > > > > In our activities as licensee, we are consuming hotspot change-wise. > > > > This is because we modified a lot in hotspot, and merging hotspot > > > > changes step by step simplifies the merging. > > > > On the other side, we consume the changes to jdk etc. as chunks. > > > > This is because we changed much less in these directories so > > > > that merging causes less problems. Also, there are much more > > > > changes and we don't have the manpower to consume them > change- > > > wise. > > > > Having combined changes requires more synchronization between > > > > the two merging tasks. It's already an increasing effort in > > > > jdk9. > > > > Also, to follow these two different merging approaches for hotspot > > > > and the rest, we would have to first split the single repo into > > > > two parts. > > > > > > > > > > > > Comments to the JEP: > > > > > > > > I appreciate that the change history is kept as it makes research > > > > in old changes more easy. On the other side, dropping the history > > > > might speed up handling of the new repo. > > > > > > We are aware that Facebook has developed Hg plugins to allow shallow > > > clones, i.e. clones without all the history, but we haven't investigated > > > using them yet. > > > > > > > > > > > I also appreciate the changes in directory layout. If the > > > > repos are merged, this should be done this way. > > > > > > > > We find it difficult to keep the jtreg runner in sync with our > > > > current version of jdk9, especially as we have two of them (We > > > > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and > > > > jdk often differ in a few builds.) > > > > I would appreciate if the runner could be included in the > > > > root/test directory. > > > > > > I'm not quite sure what you are referring to by the jtreg runner. > > > > I mean the code in http://hg.openjdk.java.net/code-tools/jtreg > > > > As Andrew stated, some subdirectories are pretty stable. It > > might completely make sense to merge these into one repository, but I'm > > really concerned about jdk and hotspot. > > > > In general, I think those people that are highly specialized on complex > > subcomponents of the VM will suffer from this. They often are fine > > just working with hotspot / jdk etc.. In general, these people develop > > new components in the latest branch. > > You mean working on tip? The OpenJDK repositories do not make use of > branches (besides having the sole default branch). Sorry, I mean the latest, unreleased Java version. On all the older versions work involving only one repo (hotspot etc) should be really rare. > > Those people that have to maintain and test the VM really will profit > > from the new setup. They anyways always operate with the full > > repo tree. > > Having this said, I think it would make more sense to put the legacy code > > base into merged repos, and not the development branch? > > When you say branch, do you mean "forest" (the wording is important here > for me to understand since branch also in a concept in Mercurial)? That > is, do you think of jdk9/dev, jdk9/hs and jdk9/jdk9 as branches? > > I personally always work with the "full tree" since it is crucial to > develop changes on top of a stable "tree configuration". Even though > hotspot and the jdk ususally are compatible with each other give or take > a few days, there have been plenty of situations where having the > repositories in a non-tested configuration can result in rather funky > behavior. Well, we are running jdk 4 with hotspot from 8u40, and jdk 8 with Hotspot from jdk9b116. Fixing the issues that arise from this is for us much less effort than supporting all the different hotspots we would have. So it's not that bad (once we get it fixed from you :)) > Again, I'm pretty confident that we can find a way for you (and the rest > of the SAP contributors) to work effectively with a consolidated OpenJDK > repository. I just need to learn more about your particular use case to > come up with a nice solution. And you guys of course have to be willing > to change your workflow slightly :) Sure! > Thanks, > Erik > > [0]: https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support- > first-awards-made/ > > > Best regards, > > Goetz. > > > > > > From erik.helin at oracle.com Wed Oct 12 14:48:03 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Oct 2016 16:48:03 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <89999114-826e-dcd3-266d-a1bf5746186d@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <89999114-826e-dcd3-266d-a1bf5746186d@oracle.com> Message-ID: <20161012144803.GJ19291@ehelin.jrpg.bea.com> On 2016-10-11, Weijun Wang wrote: > I am very glad to see history preserved. Is it possible to also merge the > history for src files before modularization and after it with this magical > script? I can call "hg log -f" on the command line but the web interface > only shows partial history. You mean that for example [0] only shows you the history up until the modularization? Sorry, I don't know if this is possible in the Mercurial web interface. The history is there in the repository, but as you've already noticed, the web interface from `hg serve` does not use --follow when showing the history for a file. If you want to reach out to Mercurial upstream and see if it possible to configure this, then you can find them at mercurial at mercurial-scm.org. Thanks, Erik [0]: http://hg.openjdk.java.net/jdk9/dev/jdk/log/138876450c3a/src/java.base/share/classes/java/lang/String.java > > Thanks > Max > > On 10/11/2016 10:11, joe darcy wrote: > >Hello, > > > >Looking ahead to JDK 10, a group of JDK engineers have been exploring > >consolidating the large number of Hg repositories in an open JDK forest > >to a single one with the goal of using the consolidated arrangement for > >JDK 10. > > > >This message is being sent to jdk9-dev since a jdk10-dev alias to > >discuss JDK 10 doesn't exist yet. > > > >A JEP describing the project has been submitted : > > > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > >repository > > https://bugs.openjdk.java.net/browse/JDK-8167368 > > > >The text of the JEP describes the motivation and current state of the > >work in more detail, including proposed changes to the file layout. > >Publication of the prototype consolidated repository is planned, but not > >done yet. The email below has a list of additional anticipated questions > >and answers. > > > >We feel this consolidated arrangement offers some significant structural > >advantages for managing the JDK's source code and we are now asking for > >feedback on this potential change. In particular, if you feel there is a > >show-stopper problem with making this change, please let us know! > > > >I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > >Ingemar Aberg participating in discussions leading up to the prototype > >and I'd like to especially recognize the contributions of Erik Helin for > >savvy Hg manipulations and Erik Joelsson for skillful build wrangling in > >this project. > > > >Please send initial comments by October 18, 2016. > > > >Cheers, > > > >-Joe > > > >Q: What about the set of forests for JDK 10? Are we going to have > >master, dev, client, hotspot, etc. the same set as in 9? > >A: That is a separate question from the repository consolidation, but > >there will likely be simplifications here too. Discussions on that point > >will come later. > > > >Q: I usually just build the code in repo X today. Will I have have to > >build the *whole JDK* now? > >A: Not necessarily. The same top-level build targets should work in the > >consolidated forest. > > > >Q: Does disk usage change? > >A: The total disk usage of the current forest compared to the > >consolidated forest is nearly the same. > > > >Q: In more detail, how were the changesets imported? > >A: The scripts used for the consolidation conversion are attached to the > >JEP. > > > >Q: What happens to the Hg hashes? > >A: The conversion scheme used in the prototype does *not* preserve Hg > >hashes of changesets compared the current forests. However, the bug ids > >are preserved and can be searched for. In addition, one or more > >pre-consolidation forests should be archived in perpetuity so that URLs > >in bug comments continue to work, etc. > > > >A mapping of the old hashes to the corresponding new hashes might be > >generated and placed in the final new repo. > > > >Q: I'm allergic to tabs; what about jcheck? > >A: If history is preserved, the checking done by jcheck needs to be > >modified for the consolidated forest. One way to do this is to augment > >the white lists used in jcheck with the conflicting changesets. This > >approach may not be elegant, but it is effective and doesn't appear to > >appreciably impact jcheck running times. > > > >Q: Will the future 9 update forest also have this consolidation > >restructuring? > >A: The script used to do the consolidation conversion is deterministic > >and could be run to create the 9 update forest in the future at the > >discretion of the 9 update team. > > > >Q: For backports for forwardports, will there be a script to translate > >patch files across the consolidation boundary? > >A: That work is planned, but not yet done; see JDK-8165623: Create patch > >translator to update paths pre/post consolidation. > > > >Q: It's the 21st century and I develop using an IDE. That is still going > >to work, right? > >A: The prototype to date does include updating the various IDE support > >files, but bug JDK-8167142 has been filed to track that work. > > From Roger.Riggs at Oracle.com Wed Oct 12 15:22:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 12 Oct 2016 11:22:41 -0400 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <5346d24f-6f01-191e-a7f4-816c987ba43a@Oracle.com> Vote: yes On 10/11/2016 2:20 PM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. From Roger.Riggs at Oracle.com Wed Oct 12 15:28:33 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 12 Oct 2016 11:28:33 -0400 Subject: CFV: New JDK9 Committer: Michail Chernov In-Reply-To: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> References: <2d59b94b-9a12-ffd3-124c-06dfd9b1eb57@oracle.com> Message-ID: <41073ac9-6841-1562-970f-757244b3f7ec@Oracle.com> Vote: Yes On 9/30/2016 6:34 AM, Dmitry Fazunenko wrote: > I hereby nominate Michail Chernov (mchernov) to JDK 9 Committer. > > From chris.hegarty at oracle.com Wed Oct 12 15:30:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Oct 2016 16:30:13 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <20161012144803.GJ19291@ehelin.jrpg.bea.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <89999114-826e-dcd3-266d-a1bf5746186d@oracle.com> <20161012144803.GJ19291@ehelin.jrpg.bea.com> Message-ID: <9139FFE1-E5A0-4D7A-9A13-9CC8606804F5@oracle.com> > On 12 Oct 2016, at 15:48, Erik Helin wrote: > > On 2016-10-11, Weijun Wang wrote: >> I am very glad to see history preserved. Is it possible to also merge the >> history for src files before modularization and after it with this magical >> script? I can call "hg log -f" on the command line but the web interface >> only shows partial history. > > You mean that for example [0] only shows you the history up until the > modularization? Sorry, I don't know if this is possible in the Mercurial > web interface. The history is there in the repository, but as you've > already noticed, the web interface from `hg serve` does not use --follow > when showing the history for a file. Just to note, in case others may not see it, [0] does contain a link to the ?base? version of the file before the modular source code restructure. It?s a bit of a pain, but you can follow it through the web interface. History is better searched / viewed through a source code indexer, e.g. OpenGrok. -Chris. > If you want to reach out to Mercurial upstream and see if it possible to > configure this, then you can find them at mercurial at mercurial-scm.org. > > Thanks, > Erik > > [0]: > http://hg.openjdk.java.net/jdk9/dev/jdk/log/138876450c3a/src/java.base/share/classes/java/lang/String.java >> >> Thanks >> Max >> >> On 10/11/2016 10:11, joe darcy wrote: >>> Hello, >>> >>> Looking ahead to JDK 10, a group of JDK engineers have been exploring >>> consolidating the large number of Hg repositories in an open JDK forest >>> to a single one with the goal of using the consolidated arrangement for >>> JDK 10. >>> >>> This message is being sent to jdk9-dev since a jdk10-dev alias to >>> discuss JDK 10 doesn't exist yet. >>> >>> A JEP describing the project has been submitted : >>> >>> JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single >>> repository >>> https://bugs.openjdk.java.net/browse/JDK-8167368 >>> >>> The text of the JEP describes the motivation and current state of the >>> work in more detail, including proposed changes to the file layout. >>> Publication of the prototype consolidated repository is planned, but not >>> done yet. The email below has a list of additional anticipated questions >>> and answers. >>> >>> We feel this consolidated arrangement offers some significant structural >>> advantages for managing the JDK's source code and we are now asking for >>> feedback on this potential change. In particular, if you feel there is a >>> show-stopper problem with making this change, please let us know! >>> >>> I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and >>> Ingemar Aberg participating in discussions leading up to the prototype >>> and I'd like to especially recognize the contributions of Erik Helin for >>> savvy Hg manipulations and Erik Joelsson for skillful build wrangling in >>> this project. >>> >>> Please send initial comments by October 18, 2016. >>> >>> Cheers, >>> >>> -Joe >>> >>> Q: What about the set of forests for JDK 10? Are we going to have >>> master, dev, client, hotspot, etc. the same set as in 9? >>> A: That is a separate question from the repository consolidation, but >>> there will likely be simplifications here too. Discussions on that point >>> will come later. >>> >>> Q: I usually just build the code in repo X today. Will I have have to >>> build the *whole JDK* now? >>> A: Not necessarily. The same top-level build targets should work in the >>> consolidated forest. >>> >>> Q: Does disk usage change? >>> A: The total disk usage of the current forest compared to the >>> consolidated forest is nearly the same. >>> >>> Q: In more detail, how were the changesets imported? >>> A: The scripts used for the consolidation conversion are attached to the >>> JEP. >>> >>> Q: What happens to the Hg hashes? >>> A: The conversion scheme used in the prototype does *not* preserve Hg >>> hashes of changesets compared the current forests. However, the bug ids >>> are preserved and can be searched for. In addition, one or more >>> pre-consolidation forests should be archived in perpetuity so that URLs >>> in bug comments continue to work, etc. >>> >>> A mapping of the old hashes to the corresponding new hashes might be >>> generated and placed in the final new repo. >>> >>> Q: I'm allergic to tabs; what about jcheck? >>> A: If history is preserved, the checking done by jcheck needs to be >>> modified for the consolidated forest. One way to do this is to augment >>> the white lists used in jcheck with the conflicting changesets. This >>> approach may not be elegant, but it is effective and doesn't appear to >>> appreciably impact jcheck running times. >>> >>> Q: Will the future 9 update forest also have this consolidation >>> restructuring? >>> A: The script used to do the consolidation conversion is deterministic >>> and could be run to create the 9 update forest in the future at the >>> discretion of the 9 update team. >>> >>> Q: For backports for forwardports, will there be a script to translate >>> patch files across the consolidation boundary? >>> A: That work is planned, but not yet done; see JDK-8165623: Create patch >>> translator to update paths pre/post consolidation. >>> >>> Q: It's the 21st century and I develop using an IDE. That is still going >>> to work, right? >>> A: The prototype to date does include updating the various IDE support >>> files, but bug JDK-8167142 has been filed to track that work. >>> From jonathan.gibbons at oracle.com Wed Oct 12 15:52:24 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Oct 2016 08:52:24 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> Message-ID: <4e404bc6-1e3e-716c-812c-950749f6b7f4@oracle.com> On 10/12/16 12:16 AM, Lindenmaier, Goetz wrote: >>> > >We find it difficult to keep the jtreg runner in sync with our >>> > >current version of jdk9, especially as we have two of them (We >>> > >test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and >>> > >jdk often differ in a few builds.) >>> > >I would appreciate if the runner could be included in the >>> > >root/test directory. >> > >> >I'm not quite sure what you are referring to by the jtreg runner. > I mean the code inhttp://hg.openjdk.java.net/code-tools/jtreg Goetz, What sort of troubles have you been having here? The intent is to provide one version of jtreg that works for all supported JDK versions. Currently, the intent is that jtreg supports running tests on all versions back to JDK 5. That being said, jtreg does advance slowly, and there is a value to identify the minimum required version of jtreg in the test/TEST.ROOT file for each repository that contains jtreg tests. If nothing else, you could use that value to help select a specific version of jtreg, assuming you build/provide multiple versions. I do accept that folk working on the jigsaw/jake forest will sometimes have to use the latest version of jtreg (i.e. tip, not the latest tagged version) but that is part of living and working on "the bleeding edge", and which does not sound like your situation. In short, I think the cost of the logistics to keep jtreg in the main JDK forest, including the need to backport changes, would far outweigh any benefits, especially when there is related concern about the overall size of an aggregate consolidated repo. -- Jon From gnu.andrew at redhat.com Wed Oct 12 16:06:02 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 12 Oct 2016 12:06:02 -0400 (EDT) Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> Message-ID: <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> snip... > > > I would appreciate if the runner could be included in the > > > root/test directory. > > > > I'm not quite sure what you are referring to by the jtreg runner. > > I mean the code in http://hg.openjdk.java.net/code-tools/jtreg > I think the problem with that is that the development of jtreg then becomes tied to OpenJDK. It might be ok for the development version of OpenJDK, but you then have to backport jtreg fixes into update releases, rather than just using the same jtreg from the separate repository. We've experienced that bundling issue with IcedTea, and it's why we split out the plugin/javaws work (IcedTea-Web). > As Andrew stated, some subdirectories are pretty stable. It > might completely make sense to merge these into one repository, but I'm > really concerned about jdk and hotspot. > > In general, I think those people that are highly specialized on complex > subcomponents of the VM will suffer from this. They often are fine > just working with hotspot / jdk etc.. In general, these people develop > new components in the latest branch. > Those people that have to maintain and test the VM really will profit > from the new setup. They anyways always operate with the full > repo tree. > Having this said, I think it would make more sense to put the legacy code > base into merged repos, and not the development branch? > I agree the biggest friction is going to be between HotSpot and the other repositories, much as it was for the build system changes which took an entire OpenJDK release to make it to HotSpot, because the development experience is quite different. The HotSpot repository is still fairly slim and performs well. I get the impression that many HotSpot developers work on that repository in isolation, given their requirements to be able to build from within the repo rather than the top-level. The JDK repository is already experiencing slowdown. It doesn't really work without the top-level repository and the additional components (CORBA, JAXP, JAXWS, Nashorn) are usually needed for a build, even if they are seldom altered. Given the size of the JDK repository already, adding in these components is not going to make a huge difference. Build changes usually end up touching most of the repositories. Merges certainly do. So, yes, the benefits are greatest for those doing build and integration work. I do wonder what percentage of the cross-repo commits touch HotSpot, and whether we could retain that as a separate repository if it's going to cause so much disruption for HS developers. JDK builds can be done using an imported HotSpot and HotSpot developers can use an imported JDK, so I don't see a strong reason to join these together. We've had to swap out HotSpot with one that includes a newer port on several occasions, and having to duplicate all the JDK code in these cases would be a major pain. HotSpot also operates a different commit process which could cause friction if the repos are merged. > Best regards, > Goetz. > > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Oct 12 16:25:43 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 12 Oct 2016 12:25:43 -0400 (EDT) Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> Message-ID: <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> ----- Original Message ----- > snip... > > > > > I would appreciate if the runner could be included in the > > > > root/test directory. > > > > > > I'm not quite sure what you are referring to by the jtreg runner. > > > > I mean the code in http://hg.openjdk.java.net/code-tools/jtreg > > > > I think the problem with that is that the development of jtreg then becomes > tied to OpenJDK. It might be ok for the development version of OpenJDK, but > you then have to backport jtreg fixes into update releases, rather than just > using the same jtreg from the separate repository. > > We've experienced that bundling issue with IcedTea, and it's why we split > out the plugin/javaws work (IcedTea-Web). > > > As Andrew stated, some subdirectories are pretty stable. It > > might completely make sense to merge these into one repository, but I'm > > really concerned about jdk and hotspot. > > > > In general, I think those people that are highly specialized on complex > > subcomponents of the VM will suffer from this. They often are fine > > just working with hotspot / jdk etc.. In general, these people develop > > new components in the latest branch. > > Those people that have to maintain and test the VM really will profit > > from the new setup. They anyways always operate with the full > > repo tree. > > Having this said, I think it would make more sense to put the legacy code > > base into merged repos, and not the development branch? > > > > I agree the biggest friction is going to be between HotSpot and the other > repositories, much as it was for the build system changes which took an > entire OpenJDK release to make it to HotSpot, because the development > experience is quite different. > > The HotSpot repository is still fairly slim and performs well. I get the > impression that many HotSpot developers work on that repository in isolation, > given their requirements to be able to build from within the repo rather than > the top-level. > > The JDK repository is already experiencing slowdown. It doesn't really work > without the top-level repository and the additional components (CORBA, JAXP, > JAXWS, Nashorn) are usually needed for a build, even if they are seldom > altered. > Given the size of the JDK repository already, adding in these components is > not going to make a huge difference. > > Build changes usually end up touching most of the repositories. Merges > certainly > do. So, yes, the benefits are greatest for those doing build and integration > work. > > I do wonder what percentage of the cross-repo commits touch HotSpot, and > whether > we could retain that as a separate repository if it's going to cause so much > disruption for HS developers. > > JDK builds can be done using an imported HotSpot and HotSpot developers can > use an > imported JDK, so I don't see a strong reason to join these together. We've > had to > swap out HotSpot with one that includes a newer port on several occasions, > and > having to duplicate all the JDK code in these cases would be a major pain. > > HotSpot also operates a different commit process which could cause friction > if > the repos are merged. > Further to that, for OpenJDK 8, the relative repo sizes look like this (compressed): -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz The JDK repository, even compressed, is over five times the size of HotSpot. Adding the other repos into the JDK repository thus wouldn't make that much of a difference to it, even if HotSpot is included, whereas it will cause an order of magnitude increase compared to the current side of the HotSpot repositories. I think I'd thus prefer to see it cut down to two repositories. That would give most of the benefits I described of getting rid of all the superfluous repos, without bloating the requirements for HotSpot work. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From philip.race at oracle.com Wed Oct 12 17:10:01 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Oct 2016 10:10:01 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> Message-ID: <9dc7f75c-c56e-5433-8b2b-df95606e3e6e@oracle.com> The funny irony here is that the current arrangement you list below was introduced for JDK7 b23 as part of the open sourcing plan (although nashorn came in later) when we also switched from SCCS+teamware to mercurial. The last build before that - JDK 7 b22 - had just hotspot+j2se as you propose plus a "top-level" repo - (if you ignore the closed repos for the plugin and similar). So what goes around comes around ... but I wonder if anyone remembers the reasoning and advocacy behind splitting it in the first before we spring back to how it was before ? I could probably dig up some old internal emails but not quickly. -phil On 10/12/2016 09:25 AM, Andrew Hughes wrote: > Further to that, for OpenJDK 8, the relative repo sizes look like > this (compressed): > > -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz > -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz > -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz > -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz > -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz > > The JDK repository, even compressed, is over five times the size > of HotSpot. Adding the other repos into the JDK repository thus > wouldn't make that much of a difference to it, even if HotSpot is > included, whereas it will cause an order of magnitude increase compared > to the current side of the HotSpot repositories. > > I think I'd thus prefer to see it cut down to two repositories. That > would give most of the benefits I described of getting rid of all > the superfluous repos, without bloating the requirements for HotSpot work. From Alan.Bateman at oracle.com Wed Oct 12 17:30:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Oct 2016 18:30:36 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <9dc7f75c-c56e-5433-8b2b-df95606e3e6e@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <9dc7f75c-c56e-5433-8b2b-df95606e3e6e@oracle.com> Message-ID: <663df3ad-2454-f960-e429-d2df592b2e80@oracle.com> On 12/10/2016 18:10, Phil Race wrote: > The funny irony here is that the current arrangement you list below > was introduced for > JDK7 b23 as part of the open sourcing plan (although nashorn came in > later) when > we also switched from SCCS+teamware to mercurial. > > The last build before that - JDK 7 b22 - had just hotspot+j2se as you > propose > plus a "top-level" repo - (if you ignore the closed repos for the > plugin and similar). > > So what goes around comes around ... but I wonder if anyone remembers > the reasoning > and advocacy behind splitting it in the first before we spring back to > how it was before ? If I recall correctly then the HotSpot VM could be dropped into an update of an older release at time. A royal PITA when trying to coordinated changes as it meant trying to keep several combinations working at the same time. All in the past now. -Alan From christian.tornqvist at oracle.com Wed Oct 12 17:56:08 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 12 Oct 2016 10:56:08 -0700 (PDT) Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov Message-ID: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. He has made 23 contributions to JDK 9 [3]. Votes are due by Oct 26, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Christian [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b From coleen.phillimore at oracle.com Wed Oct 12 18:03:03 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 12 Oct 2016 14:03:03 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <8d4bcd63-9b81-f169-ee0e-e4f6a7659f5c@oracle.com> Vote: yes On 10/12/16 1:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From vladimir.kozlov at oracle.com Wed Oct 12 18:04:45 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Oct 2016 11:04:45 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <4991b9a5-9c23-b532-baf7-b06233fc5873@oracle.com> Vote: yes On 10/12/16 10:56 AM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From jiangli.zhou at oracle.com Wed Oct 12 18:12:47 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 12 Oct 2016 11:12:47 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <31CFFB7D-BDD8-4831-82F2-3CD21E8BF513@oracle.com> Vote: yes Thanks, Jiangli > On Oct 12, 2016, at 10:56 AM, Christian Tornqvist wrote: > > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From brian.burkhalter at oracle.com Wed Oct 12 18:16:18 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 12 Oct 2016 11:16:18 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <24836D3C-29A7-482A-988A-49BF6765D418@oracle.com> Vote: yes Brian On Oct 12, 2016, at 10:56 AM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. From calvin.cheung at oracle.com Wed Oct 12 18:23:11 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 12 Oct 2016 11:23:11 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <57FE7F8F.50702@oracle.com> Vote: yes On 10/12/16, 10:56 AM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From john.r.rose at oracle.com Wed Oct 12 18:47:09 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Oct 2016 11:47:09 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: yes On Oct 12, 2016, at 10:56 AM, Christian Tornqvist wrote: > > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. From lois.foltan at oracle.com Wed Oct 12 19:02:10 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 12 Oct 2016 15:02:10 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <57FE88B2.4050807@oracle.com> Vote: yes On 10/12/2016 1:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From artem.smotrakov at oracle.com Wed Oct 12 19:15:03 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 12 Oct 2016 15:15:03 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <00eecacf-44e8-0310-96c0-b065bb1fd39f@oracle.com> Vote: yes Artem On 10/12/2016 01:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From karen.kinnear at oracle.com Wed Oct 12 19:18:32 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 12 Oct 2016 15:18:32 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: vote: yes > On Oct 12, 2016, at 1:56 PM, Christian Tornqvist wrote: > > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From lana.steuck at oracle.com Wed Oct 12 20:04:11 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 12 Oct 2016 20:04:11 GMT Subject: jdk9-b140: dev Message-ID: <201610122004.u9CK4BWE008899@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/a5815c6098a2 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/785843878cf7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6842e63d6c39 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e93b7ea55975 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/9004617323fe http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/8d100cb9b048 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fec31089c2ef http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9f3fc931bc23 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8149371 client-libs multi-res. image: -Dsun.java2d.uiScale does not work for Window icons JDK-8150176 client-libs [hidpi] wrong resolution variant of multi-res. image is used for TrayI JDK-8154043 client-libs Fields not reachable anymore by tab-key, because of new tabbing behavi JDK-8155753 client-libs Removing a monitor in the OS dispaly configuration causes assertion fa JDK-8160056 client-libs TextField.setText breaks the contract of EOL JDK-8160160 client-libs The menu displayed nothing with the option"-server -d64 -Xmixed -Dswin JDK-8161910 client-libs [PIT] regression: HW/LW mixing seems broken on Unity JDK-8162531 client-libs solaris.fontconfig.properties needs updating JDK-8162591 client-libs All existing gradient paint implementations have issues with coordinat JDK-8163261 client-libs regression on Linux: java/awt/LightweightDispatcher/LWDispatcherMemory JDK-8164536 client-libs enableSuddenTermination() - Not throws SecurityException if a security JDK-8164931 client-libs Verify if writer.abort() works properly for all writers in IIOWritePro JDK-8165234 client-libs Provide a way to not close toggle menu items on mouse click on compone JDK-8165594 client-libs Bad rendering of Swing UI controls with Windows Classic L&F on HiDPI d JDK-8165619 client-libs Frame is not repainted if created in state=MAXIMIZED_BOTH on Unity JDK-8165717 client-libs [macosx] Various memory leaks in jdk9 JDK-8165829 client-libs Android Studio 2.x crashes with NPE at sun.lwawt.macosx.CAccessibility JDK-8165947 client-libs One more page printed before the test page with OpenJDK JDK-8166015 client-libs [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivatio JDK-8166259 client-libs One more banner page printed before the test page JDK-8166288 client-libs Au file format can be validated better JDK-8166685 client-libs We should unpin stream and pixel buffer in case of setjmp during write JDK-8166981 client-libs RGBColorConvertTest has wrong @run line JDK-8151486 core-libs Class.forName causes memory leak JDK-8159855 core-libs Create an SPI for tools JDK-8164705 core-libs Remove pathname canonicalization from FilePermission JDK-8164814 core-libs Deprecate Atomic*.weakCompareAndSet and defer to Atomic*.weakCompareAn JDK-8165372 core-libs StackWalker performance regression following JDK-8147039 JDK-8165806 core-libs UnicastServerRef support to export an object with a filter JDK-8166045 core-libs jdk/internal/misc/Unsafe tests fail due to timeout JDK-8166501 core-libs compilation error in stackwalk.cpp on some gccs JDK-8166791 core-libs Fix module dependencies for networking component tests JDK-8166875 core-libs (tz) Support tzdata2016g JDK-8167005 core-libs Comment on the need for an empty constructor in ArrayList$Itr JDK-8167018 core-libs Nashorn and jjs should support --module-path and --add-modules options JDK-8167117 core-libs Insert missing "final" keywords in Nashorn sources JDK-8167157 core-libs ant build fails with [javadoc] javadoc: error - Illegal package name: JDK-8167289 core-libs Backport ES6 updates from Graal.js JDK-8167295 core-libs Further cleanup to the native parts of libnet/libnio JDK-8160987 core-svc JDWP ClassType.InvokeMethod doesn't validate class JDK-8161225 core-svc Assert failure in JVMTI GetNamedModule at JPLISAgent.c line: 792 JDK-8080238 deploy JNLP property apple.laf.useScreenMenuBar no longer treated as secure f JDK-8158823 deploy Correct search tab to open the correct tab JDK-8164717 deploy [test] JDK8048972Test::testUpdateIntegrityLevel failed due to unable t JDK-8164991 deploy [test] Tests that loading applet should be filtered out for unsupport JDK-8165763 deploy infoplistScenarios/testInfoplist: test instruction step4 need update JDK-8165764 deploy The applet can't be loaded successfully with Safari browser on MacOS JDK-8165831 deploy At step12,The content contained in 'More Information' dialog is incorr JDK-8165867 deploy [macos] JVM continuously throw a NullPointerException on new MacOS 10. JDK-8165928 deploy At step3:A dialog with title "Desktop Integration Warning" display whe JDK-8166004 deploy [TEST_BUG]At step5,Can not set the Security Level to Very High. JDK-8166408 deploy Intermittent test failure in JNLPClassLoaderTest JDK-8166482 deploy Evaluate relative dimension test failures under javafx/deploy JDK-8166582 deploy LaunchDownloadTest failure after fix for JDK-8165001 JDK-8166602 deploy [test] Some cases in FXOcspAndCrlCheckTest failed on Mac due to gibber JDK-8166605 deploy [test] The expect dialog title string in driver xml is wrong for some JDK-8166774 deploy Filter out applets under fx deploy on unsupported config JDK-8166873 deploy [test] Many javafx cases failed on Ubuntu due to "java.lang.IllegalSta JDK-8033552 hotspot Fix missing missing volatile specifiers in CAS operations in GC code JDK-8078122 hotspot YMM registers upper 128 bits may get clobbered by a JNI call on window JDK-8129376 hotspot SPECjvm98-client performance regression in 9-b66 JDK-8146546 hotspot assert(fr->safe_for_sender(thread)) failed: Safety check JDK-8147943 hotspot jvmti.h generated with GPL header JDK-8150758 hotspot [TESTBUG] need jvmti tests for module aware agents JDK-8154122 hotspot Intrinsify fused mac operations on x86 JDK-8156852 hotspot Convert JSON_test to Gtest JDK-8159818 hotspot Convert IHOP_test to GTest JDK-8161085 hotspot PreserveFPRegistersTest fails with 'AssertionError: Final value has ch JDK-8163969 hotspot Cyclic interface initialization causes JVM crash JDK-8164011 hotspot --patch-module support for CDS JDK-8164482 hotspot [REDO] G1 does not implement millis_since_last_gc which is needed by R JDK-8164508 hotspot unexpected profiling mismatch in c1 generated code JDK-8164852 hotspot Move slow tier1/tier2 runtime tests to later tiers JDK-8164920 hotspot ppc: enhancement of CRC32 intrinsic JDK-8164987 hotspot RTM jtreg tests failing due to unnamed module unable to access class j JDK-8165235 hotspot [TESTBUG] RTM tests must check OS version JDK-8165433 hotspot Convert Test_linked_list to Gtest JDK-8165439 hotspot Convert Test_TempNewSymbol to GTest JDK-8165457 hotspot [JVMCI] increase InterpreterCodeSize for JVMCI JDK-8165537 hotspot runtime/SharedArchiveFile/SASymbolTableTest.java fails with NullPointe JDK-8165565 hotspot Shorten branches causes incorrect code for SKX JDK-8165601 hotspot Convert arrayOopDesc_test to Gtest JDK-8165602 hotspot Convert TestChunkedList_test to GTest JDK-8165613 hotspot Convert TestKlass_test to Gtest JDK-8165755 hotspot [JVMCI] replace use of vm_abort with vm_exit JDK-8165857 hotspot CMS _overflow_list is missing volatile specifiers. JDK-8165858 hotspot heapRegionManager is missing volatile specifier for _claims. JDK-8165860 hotspot WorkGroup classes are missing volatile specifiers for lock-free code JDK-8166046 hotspot [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fail JDK-8166140 hotspot C1: Possible integer overflow in LIRGenerator::generate_address on sev JDK-8166164 hotspot compiler/compilercontrol/share/processors/LogProcessor.java does not c JDK-8166433 hotspot Fix for JDK-8163014 broke Aarch64 build JDK-8166483 hotspot gtest fmw should be updated to support null detection on SS >= 12u4 JDK-8166549 hotspot fix incorrectly @ignore-d hotspot/compiler tests JDK-8166552 hotspot SA: Missed testcase for add default methods to InstanceKlass JDK-8166583 hotspot Add oopDesc::klass_or_null_acquire() JDK-8166663 hotspot Simplify oops_on_card_seq_iterate_careful JDK-8166765 hotspot [ppc] Port "8163014: Mysterious/wrong value for long frame local varia JDK-8166777 hotspot [ppc] port "8164086: Checked JNI pending exception check should be cle JDK-8150736 infrastructure Excessive disk space used by build system JDK-8166096 infrastructure variable tracking size limit exceeded in jvmciCompilerToVM.cpp JDK-8166202 infrastructure Tracefile gensrc cannot handle closed src dir in different location JDK-8166648 infrastructure jib make run-test for langtools results in intermittent failures on wi JDK-8166799 infrastructure ASSEMBLY_EXCEPTION contains historical company name JDK-8163171 install Java Update does not remove older versions JDK-8165101 security-libs AnchorCertificates throws NPE when cacerts file not found JDK-8165103 security-libs Update to "denyAfter constraint check" exception message JDK-8166632 security-libs Document how to grant permissions for a module jrt:/ in the im JDK-8166976 security-libs TestCipherPBECons has wrong @run line JDK-8167181 security-libs Exported elements referring to inaccessible types in jdk.security.jgss JDK-4649116 tools Add option to include full package description at top, before interfac JDK-8072604 tools Improve handling of direct use of accept with TreePathScanner JDK-8151102 tools Cleanup javadoc exception handling JDK-8153362 tools Add javac -Xlint warning to list exposed types which are not accessibl JDK-8154349 tools New doclet incorrectly shows entire text body for JavaFX properties in JDK-8161338 tools (jdeprscan) remove JEP 293 non-conforming -cp option JDK-8162401 tools Support multiple --add-exports and --add-reads with the same module/pa JDK-8165991 tools Fix DocTreeFactory newDocCommentTree JDK-8166472 tools javac/javadoc expands @files incorrectly JDK-8166846 tools jdeps fails to generate module info if there is any class in unnamed p JDK-8166860 tools Add magic number to jmod file JDK-8167014 tools jdeps: Missing message: warn.skipped.entry JDK-8167070 tools Performance regression in compound scopes JDK-8167343 tools JShell: Completeness analysis infers an incomplete declaration as COMP JDK-8139584 xml XMLStreamWriterImpl does not write 'standalone' property JDK-8167002 xml JAXP schema validator: Use HashSet instead of ArrayList for tracking X From daniel.daugherty at oracle.com Wed Oct 12 20:06:44 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Oct 2016 14:06:44 -0600 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: yes Dan On 10/12/16 11:56 AM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > > From dmitry.fazunenko at oracle.com Wed Oct 12 20:11:44 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 12 Oct 2016 23:11:44 +0300 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <902c512a-0f8a-1de0-1bc7-265f79ff68b4@oracle.com> Vote: yes From eric.caspole at oracle.com Wed Oct 12 20:21:52 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 12 Oct 2016 16:21:52 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: yes Regards, Eric On 10/12/2016 1:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From goetz.lindenmaier at sap.com Wed Oct 12 21:17:55 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 12 Oct 2016 21:17:55 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> Message-ID: Hi, I think Andrew has a good point there. Cutting it into two would exactly mirror how we work with the licensee code, and it would help hotspot developers. Thanks Andrew! Best regards, Goetz > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Wednesday, October 12, 2016 6:26 PM > To: Lindenmaier, Goetz > Cc: jdk9-dev at openjdk.java.net > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > > > ----- Original Message ----- > > snip... > > > > > > > I would appreciate if the runner could be included in the > > > > > root/test directory. > > > > > > > > I'm not quite sure what you are referring to by the jtreg runner. > > > > > > I mean the code in http://hg.openjdk.java.net/code-tools/jtreg > > > > > > > I think the problem with that is that the development of jtreg then becomes > > tied to OpenJDK. It might be ok for the development version of OpenJDK, > but > > you then have to backport jtreg fixes into update releases, rather than just > > using the same jtreg from the separate repository. > > > > We've experienced that bundling issue with IcedTea, and it's why we split > > out the plugin/javaws work (IcedTea-Web). > > > > > As Andrew stated, some subdirectories are pretty stable. It > > > might completely make sense to merge these into one repository, but I'm > > > really concerned about jdk and hotspot. > > > > > > In general, I think those people that are highly specialized on complex > > > subcomponents of the VM will suffer from this. They often are fine > > > just working with hotspot / jdk etc.. In general, these people develop > > > new components in the latest branch. > > > Those people that have to maintain and test the VM really will profit > > > from the new setup. They anyways always operate with the full > > > repo tree. > > > Having this said, I think it would make more sense to put the legacy code > > > base into merged repos, and not the development branch? > > > > > > > I agree the biggest friction is going to be between HotSpot and the other > > repositories, much as it was for the build system changes which took an > > entire OpenJDK release to make it to HotSpot, because the development > > experience is quite different. > > > > The HotSpot repository is still fairly slim and performs well. I get the > > impression that many HotSpot developers work on that repository in > isolation, > > given their requirements to be able to build from within the repo rather > than > > the top-level. > > > > The JDK repository is already experiencing slowdown. It doesn't really work > > without the top-level repository and the additional components (CORBA, > JAXP, > > JAXWS, Nashorn) are usually needed for a build, even if they are seldom > > altered. > > Given the size of the JDK repository already, adding in these components is > > not going to make a huge difference. > > > > Build changes usually end up touching most of the repositories. Merges > > certainly > > do. So, yes, the benefits are greatest for those doing build and integration > > work. > > > > I do wonder what percentage of the cross-repo commits touch HotSpot, > and > > whether > > we could retain that as a separate repository if it's going to cause so much > > disruption for HS developers. > > > > JDK builds can be done using an imported HotSpot and HotSpot developers > can > > use an > > imported JDK, so I don't see a strong reason to join these together. We've > > had to > > swap out HotSpot with one that includes a newer port on several occasions, > > and > > having to duplicate all the JDK code in these cases would be a major pain. > > > > HotSpot also operates a different commit process which could cause > friction > > if > > the repos are merged. > > > > Further to that, for OpenJDK 8, the relative repo sizes look like > this (compressed): > > -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz > -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz > -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz > -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz > -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz > > The JDK repository, even compressed, is over five times the size > of HotSpot. Adding the other repos into the JDK repository thus > wouldn't make that much of a difference to it, even if HotSpot is > included, whereas it will cause an order of magnitude increase compared > to the current side of the HotSpot repositories. > > I think I'd thus prefer to see it cut down to two repositories. That > would give most of the benefits I described of getting rid of all > the superfluous repos, without bloating the requirements for HotSpot work. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From serguei.spitsyn at oracle.com Wed Oct 12 22:01:38 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Oct 2016 15:01:38 -0700 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <67c2d4e9-27b7-66b8-d5bb-551127445888@oracle.com> Vote: yes On 10/11/16 11:20, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. From serguei.spitsyn at oracle.com Wed Oct 12 22:02:52 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Oct 2016 15:02:52 -0700 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <461f6279-4bce-2386-42d9-b4d6fab25a81@oracle.com> Vote: yes On 10/12/16 10:56, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. From mikael.vidstedt at oracle.com Wed Oct 12 22:04:14 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 12 Oct 2016 15:04:14 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> Message-ID: > On Oct 12, 2016, at 9:06 AM, Andrew Hughes wrote: > > snip... > >>>> I would appreciate if the runner could be included in the >>>> root/test directory. >>> >>> I'm not quite sure what you are referring to by the jtreg runner. >> >> I mean the code in http://hg.openjdk.java.net/code-tools/jtreg >> > > I think the problem with that is that the development of jtreg then becomes > tied to OpenJDK. It might be ok for the development version of OpenJDK, but > you then have to backport jtreg fixes into update releases, rather than just > using the same jtreg from the separate repository. > > We've experienced that bundling issue with IcedTea, and it's why we split > out the plugin/javaws work (IcedTea-Web). > >> As Andrew stated, some subdirectories are pretty stable. It >> might completely make sense to merge these into one repository, but I'm >> really concerned about jdk and hotspot. >> >> In general, I think those people that are highly specialized on complex >> subcomponents of the VM will suffer from this. They often are fine >> just working with hotspot / jdk etc.. In general, these people develop >> new components in the latest branch. >> Those people that have to maintain and test the VM really will profit >> from the new setup. They anyways always operate with the full >> repo tree. >> Having this said, I think it would make more sense to put the legacy code >> base into merged repos, and not the development branch? >> > > I agree the biggest friction is going to be between HotSpot and the other > repositories, much as it was for the build system changes which took an > entire OpenJDK release to make it to HotSpot, because the development > experience is quite different. > > The HotSpot repository is still fairly slim and performs well. I get the > impression that many HotSpot developers work on that repository in isolation, > given their requirements to be able to build from within the repo rather than > the top-level. FWIW since a few years ago all HotSpot developers at Oracle are effectively required to pull and work with the full set of repos. At the time of the switchover, developers had to spend some time adapting workflows and (wrapper) build scripts, etc. to the new model, but I think it?s fair to say by now that it has been working out really well and that it has over the years meant that many events which would otherwise have been ?flag days? (where incompatible changes need to be made across the JDK/HotSpot boundary), have just been handled like a normal integrations/changes. Extrapolating from lessons learned in the past we have definitely saved ourselves a lot of trouble by not treating the hotspot repo/code as a special case. Somewhat naively I actually think that it also leads to better design and implementation choices, because you don?t have to think twice about making that breaking cross-repo change - if that is the right way to implement it, that is what you do, no need to worry about breaking your colleagues? builds. > The JDK repository is already experiencing slowdown. It doesn't really work > without the top-level repository and the additional components (CORBA, JAXP, > JAXWS, Nashorn) are usually needed for a build, even if they are seldom altered. > Given the size of the JDK repository already, adding in these components is > not going to make a huge difference. > > Build changes usually end up touching most of the repositories. Merges certainly > do. So, yes, the benefits are greatest for those doing build and integration work. Not to mention big, cross-component projects like Lambdas and Jigsaw, projects which are complex enough even without taking repositories etc. into account. > I do wonder what percentage of the cross-repo commits touch HotSpot, and whether > we could retain that as a separate repository if it's going to cause so much > disruption for HS developers. > > JDK builds can be done using an imported HotSpot and HotSpot developers can use an > imported JDK, so I don't see a strong reason to join these together. We've had to > swap out HotSpot with one that includes a newer port on several occasions, and > having to duplicate all the JDK code in these cases would be a major pain. Even after a potential repo consolidation I would expect it to be possible to only (re-)build the hotspot component, without having to necessarily recompile the rest of the JDK (the current build system already supports this). It may also be possible to import/export it into an existing JDK, but it should be noted that we do not in any way guarantee that the end result will work as intended unless the code for the pre-built JDK matches the Hotspot code. As Joe mentions, we have made several potentially breaking changes like that over the last few years - I did at least a couple of breaking changes myself related to the Unsafe cleanup. Cheers, Mikael > > HotSpot also operates a different commit process which could cause friction if > the repos are merged. > >> Best regards, >> Goetz. >> >> >> >> > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > From jonathan.gibbons at oracle.com Wed Oct 12 22:17:54 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Oct 2016 15:17:54 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> Message-ID: <57FEB692.3030707@oracle.com> On 10/12/2016 03:04 PM, Mikael Vidstedt wrote: >> On Oct 12, 2016, at 9:06 AM, Andrew Hughes wrote: >> >> snip... >> >>>>> I would appreciate if the runner could be included in the >>>>> root/test directory. >>>> I'm not quite sure what you are referring to by the jtreg runner. >>> I mean the code in http://hg.openjdk.java.net/code-tools/jtreg >>> >> I think the problem with that is that the development of jtreg then becomes >> tied to OpenJDK. It might be ok for the development version of OpenJDK, but >> you then have to backport jtreg fixes into update releases, rather than just >> using the same jtreg from the separate repository. >> >> We've experienced that bundling issue with IcedTea, and it's why we split >> out the plugin/javaws work (IcedTea-Web). >> >>> As Andrew stated, some subdirectories are pretty stable. It >>> might completely make sense to merge these into one repository, but I'm >>> really concerned about jdk and hotspot. >>> >>> In general, I think those people that are highly specialized on complex >>> subcomponents of the VM will suffer from this. They often are fine >>> just working with hotspot / jdk etc.. In general, these people develop >>> new components in the latest branch. >>> Those people that have to maintain and test the VM really will profit >>> from the new setup. They anyways always operate with the full >>> repo tree. >>> Having this said, I think it would make more sense to put the legacy code >>> base into merged repos, and not the development branch? >>> >> I agree the biggest friction is going to be between HotSpot and the other >> repositories, much as it was for the build system changes which took an >> entire OpenJDK release to make it to HotSpot, because the development >> experience is quite different. >> >> The HotSpot repository is still fairly slim and performs well. I get the >> impression that many HotSpot developers work on that repository in isolation, >> given their requirements to be able to build from within the repo rather than >> the top-level. > > FWIW since a few years ago all HotSpot developers at Oracle are effectively required to pull and work with the full set of repos. At the time of the switchover, developers had to spend some time adapting workflows and (wrapper) build scripts, etc. to the new model, but I think it?s fair to say by now that it has been working out really well and that it has over the years meant that many events which would otherwise have been ?flag days? (where incompatible changes need to be made across the JDK/HotSpot boundary), have just been handled like a normal integrations/changes. Extrapolating from lessons learned in the past we have definitely saved ourselves a lot of trouble by not treating the hotspot repo/code as a special case. Somewhat naively I actually think that it also leads to better design and implementation choices, because you don?t have to think twice about making that breaking cross-repo change - if that is the right way to implement it, that is what you do, no need to worry about breaking your colleagues? builds. > >> The JDK repository is already experiencing slowdown. It doesn't really work >> without the top-level repository and the additional components (CORBA, JAXP, >> JAXWS, Nashorn) are usually needed for a build, even if they are seldom altered. >> Given the size of the JDK repository already, adding in these components is >> not going to make a huge difference. >> >> Build changes usually end up touching most of the repositories. Merges certainly >> do. So, yes, the benefits are greatest for those doing build and integration work. > Not to mention big, cross-component projects like Lambdas and Jigsaw, projects which are complex enough even without taking repositories etc. into account. > >> I do wonder what percentage of the cross-repo commits touch HotSpot, and whether >> we could retain that as a separate repository if it's going to cause so much >> disruption for HS developers. >> >> JDK builds can be done using an imported HotSpot and HotSpot developers can use an >> imported JDK, so I don't see a strong reason to join these together. We've had to >> swap out HotSpot with one that includes a newer port on several occasions, and >> having to duplicate all the JDK code in these cases would be a major pain. > Even after a potential repo consolidation I would expect it to be possible to only (re-)build the hotspot component, without having to necessarily recompile the rest of the JDK (the current build system already supports this). It may also be possible to import/export it into an existing JDK, but it should be noted that we do not in any way guarantee that the end result will work as intended unless the code for the pre-built JDK matches the Hotspot code. As Joe mentions, we have made several potentially breaking changes like that over the last few years - I did at least a couple of breaking changes myself related to the Unsafe cleanup. Ditto from LangTools. Currently, those of us working on the javac and javadoc (in particular) can use a simple Ant script to (re)build just the modules in the langtools/ repo. Yes, it's do at your own risk, and not guaranteed to work, and requires maintenance, but I would expect that such mechanisms will continue to work after the consolidation. > > Cheers, > Mikael > >> HotSpot also operates a different commit process which could cause friction if >> the repos are merged. >> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> >> From vladimir.x.ivanov at oracle.com Wed Oct 12 22:19:59 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 13 Oct 2016 01:19:59 +0300 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 10/12/16 8:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > From joe.darcy at oracle.com Wed Oct 12 22:21:53 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 12 Oct 2016 15:21:53 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FEB692.3030707@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <57FEB692.3030707@oracle.com> Message-ID: <57FEB781.2040004@oracle.com> On 10/12/2016 3:17 PM, Jonathan Gibbons wrote: > > > On 10/12/2016 03:04 PM, Mikael Vidstedt wrote: >>> On Oct 12, 2016, at 9:06 AM, Andrew Hughes >>> wrote: >>> Even after a potential repo consolidation I would expect it to be >>> possible to only (re-)build the hotspot component, without having to >>> necessarily recompile the rest of the JDK (the current build system >>> already supports this). It may also be possible to import/export it >>> into an existing JDK, but it should be noted that we do not in any >>> way guarantee that the end result will work as intended unless the >>> code for the pre-built JDK matches the Hotspot code. As Joe >>> mentions, we have made several potentially breaking changes like >>> that over the last few years - I did at least a couple of breaking >>> changes myself related to the Unsafe cleanup. >> [snip] > > Ditto from LangTools. Currently, those of us working on the javac and > javadoc (in particular) can use a simple Ant script to (re)build just > the modules in the langtools/ repo. Yes, it's do at your own risk, and > not guaranteed to work, and requires maintenance, but I would expect > that such mechanisms will continue to work after the consolidation. Yes, the intention is to allow all the existing build targets to still work post consolidation. Cheers, -Joe From joe.darcy at oracle.com Wed Oct 12 23:15:45 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 12 Oct 2016 16:15:45 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <9d3422912a5948b1bf10c5bd0297b2fa@DEWDFE13DE50.global.corp.sap> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <20161012121604.GC19291@ehelin.jrpg.bea.com> <9d3422912a5948b1bf10c5bd0297b2fa@DEWDFE13DE50.global.corp.sap> Message-ID: <57FEC421.6040203@oracle.com> Hi Goetz, Just a quick comment on one point below... On 10/12/2016 6:57 AM, Lindenmaier, Goetz wrote: > Hi Erik and Joe, > > I added more comments inline below :) > > But to subsume and not discuss my personal work setup: > The planned setup > - is benefitial if your work spans the sub-repos > - imposes overhead if the work concentrates in one sub-repo. > > It moves efforts from > keeping repos in sync / doing spanning changes > to > managing development setups/builds (branches, local clones, CONF). > > Also, I really think it brings mercurial closer to its limits, and you need to > work around these. The basic idea of git and mercurial was to quickly > clone, edit, submit, discard. Not to setup a local master repo and > be your own SCM admin. > > I would hope with this change we are working with Mercurial closer to its limits since historically in OpenJDK we have used Mercurial very far from its limits ;-) For example, in the future I'd like to see more usage of branches and/or bookmarks in JDK development to reduce the need for cloning so many forests, but that is a discussion for another day. Cheers, -Joe From joe.darcy at oracle.com Wed Oct 12 23:24:52 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 12 Oct 2016 16:24:52 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4e404bc6-1e3e-716c-812c-950749f6b7f4@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <4e404bc6-1e3e-716c-812c-950749f6b7f4@oracle.com> Message-ID: <57FEC644.7010806@oracle.com> On 10/12/2016 8:52 AM, Jonathan Gibbons wrote: > > On 10/12/16 12:16 AM, Lindenmaier, Goetz wrote: > >>>> > >We find it difficult to keep the jtreg runner in sync with our >>>> > >current version of jdk9, especially as we have two of them (We >>>> > >test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and >>>> > >jdk often differ in a few builds.) >>>> > >I would appreciate if the runner could be included in the >>>> > >root/test directory. >>> > >>> >I'm not quite sure what you are referring to by the jtreg runner. >> I mean the code inhttp://hg.openjdk.java.net/code-tools/jtreg > > Goetz, > > What sort of troubles have you been having here? The intent is to provide > one version of jtreg that works for all supported JDK versions. Currently, > the intent is that jtreg supports running tests on all versions back > to JDK 5. > > That being said, jtreg does advance slowly, and there is a value to > identify > the minimum required version of jtreg in the test/TEST.ROOT file for each > repository that contains jtreg tests. If nothing else, you could use > that value > to help select a specific version of jtreg, assuming you build/provide > multiple versions. > > I do accept that folk working on the jigsaw/jake forest will sometimes > have > to use the latest version of jtreg (i.e. tip, not the latest tagged > version) but > that is part of living and working on "the bleeding edge", and which does > not sound like your situation. > > In short, I think the cost of the logistics to keep jtreg in the main > JDK forest, > including the need to backport changes, would far outweigh any benefits, > especially when there is related concern about the overall size of an > aggregate > consolidated repo. > I agree with Jon that it is strongly preferable to have jtreg be separate from any particular JDK release since it can be shared among multiple release trains and the development cycle of jtreg is not fundamentally tied to the development cycle of a particular JDK release (although many recent jtreg features have been in support of Jigsaw in 9). Cheers, -Joe From joe.darcy at oracle.com Wed Oct 12 23:44:17 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 12 Oct 2016 16:44:17 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> Message-ID: <57FECAD1.2070702@oracle.com> On 10/12/2016 9:25 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> snip... >> >> [snip] > Further to that, for OpenJDK 8, the relative repo sizes look like > this (compressed): > > -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz > -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz > -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz > -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz > -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz > > The JDK repository, even compressed, is over five times the size > of HotSpot. Adding the other repos into the JDK repository thus > wouldn't make that much of a difference to it, even if HotSpot is > included, whereas it will cause an order of magnitude increase compared > to the current side of the HotSpot repositories. > > I think I'd thus prefer to see it cut down to two repositories. That > would give most of the benefits I described of getting rid of all > the superfluous repos, without bloating the requirements for HotSpot work. Of course a consequence of a hotspot + everything else arrangement be perpetuating the current inability to make atomic HotSpot + JDK changes. Cheers, -Joe From jonathan.gibbons at oracle.com Wed Oct 12 23:53:06 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Oct 2016 16:53:06 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> Message-ID: <57FECCE2.4050907@oracle.com> On 10/12/2016 09:25 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> snip... >> >>>>> I would appreciate if the runner could be included in the >>>>> root/test directory. >>>> I'm not quite sure what you are referring to by the jtreg runner. >>> I mean the code in http://hg.openjdk.java.net/code-tools/jtreg >>> >> I think the problem with that is that the development of jtreg then becomes >> tied to OpenJDK. It might be ok for the development version of OpenJDK, but >> you then have to backport jtreg fixes into update releases, rather than just >> using the same jtreg from the separate repository. >> >> We've experienced that bundling issue with IcedTea, and it's why we split >> out the plugin/javaws work (IcedTea-Web). >> >>> As Andrew stated, some subdirectories are pretty stable. It >>> might completely make sense to merge these into one repository, but I'm >>> really concerned about jdk and hotspot. >>> >>> In general, I think those people that are highly specialized on complex >>> subcomponents of the VM will suffer from this. They often are fine >>> just working with hotspot / jdk etc.. In general, these people develop >>> new components in the latest branch. >>> Those people that have to maintain and test the VM really will profit >>> from the new setup. They anyways always operate with the full >>> repo tree. >>> Having this said, I think it would make more sense to put the legacy code >>> base into merged repos, and not the development branch? >>> >> I agree the biggest friction is going to be between HotSpot and the other >> repositories, much as it was for the build system changes which took an >> entire OpenJDK release to make it to HotSpot, because the development >> experience is quite different. >> >> The HotSpot repository is still fairly slim and performs well. I get the >> impression that many HotSpot developers work on that repository in isolation, >> given their requirements to be able to build from within the repo rather than >> the top-level. >> >> The JDK repository is already experiencing slowdown. It doesn't really work >> without the top-level repository and the additional components (CORBA, JAXP, >> JAXWS, Nashorn) are usually needed for a build, even if they are seldom >> altered. >> Given the size of the JDK repository already, adding in these components is >> not going to make a huge difference. >> >> Build changes usually end up touching most of the repositories. Merges >> certainly >> do. So, yes, the benefits are greatest for those doing build and integration >> work. >> >> I do wonder what percentage of the cross-repo commits touch HotSpot, and >> whether >> we could retain that as a separate repository if it's going to cause so much >> disruption for HS developers. >> >> JDK builds can be done using an imported HotSpot and HotSpot developers can >> use an >> imported JDK, so I don't see a strong reason to join these together. We've >> had to >> swap out HotSpot with one that includes a newer port on several occasions, >> and >> having to duplicate all the JDK code in these cases would be a major pain. >> >> HotSpot also operates a different commit process which could cause friction >> if >> the repos are merged. >> > Further to that, for OpenJDK 8, the relative repo sizes look like > this (compressed): > > -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz > -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz > -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz > -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz > -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz > > The JDK repository, even compressed, is over five times the size > of HotSpot. Adding the other repos into the JDK repository thus > wouldn't make that much of a difference to it, even if HotSpot is > included, whereas it will cause an order of magnitude increase compared > to the current side of the HotSpot repositories. > > I think I'd thus prefer to see it cut down to two repositories. That > would give most of the benefits I described of getting rid of all > the superfluous repos, without bloating the requirements for HotSpot work. For my part, I always preferred a different grouping of repositories, along more functional lines, starting with * hotspot + java.base module + javac * client/desktop/gui code * XML code * nashorn But while I believe that would solve many/most of the problems for "coordinated" updates across hotspot/core-libs/javac, I have to accept it will not solve "the bisect problem", and so I have come to accept the desirability of a single repo. That being said, I do see practical concerns here about working with a single repo, and want to make sure we address all those concerns with reasonable, demonstrable solutions. -- Jon From joe.darcy at oracle.com Thu Oct 13 00:04:00 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 12 Oct 2016 17:04:00 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> Message-ID: <57FECF70.2090308@oracle.com> Hello, On 10/12/2016 2:17 PM, Lindenmaier, Goetz wrote: > Hi, > > I think Andrew has a good point there. > Cutting it into two would exactly mirror how we work > with the licensee code, and it would help hotspot developers. > Thanks Andrew! > > Best regards, > Goetz > Some general comments, there are several hundred engineers regularly making changes to the JDK code base. Those engineers work in a wide variety of different ways, in different source languages (C/C++, Java), with different subsets of the code (just one current repository, changes often crossing repositories), at different rates of pushing changes, etc. Compared to the split repository arrangement today, the consolidated repository does make some kinds of operations easier or more natural and other operations more difficult. The trick is balancing the relative costs and benefits of the two categories of operations of course, which can be subtle [1] and one reason we are asking for feedback to get a better sense of the trade-offs. Conversely, I think it is reasonable for engineers making changes to the JDK to be wiling to offer some flexibility in adjusting established worksflows optimized for the split repositories to accommodate the sort of infrastructure changes being proposed here for a consolidated one. Thanks, -Joe [1] "Norms: How to Measure Size," https://blogs.oracle.com/darcy/entry/norms_how_to_measure_size From Sergey.Bylokhov at oracle.com Thu Oct 13 03:53:00 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 13 Oct 2016 06:53:00 +0300 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FEC421.6040203@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <20161012121604.GC19291@ehelin.jrpg.bea.com> <9d3422912a5948b1bf10c5bd0297b2fa@DEWDFE13DE50.global.corp.sap> <57FEC421.6040203@oracle.com> Message-ID: On 13.10.16 2:15, Joseph D. Darcy wrote: > I would hope with this change we are working with Mercurial closer to > its limits since historically in OpenJDK we have used Mercurial very far > from its limits ;-) > > For example, in the future I'd like to see more usage of branches and/or > bookmarks in JDK development to reduce the need for cloning so many > forests, but that is a discussion for another day. Do we have some performance numbers, how many time hg will spend in the common operations like hg diff, hg st, hg inc, hg out, etc? It will be good to know for example results of the Git, probably it will speedup these usecases? -- Best regards, Sergey. From joe.darcy at oracle.com Thu Oct 13 04:25:08 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 12 Oct 2016 21:25:08 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <20161012121604.GC19291@ehelin.jrpg.bea.com> <9d3422912a5948b1bf10c5bd0297b2fa@DEWDFE13DE50.global.corp.sap> <57FEC421.6040203@oracle.com> Message-ID: On 10/12/2016 8:53 PM, Sergey Bylokhov wrote: > On 13.10.16 2:15, Joseph D. Darcy wrote: >> I would hope with this change we are working with Mercurial closer to >> its limits since historically in OpenJDK we have used Mercurial very far >> from its limits ;-) >> >> For example, in the future I'd like to see more usage of branches and/or >> bookmarks in JDK development to reduce the need for cloning so many >> forests, but that is a discussion for another day. > > Do we have some performance numbers, how many time hg will spend in > the common operations like hg diff, hg st, hg inc, hg out, etc? It > will be good to know for example results of the Git, probably it will > speedup these usecases? > A git migration is well outside the scope of this project and thus not relevant for the issues at hand. Thanks, -Joe From robbin.ehn at oracle.com Thu Oct 13 07:46:10 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 13 Oct 2016 09:46:10 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <22200664-0f87-f2a5-2aa9-1a093daa69a5@oracle.com> I tested this last week, ship it! Thanks to all involved for doing this. /Robbin On 10/11/2016 04:11 AM, joe darcy wrote: > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring consolidating the large number of Hg repositories in an open JDK forest to a single one with the goal > of using the consolidated arrangement for JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the work in more detail, including proposed changes to the file layout. Publication of the prototype > consolidated repository is planned, but not done yet. The email below has a list of additional anticipated questions and answers. > > We feel this consolidated arrangement offers some significant structural advantages for managing the JDK's source code and we are now asking for feedback on this potential > change. In particular, if you feel there is a show-stopper problem with making this change, please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and Ingemar Aberg participating in discussions leading up to the prototype and I'd like to especially > recognize the contributions of Erik Helin for savvy Hg manipulations and Erik Joelsson for skillful build wrangling in this project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have master, dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but there will likely be simplifications here too. Discussions on that point will come later. > > Q: I usually just build the code in repo X today. Will I have have to build the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in the consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the consolidated forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to the JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg hashes of changesets compared the current forests. However, the bug ids are preserved and can be > searched for. In addition, one or more pre-consolidation forests should be archived in perpetuity so that URLs in bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be modified for the consolidated forest. One way to do this is to augment the white lists used in jcheck > with the conflicting changesets. This approach may not be elegant, but it is effective and doesn't appear to appreciably impact jcheck running times. > > Q: Will the future 9 update forest also have this consolidation restructuring? > A: The script used to do the consolidation conversion is deterministic and could be run to create the 9 update forest in the future at the discretion of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate patch files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create patch translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still going to work, right? > A: The prototype to date does include updating the various IDE support files, but bug JDK-8167142 has been filed to track that work. > From harold.seigel at oracle.com Thu Oct 13 12:50:59 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 13 Oct 2016 08:50:59 -0400 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <43f7d773-45be-0783-072c-0a04af4966cc@oracle.com> Vote: yes Harold On 10/12/2016 1:56 PM, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From dmitry.dmitriev at oracle.com Thu Oct 13 12:56:17 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Thu, 13 Oct 2016 15:56:17 +0300 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: <590c633c-3ad9-16f7-4e69-e951b818866a@oracle.com> Vote: yes Dmitry On 12.10.2016 20:56, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > From maurizio.cimadamore at oracle.com Thu Oct 13 13:21:55 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 13 Oct 2016 14:21:55 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> Hi Joe, some comments on this. As my workflow typically involve cloning one langtools repo per each new fix, I'll start with discussing local clones first. Starting with some concrete numbers, I am currently working on 2 forests (jdk 9 and valhalla); between these two forests I currently have ~35 langtools clones (for various prototypes and bug fixes). Also, as I'm working on two machines, I keep them in sync using Unison, a very common sync tool in linux land based on rsync. I have been experimenting with local clones, to see to which degree a local clone could save in terms of space. My findings are that a local clone takes around 800M - which seems consistent with the fact that Mercurial hardlinks the repo files but not the history, which is simply copied. For people like me, working on langtools, that's quite a significant jump in terms of space - a clean langtools repo is around 150M. So, in my specific case, disk usage will jump from 150M * 35 =~ 5G to 800M * 35 =~ 28G (this is a very conservative estimate - since it's assuming that all files are hardlinked, which will not be the case as soon as I start making some changes in the local clones). While this is not a deal breaker in terms of disk spaces (my SSD has 200G in total), it poses serious strain on my ability to do regular syncing/backups. Add to this the fact that most backup/syncing tools explicitly calls out the hardlink case as being problematic. Unison doesn't support them, rsync supports them to some degree, and even some professional backup tools I'm using no do support them (or recommend to do without them anyway). So, local cloning could be a fine solution when working on one machine, but as soon as you start considering back up, you have troubles. For this reasons I will have to consider to change my day to day workflow, and to try and avoid relying on clone as much as I did - which poses issues: for instance, if I keep all my patches in the same repo (by using either MQ or bookmarks) - how do I differentiate between the different IDE projects to work on them? Last but not the least - if the local clone size I'm seeing now (800M) is almost entirely history-driven, and that already accounts for 50% of the total size - doesn't that mean that i.e. in 2-3 years time, the size of the history will trump the size of the files, meaning that the advantages of doing local clones will be smaller and smaller over time? On a separate and more note, it seems to me that this effort is two things at once: * a repo consolidation: use a single repo instead of a forest * a source restructuring Each of the above moves has risks and costs for people in the OpenJDK land. For instance, as discussed above, the repo consolidation might mean significantly change the workflow people use on a daily basis (see above). At the same time, the source restructuring is posing issues for things like builds, IDE support, and the likes. I wonder if it wouldn't be sensible to do the repo restructuring now, where the new repo is simply a consolidated version of the new one; no need to update build scripts to take into account new paths. Then, maybe in the next release (JDK 11), we could attack the source restructuring problem. This way people will have more time to adjust to the big changes that are coming. What do you think? Maurizio On 11/10/16 03:11, joe darcy wrote: > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK > forest to a single one with the goal of using the consolidated > arrangement for JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to > discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the > work in more detail, including proposed changes to the file layout. > Publication of the prototype consolidated repository is planned, but > not done yet. The email below has a list of additional anticipated > questions and answers. > > We feel this consolidated arrangement offers some significant > structural advantages for managing the JDK's source code and we are > now asking for feedback on this potential change. In particular, if > you feel there is a show-stopper problem with making this change, > please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > Ingemar Aberg participating in discussions leading up to the prototype > and I'd like to especially recognize the contributions of Erik Helin > for savvy Hg manipulations and Erik Joelsson for skillful build > wrangling in this project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have > master, dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but > there will likely be simplifications here too. Discussions on that > point will come later. > > Q: I usually just build the code in repo X today. Will I have have to > build the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in > the consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the > consolidated forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to > the JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg > hashes of changesets compared the current forests. However, the bug > ids are preserved and can be searched for. In addition, one or more > pre-consolidation forests should be archived in perpetuity so that > URLs in bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be > generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be > modified for the consolidated forest. One way to do this is to augment > the white lists used in jcheck with the conflicting changesets. This > approach may not be elegant, but it is effective and doesn't appear to > appreciably impact jcheck running times. > > Q: Will the future 9 update forest also have this consolidation > restructuring? > A: The script used to do the consolidation conversion is deterministic > and could be run to create the 9 update forest in the future at the > discretion of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate > patch files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create > patch translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still > going to work, right? > A: The prototype to date does include updating the various IDE support > files, but bug JDK-8167142 has been filed to track that work. > From scolebourne at joda.org Thu Oct 13 14:11:55 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 13 Oct 2016 15:11:55 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: On those few occasions where I have worked with the main OpenJDK repos, it has been painful. But this wasn't because of the separation (which the seemed to be handled fine in the initial setup phase where the scripts clone everything), but because of the performance (hg seems dog-slow to me compared with git, but perhaps it is just a large repo). I note that the linux repo has a split between the current repo and a historic repo, that can be linked using git grafts: http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repository-with-full-history/8130239#8130239 I wonder if there is a similar concept for hg that would allow the repo to be split, removing older history while still allowing it to be pieced together. On the feedback that hotspot is perhaps more separate than the rest, I tend to agree. While there are clearly times where the two projects need to be updated together, hopefully this is regularly rare. I would have thought that the two teams could both work on a branch until the flag day, when it would then just be a simple merge on each repo (speaking it git terminology, hg terminology may differ). In summary, my concern is primarily performance. Its already slow, and this change can only make it slower. Stephen On 11 October 2016 at 03:11, joe darcy wrote: > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK forest to a > single one with the goal of using the consolidated arrangement for JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to discuss > JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the work > in more detail, including proposed changes to the file layout. Publication > of the prototype consolidated repository is planned, but not done yet. The > email below has a list of additional anticipated questions and answers. > > We feel this consolidated arrangement offers some significant structural > advantages for managing the JDK's source code and we are now asking for > feedback on this potential change. In particular, if you feel there is a > show-stopper problem with making this change, please let us know! > > I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and Ingemar > Aberg participating in discussions leading up to the prototype and I'd like > to especially recognize the contributions of Erik Helin for savvy Hg > manipulations and Erik Joelsson for skillful build wrangling in this > project. > > Please send initial comments by October 18, 2016. > > Cheers, > > -Joe > > Q: What about the set of forests for JDK 10? Are we going to have master, > dev, client, hotspot, etc. the same set as in 9? > A: That is a separate question from the repository consolidation, but there > will likely be simplifications here too. Discussions on that point will come > later. > > Q: I usually just build the code in repo X today. Will I have have to build > the *whole JDK* now? > A: Not necessarily. The same top-level build targets should work in the > consolidated forest. > > Q: Does disk usage change? > A: The total disk usage of the current forest compared to the consolidated > forest is nearly the same. > > Q: In more detail, how were the changesets imported? > A: The scripts used for the consolidation conversion are attached to the > JEP. > > Q: What happens to the Hg hashes? > A: The conversion scheme used in the prototype does *not* preserve Hg hashes > of changesets compared the current forests. However, the bug ids are > preserved and can be searched for. In addition, one or more > pre-consolidation forests should be archived in perpetuity so that URLs in > bug comments continue to work, etc. > > A mapping of the old hashes to the corresponding new hashes might be > generated and placed in the final new repo. > > Q: I'm allergic to tabs; what about jcheck? > A: If history is preserved, the checking done by jcheck needs to be modified > for the consolidated forest. One way to do this is to augment the white > lists used in jcheck with the conflicting changesets. This approach may not > be elegant, but it is effective and doesn't appear to appreciably impact > jcheck running times. > > Q: Will the future 9 update forest also have this consolidation > restructuring? > A: The script used to do the consolidation conversion is deterministic and > could be run to create the 9 update forest in the future at the discretion > of the 9 update team. > > Q: For backports for forwardports, will there be a script to translate patch > files across the consolidation boundary? > A: That work is planned, but not yet done; see JDK-8165623: Create patch > translator to update paths pre/post consolidation. > > Q: It's the 21st century and I develop using an IDE. That is still going to > work, right? > A: The prototype to date does include updating the various IDE support > files, but bug JDK-8167142 has been filed to track that work. > From gnu.andrew at redhat.com Thu Oct 13 15:31:37 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 13 Oct 2016 11:31:37 -0400 (EDT) Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FECAD1.2070702@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECAD1.2070702@oracle.com> Message-ID: <1126901321.756093.1476372697042.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 10/12/2016 9:25 AM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> snip... > >> > >> > > [snip] > > > Further to that, for OpenJDK 8, the relative repo sizes look like > > this (compressed): > > > > -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz > > -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz > > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz > > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz > > -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz > > -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz > > -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz > > -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz > > > > The JDK repository, even compressed, is over five times the size > > of HotSpot. Adding the other repos into the JDK repository thus > > wouldn't make that much of a difference to it, even if HotSpot is > > included, whereas it will cause an order of magnitude increase compared > > to the current side of the HotSpot repositories. > > > > I think I'd thus prefer to see it cut down to two repositories. That > > would give most of the benefits I described of getting rid of all > > the superfluous repos, without bloating the requirements for HotSpot work. > > Of course a consequence of a hotspot + everything else arrangement be > perpetuating the current inability to make atomic HotSpot + JDK changes. > Yeah, I'm aware of that. That's why I'm wondering what percentage of cross-repo commits include both HotSpot and some JDK repository. I do take on board the point made elsewhere that they become more likely if they are less problematic. I just think it's going to have a big impact for people working solely on HotSpot and so it needs to be clearly beneficial. > Cheers, > > -Joe > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From joe.darcy at oracle.com Thu Oct 13 17:32:49 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 13 Oct 2016 10:32:49 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> Message-ID: <4fe585ae-c523-9448-b181-d6702be266f3@oracle.com> Hi Maurizio, A partial reply for now... On 10/13/2016 6:21 AM, Maurizio Cimadamore wrote: > Hi Joe, > some comments on this. [snip] > > > On a separate and more note, it seems to me that this effort is > two things at once: > > * a repo consolidation: use a single repo instead of a forest > * a source restructuring > > Each of the above moves has risks and costs for people in the OpenJDK > land. For instance, as discussed above, the repo consolidation might > mean significantly change the workflow people use on a daily basis > (see above). At the same time, the source restructuring is posing > issues for things like builds, IDE support, and the likes. > > I wonder if it wouldn't be sensible to do the repo restructuring now, > where the new repo is simply a consolidated version of the new one; no > need to update build scripts to take into account new paths. Then, > maybe in the next release (JDK 11), we could attack the source > restructuring problem. This way people will have more time to adjust > to the big changes that are coming. > > What do you think? > As a preface, I'm working to get the prototype of the consolidated repository externally visible and hope to have an update within the next few days. The prototype did first combine the repositories such that all the relative paths were the same compared to the root. As I recall, this did require some nonzero updates to the build scripts. The second step was moving the module source directories to a consistent scheme. This required more makefile updates, but those updates have been made and the resulting build successfully compared to a pre-combined, pre-module-directory moved build, one of the recent JDK 9 promoted builds. There is some cleanup work remaining to be done including updates for IDE support and scripts to massage patches across the consolidation boundary. I'm confident the essential remaining work can be completed within the next few weeks. A consolidated repository without the source restructuring feels half-done and internally inconsistent to me. Cheers, -Joe From goetz.lindenmaier at sap.com Thu Oct 13 18:44:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 13 Oct 2016 18:44:58 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FEC644.7010806@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <4e404bc6-1e3e-716c-812c-950749f6b7f4@oracle.com> <57FEC644.7010806@oracle.com> Message-ID: <8abff207151f4875a3ab28365cd8ce3e@DEWDFE13DE50.global.corp.sap> Hi, the problems we encounter with jtreg are not that much that it?s not compatible with tests in 8. It?s not compatible with older builds of 9. It?s a problem to run a new jtreg with an older build of jdk9. Our internal sources of 9 are aprox. 5 months behind and we always test them with an older jtreg. We never now when and to what version we should go if these break. For our openJdk 9 build it?s easy as we build tip, and so jtreg tip should work. Unfortunately I don?t remember the issues we encountered. But looking at the repo ?remove support for acception old-style module system options? would be a candidate. But what kind of bugs are you fixing there you would have to downport to a runner for 8? Bugs that crash the runner? They are rare, aren't they? Best regards, Goetz. From: Joseph D. Darcy [mailto:joe.darcy at oracle.com] Sent: Thursday, October 13, 2016 1:25 AM To: Jonathan Gibbons ; Lindenmaier, Goetz ; jdk9-dev at openjdk.java.net Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 On 10/12/2016 8:52 AM, Jonathan Gibbons wrote: On 10/12/16 12:16 AM, Lindenmaier, Goetz wrote: > > We find it difficult to keep the jtreg runner in sync with our > > current version of jdk9, especially as we have two of them (We > > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and > > jdk often differ in a few builds.) > > I would appreciate if the runner could be included in the > > root/test directory. > > I'm not quite sure what you are referring to by the jtreg runner. I mean the code in http://hg.openjdk.java.net/code-tools/jtreg Goetz, What sort of troubles have you been having here? The intent is to provide one version of jtreg that works for all supported JDK versions. Currently, the intent is that jtreg supports running tests on all versions back to JDK 5. That being said, jtreg does advance slowly, and there is a value to identify the minimum required version of jtreg in the test/TEST.ROOT file for each repository that contains jtreg tests. If nothing else, you could use that value to help select a specific version of jtreg, assuming you build/provide multiple versions. I do accept that folk working on the jigsaw/jake forest will sometimes have to use the latest version of jtreg (i.e. tip, not the latest tagged version) but that is part of living and working on "the bleeding edge", and which does not sound like your situation. In short, I think the cost of the logistics to keep jtreg in the main JDK forest, including the need to backport changes, would far outweigh any benefits, especially when there is related concern about the overall size of an aggregate consolidated repo. I agree with Jon that it is strongly preferable to have jtreg be separate from any particular JDK release since it can be shared among multiple release trains and the development cycle of jtreg is not fundamentally tied to the development cycle of a particular JDK release (although many recent jtreg features have been in support of Jigsaw in 9). Cheers, -Joe From staffan.larsen at oracle.com Thu Oct 13 19:29:27 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 13 Oct 2016 21:29:27 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <1126901321.756093.1476372697042.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECAD1.2070702@oracle.com> <1126901321.756093.1476372697042.JavaMail.zimbra@redhat.com> Message-ID: <4C6E8DA3-7782-4D3A-ACEB-71D63BE861DF@oracle.com> > On 13 Oct 2016, at 17:31, Andrew Hughes wrote: > > > > ----- Original Message ----- >> On 10/12/2016 9:25 AM, Andrew Hughes wrote: >>> >>> ----- Original Message ----- >>>> snip... >>>> >>>> >> >> [snip] >> >>> Further to that, for OpenJDK 8, the relative repo sizes look like >>> this (compressed): >>> >>> -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz >>> -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz >>> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz >>> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz >>> -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz >>> -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz >>> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz >>> -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz >>> >>> The JDK repository, even compressed, is over five times the size >>> of HotSpot. Adding the other repos into the JDK repository thus >>> wouldn't make that much of a difference to it, even if HotSpot is >>> included, whereas it will cause an order of magnitude increase compared >>> to the current side of the HotSpot repositories. >>> >>> I think I'd thus prefer to see it cut down to two repositories. That >>> would give most of the benefits I described of getting rid of all >>> the superfluous repos, without bloating the requirements for HotSpot work. >> >> Of course a consequence of a hotspot + everything else arrangement be >> perpetuating the current inability to make atomic HotSpot + JDK changes. >> > > Yeah, I'm aware of that. That's why I'm wondering what percentage of cross-repo > commits include both HotSpot and some JDK repository. I do take on board the point > made elsewhere that they become more likely if they are less problematic. That percentage is probably small, but for some of us (particularly the group I am working in: serviceability), the percentage is very high. > > I just think it's going to have a big impact for people working solely on HotSpot > and so it needs to be clearly beneficial. As Mikeal said in a different reply, all hotspot engineers within Oracle already work with a full forest since some months back. This has led to some changed workflows, but overall the feedback has been positive. /Staffan > >> Cheers, >> >> -Joe >> > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com ) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net ) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From herve.girod at gmail.com Thu Oct 13 20:35:34 2016 From: herve.girod at gmail.com (Herve Girod) Date: Thu, 13 Oct 2016 22:35:34 +0200 Subject: Problem with the Javadoc Search function (JEP 225) in the latests builds? Message-ID: Hello, I noticed that the Javadoc Search function (JEP 225) works well when using the online html javadoc (for the JDK of JavaFX), but if I download the JDK documentation (or the JavaFX documentation), the Search box never work (even if connected of course) Is it intentional at this stage or is it a bug? I tried this on my work PC (Windows 7 with IE or Firefox), or on my home PC (Windows 10 with the latest Firefox or IE version, but none worked. Herve From jonathan.gibbons at oracle.com Thu Oct 13 20:39:02 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Oct 2016 13:39:02 -0700 Subject: Problem with the Javadoc Search function (JEP 225) in the latests builds? In-Reply-To: References: Message-ID: <57FFF0E6.9040809@oracle.com> On 10/13/2016 01:35 PM, Herve Girod wrote: > Hello, > > I noticed that the Javadoc Search function (JEP 225) works well when using > the online html javadoc (for the JDK of JavaFX), but if I download the JDK > documentation (or the JavaFX documentation), the Search box never work > (even if connected of course) > > Is it intentional at this stage or is it a bug? I tried this on my work PC > (Windows 7 with IE or Firefox), or on my home PC (Windows 10 with the > latest Firefox or IE version, but none worked. > > Herve Known problem: https://bugs.openjdk.java.net/browse/JDK-8166175 -- Jon From bhavesh.x.patel at oracle.com Thu Oct 13 20:39:33 2016 From: bhavesh.x.patel at oracle.com (Bhavesh Patel) Date: Thu, 13 Oct 2016 13:39:33 -0700 Subject: Problem with the Javadoc Search function (JEP 225) in the latests builds? In-Reply-To: References: Message-ID: <57FFF105.3020409@oracle.com> Hi Herve, It is a bug and there is an open issue for it https://bugs.openjdk.java.net/browse/JDK-8166175. Regards, Bhavesh. On 10/13/2016 1:35 PM, Herve Girod wrote: > Hello, > > I noticed that the Javadoc Search function (JEP 225) works well when using > the online html javadoc (for the JDK of JavaFX), but if I download the JDK > documentation (or the JavaFX documentation), the Search box never work > (even if connected of course) > > Is it intentional at this stage or is it a bug? I tried this on my work PC > (Windows 7 with IE or Firefox), or on my home PC (Windows 10 with the > latest Firefox or IE version, but none worked. > > Herve From herve.girod at gmail.com Thu Oct 13 21:07:20 2016 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Thu, 13 Oct 2016 23:07:20 +0200 Subject: Problem with the Javadoc Search function (JEP 225) in the latests builds? In-Reply-To: <57FFF105.3020409@oracle.com> References: <57FFF105.3020409@oracle.com> Message-ID: <78B2DC18-9768-47BD-A525-F070B30DC26E@gmail.com> Sorry, I did not see it... Sent from my iPad > On 13 Oct 2016, at 22:39, Bhavesh Patel wrote: > > Hi Herve, > It is a bug and there is an open issue for it https://bugs.openjdk.java.net/browse/JDK-8166175. > > Regards, > Bhavesh. > >> On 10/13/2016 1:35 PM, Herve Girod wrote: >> Hello, >> >> I noticed that the Javadoc Search function (JEP 225) works well when using >> the online html javadoc (for the JDK of JavaFX), but if I download the JDK >> documentation (or the JavaFX documentation), the Search box never work >> (even if connected of course) >> >> Is it intentional at this stage or is it a bug? I tried this on my work PC >> (Windows 7 with IE or Firefox), or on my home PC (Windows 10 with the >> latest Firefox or IE version, but none worked. >> >> Herve > From joe.darcy at oracle.com Thu Oct 13 23:46:54 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 13 Oct 2016 16:46:54 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <8abff207151f4875a3ab28365cd8ce3e@DEWDFE13DE50.global.corp.sap> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <4e404bc6-1e3e-716c-812c-950749f6b7f4@oracle.com> <57FEC644.7010806@oracle.com> <8abff207151f4875a3ab28365cd8ce3e@DEWDFE13DE50.global.corp.sap> Message-ID: <58001CEE.5030609@oracle.com> Hello, On 10/13/2016 11:44 AM, Lindenmaier, Goetz wrote: > > Hi, > > the problems we encounter with jtreg are not that much that it?s not > > compatible with tests in 8. It?s not compatible with older builds > > of 9. > > It?s a problem to run a new jtreg with an older build of jdk9. > > Our internal sources of 9 are aprox. 5 months behind and we always > > test them with an older jtreg. > > We never now when and to what version we should go if these break. > > For our openJdk 9 build it?s easy as we build tip, and so jtreg tip > should work. > > Unfortunately I don?t remember the issues we encountered. But looking > at the > > repo ?remove support for acception old-style module system options? would > > be a candidate. > > But what kind of bugs are you fixing there you would have to downport > > to a runner for 8? Bugs that crash the runner? They are rare, aren't > they? > > FYI, in the roots of the regression tests in the TEST.ROOT files, there is an entry like requiredVersion=4.2 b03 which means that jtreg 4.2 b03 or later needs to be used. If you are running to problems with jtreg on JDK 9, I suggest using the exact version listed in the TEST.ROOT file. HTH, -Joe From joe.darcy at oracle.com Fri Oct 14 01:34:24 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 13 Oct 2016 18:34:24 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <1126901321.756093.1476372697042.JavaMail.zimbra@redhat.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECAD1.2070702@oracle.com> <1126901321.756093.1476372697042.JavaMail.zimbra@redhat.com> Message-ID: <58003620.3050203@oracle.com> On 10/13/2016 8:31 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> On 10/12/2016 9:25 AM, Andrew Hughes wrote: >>> ----- Original Message ----- [snip] >> Of course a consequence of a hotspot + everything else arrangement be >> perpetuating the current inability to make atomic HotSpot + JDK changes. >> > Yeah, I'm aware of that. That's why I'm wondering what percentage of cross-repo > commits include both HotSpot and some JDK repository. I do take on board the point > made elsewhere that they become more likely if they are less problematic. > > I just think it's going to have a big impact for people working solely on HotSpot > and so it needs to be clearly beneficial. > I generated a list of the ~800 reused bug ids in the open forest. Unfortunately, JBS was not very happy processing a "id in ()" query. I'll see if I can use different techniques to do some analysis of the data. As previously noted, the reused bugs ids are just lower bound on the count of logical fixes which spans repos since some engineers, including myself, opt to push logically the same fix to different repos under different bug ids. -Joe From joe.darcy at oracle.com Fri Oct 14 01:44:17 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 13 Oct 2016 18:44:17 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FECCE2.4050907@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECCE2.4050907@oracle.com> Message-ID: <58003871.2030108@oracle.com> Hi Jon, On 10/12/2016 4:53 PM, Jonathan Gibbons wrote: > > > On 10/12/2016 09:25 AM, Andrew Hughes wrote: >> >> ----- Original Message ----- >>> snip... >> [snip] > > > For my part, I always preferred a different grouping of repositories, > along more > functional lines, starting with > > * hotspot + java.base module + javac > * client/desktop/gui code > * XML code > * nashorn > > But while I believe that would solve many/most of the problems for > "coordinated" updates > across hotspot/core-libs/javac, I have to accept it will not solve > "the bisect problem", > and so I have come to accept the desirability of a single repo. > > That being said, I do see practical concerns here about working with a > single repo, and > want to make sure we address all those concerns with reasonable, > demonstrable > solutions. > I agree the set of source code of a minimum consolidated repository, one able to compile and run itself, would be close to hotspot + java.base module + javac, but addressing other concerns draws in the rest of the forest. The proposal was sent out for discussion (and soon the prototype for inspection) precisely to help flush out such practical problems a revised repo arrangement would present. Thanks to you and others who have sent feedback on such points already. Cheers, -Joe From dlloyd at redhat.com Fri Oct 14 06:18:18 2016 From: dlloyd at redhat.com (David Lloyd) Date: Fri, 14 Oct 2016 02:18:18 -0400 (EDT) Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FECCE2.4050907@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECCE2.4050907@oracle.com> Message-ID: <248EDBFD-C8C4-4C1E-A703-C55967F64408@redhat.com> One small additional consideration: a consolidated repository makes it considerably easier to maintain a git mirror (something I do today via some fairly horrific scripts) or even move to git or another SCM in the future. -- - DML > On Oct 13, 2016, at 01:53, Jonathan Gibbons wrote: > > > >> On 10/12/2016 09:25 AM, Andrew Hughes wrote: >> >> ----- Original Message ----- >>> snip... >>> >>>>>> I would appreciate if the runner could be included in the >>>>>> root/test directory. >>>>> I'm not quite sure what you are referring to by the jtreg runner. >>>> I mean the code in http://hg.openjdk.java.net/code-tools/jtreg >>>> >>> I think the problem with that is that the development of jtreg then becomes >>> tied to OpenJDK. It might be ok for the development version of OpenJDK, but >>> you then have to backport jtreg fixes into update releases, rather than just >>> using the same jtreg from the separate repository. >>> >>> We've experienced that bundling issue with IcedTea, and it's why we split >>> out the plugin/javaws work (IcedTea-Web). >>> >>>> As Andrew stated, some subdirectories are pretty stable. It >>>> might completely make sense to merge these into one repository, but I'm >>>> really concerned about jdk and hotspot. >>>> >>>> In general, I think those people that are highly specialized on complex >>>> subcomponents of the VM will suffer from this. They often are fine >>>> just working with hotspot / jdk etc.. In general, these people develop >>>> new components in the latest branch. >>>> Those people that have to maintain and test the VM really will profit >>>> from the new setup. They anyways always operate with the full >>>> repo tree. >>>> Having this said, I think it would make more sense to put the legacy code >>>> base into merged repos, and not the development branch? >>>> >>> I agree the biggest friction is going to be between HotSpot and the other >>> repositories, much as it was for the build system changes which took an >>> entire OpenJDK release to make it to HotSpot, because the development >>> experience is quite different. >>> >>> The HotSpot repository is still fairly slim and performs well. I get the >>> impression that many HotSpot developers work on that repository in isolation, >>> given their requirements to be able to build from within the repo rather than >>> the top-level. >>> >>> The JDK repository is already experiencing slowdown. It doesn't really work >>> without the top-level repository and the additional components (CORBA, JAXP, >>> JAXWS, Nashorn) are usually needed for a build, even if they are seldom >>> altered. >>> Given the size of the JDK repository already, adding in these components is >>> not going to make a huge difference. >>> >>> Build changes usually end up touching most of the repositories. Merges >>> certainly >>> do. So, yes, the benefits are greatest for those doing build and integration >>> work. >>> >>> I do wonder what percentage of the cross-repo commits touch HotSpot, and >>> whether >>> we could retain that as a separate repository if it's going to cause so much >>> disruption for HS developers. >>> >>> JDK builds can be done using an imported HotSpot and HotSpot developers can >>> use an >>> imported JDK, so I don't see a strong reason to join these together. We've >>> had to >>> swap out HotSpot with one that includes a newer port on several occasions, >>> and >>> having to duplicate all the JDK code in these cases would be a major pain. >>> >>> HotSpot also operates a different commit process which could cause friction >>> if >>> the repos are merged. >>> >> Further to that, for OpenJDK 8, the relative repo sizes look like >> this (compressed): >> >> -rw-r--r-- 1 andrew users 918K Aug 7 18:20 corba.tar.xz >> -rw-r--r-- 1 andrew users 6.5M Aug 7 18:22 hotspot.tar.xz >> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxp.tar.xz >> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:21 jaxws.tar.xz >> -rw-r--r-- 1 andrew users 38M Aug 7 18:23 jdk.tar.xz >> -rw-r--r-- 1 andrew users 2.0M Aug 7 18:21 langtools.tar.xz >> -rw-r--r-- 1 andrew users 2.2M Aug 7 18:25 nashorn.tar.xz >> -rw-r--r-- 1 andrew users 327K Aug 7 18:20 openjdk.tar.xz >> >> The JDK repository, even compressed, is over five times the size >> of HotSpot. Adding the other repos into the JDK repository thus >> wouldn't make that much of a difference to it, even if HotSpot is >> included, whereas it will cause an order of magnitude increase compared >> to the current side of the HotSpot repositories. >> >> I think I'd thus prefer to see it cut down to two repositories. That >> would give most of the benefits I described of getting rid of all >> the superfluous repos, without bloating the requirements for HotSpot work. > > > For my part, I always preferred a different grouping of repositories, along more > functional lines, starting with > > * hotspot + java.base module + javac > * client/desktop/gui code > * XML code > * nashorn > > But while I believe that would solve many/most of the problems for "coordinated" updates > across hotspot/core-libs/javac, I have to accept it will not solve "the bisect problem", > and so I have come to accept the desirability of a single repo. > > That being said, I do see practical concerns here about working with a single repo, and > want to make sure we address all those concerns with reasonable, demonstrable > solutions. > > -- Jon From weijun.wang at oracle.com Fri Oct 14 14:03:11 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 14 Oct 2016 22:03:11 +0800 Subject: FilePermission change in jdk-9+140 Message-ID: Hi All If you use a security manager and file permissions then read on. The following changeset is included in jdk-9+140: 8164705: Remove pathname canonicalization from FilePermission http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4251b451be17 This code change removes pathname canonicalization from FilePermission creation, thus calculations of the equals() and implies() methods will be based on the raw path string one provides in "new FilePermission(path, action)". The new behavior is described as @implNote at various places in http://download.java.net/java/jdk9/docs/api/java/io/FilePermission.html We do this mainly for performance enhancement so that there is no need to consult the file system every time a FilePermisson is created. This means FilePermissions on the following pathnames will be unrelated: 1. On "./file" and "/path/to/current/directory/file". 2. On symlink and its target. 3. On "C:\Program Files" and "C:\PROGRA~1" on Windows. and any other name change that a canonicalization can make. Please note that the new FilePermission implementation is based on NIO Path, and Path happens to understand case-sensitiveness and various other things, so there is no need to worry about "C:\PATH" and "c:\path" on Windows or abundant ./down/.. on all platforms. That said, this changeset also adds a compatibility layer at the permission check level to translate between an absolute pathname and a relative one. So, even if FilePermission on a relative path does not imply one on an absolute path pointing to the same file, when you grant a permission in a relative pathname, you are still allowed to read the file with an absolute pathname. This compatibility layer covers these cases: 1. When a permission is granted in a policy file. 2. When a permission is automatically granted because it's on a path where the class files are stored. 3. When a permission is requested in a doPrivileged-with-permissions call We do hope that whenever you want to access a file, the permission you granted in a policy would be better to match the pathname you use to access the file. For example, if you plan to call 'new FileInputStream("/home/me/x")', please also grant FilePermission on "/home/me/x" instead of just "x". Please note the compatibility layer does NOT cover: 1. A user-defined security manager or policy implementation, because we cannot control it. (Not always, but you need to test). 2. The translation between a symlink and its target, because it needs to read the file system. 3. The translation between a Windows long file name and its DOS-8.3 shorted name, because it needs to read the file system. Also, "/-" does not imply "./file" even if it's a Unix. Please use "<>" instead. Finally, if you cannot live with this new behavior and like the pre-jdk9 style, you can always set the system property jdk.io.permissionsUseCanonicalPath back to true. Thanks Max From brian.goetz at oracle.com Fri Oct 14 17:03:43 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 14 Oct 2016 13:03:43 -0400 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <57FECF70.2090308@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> Message-ID: <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> > Conversely, I think it is reasonable for engineers making changes to > the JDK to be wiling to offer some flexibility in adjusting > established worksflows optimized for the split repositories to > accommodate the sort of infrastructure changes being proposed here for > a consolidated one. Let me amplify this: OpenJDK developers are not the only stakeholders here. By aligning more with the way the rest of the world develops -- all code in one linearized, transactionally updated repo -- it increases the feasibility / reduces the cost of tools like 'bisect' to determine where a fault was introduced. This reduces SQE costs and increases product quality -- something we all have a stake in. David Lloyd has pointed up other tooling-related benefits, such as making it easier to maintain a git mirror. Most of the objections raised so far have been "(I think they will) make my life harder." Fair enough; people should be their own advocates. But let's not forget the significant benefits that accrue to *everyone* as a result, and keep those in mind when judging the pros and cons. From joe.darcy at oracle.com Fri Oct 14 18:44:54 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 14 Oct 2016 11:44:54 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> Message-ID: On 10/14/2016 10:03 AM, Brian Goetz wrote: > >> Conversely, I think it is reasonable for engineers making changes to >> the JDK to be wiling to offer some flexibility in adjusting >> established worksflows optimized for the split repositories to >> accommodate the sort of infrastructure changes being proposed here >> for a consolidated one. > > Let me amplify this: OpenJDK developers are not the only stakeholders > here. By aligning more with the way the rest of the world develops > -- all code in one linearized, transactionally updated repo -- it > increases the feasibility / reduces the cost of tools like 'bisect' to > determine where a fault was introduced. This reduces SQE costs and > increases product quality -- something we all have a stake in. David > Lloyd has pointed up other tooling-related benefits, such as making it > easier to maintain a git mirror. > > Most of the objections raised so far have been "(I think they will) > make my life harder." Fair enough; people should be their own > advocates. But let's not forget the significant benefits that accrue > to *everyone* as a result, and keep those in mind when judging the > pros and cons. > Another forward-looking consideration is what kinds of changes do we want to encourage or make easier in evolving the JDK? In absolute percentages, cross-repository changes are relatively uncommon compared to the total number of bug fixes, in part because of the complications of doing them. However, those cross-repository fixes also have the potential to be very high-leverage changes. Multiple JDK 9 features large and small have made such repo-crossing changes, ranging from Jigsaw on the high-end to smaller features such as using indify for string concatenation (JEP 280) and VarHandles (JEP 193). I think we should expect and encourage more features like this in the future. The logistics for some other relatively simple changes like adding a new javac warning would be greatly eased by having a unified repository. Cheers, -Joe From anthony.vanelverdinghe at gmail.com Fri Oct 14 20:10:37 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 14 Oct 2016 22:10:37 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> Message-ID: <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> Hi While I'm not an OpenJDK committer (yet, hope to become so one fine day), I believe this is a great initiative. Since several people have raised concerns related to the increased repository size, I just wanted to point out that both Facebook and Mozilla work with Mercurial repositories which dwarf a typical OpenJDK repository. For example, a clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev is less than 1 GB. There are also several Mercurial extensions which may prove to be useful for people having to work with large repositories and/or adapt their workflows. During their work to scale Mercurial [2], Facebook contributed/made several extensions, such as fsmonitor as mentioned by Joe [3], and the ones in their BitBucket repository [4], such as remotefilelog [5]. When working with local clones, the share extension may be helpful [6]. Finally, note that mq is "often considered for deprecation", so this may be an opportunity to adopt "modern tools, such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. Kind regards, Anthony [1] https://hg.mozilla.org/mozilla-central/ [2] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/004990.html [4] https://bitbucket.org/facebook/hg-experimental [5] https://bitbucket.org/facebook/hg-experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilelog/?at=default [6] https://www.mercurial-scm.org/wiki/ShareExtension [7] https://www.mercurial-scm.org/wiki/MqExtension On 14/10/2016 19:03, Brian Goetz wrote: > >> Conversely, I think it is reasonable for engineers making changes to >> the JDK to be wiling to offer some flexibility in adjusting >> established worksflows optimized for the split repositories to >> accommodate the sort of infrastructure changes being proposed here >> for a consolidated one. > > Let me amplify this: OpenJDK developers are not the only stakeholders > here. By aligning more with the way the rest of the world develops > -- all code in one linearized, transactionally updated repo -- it > increases the feasibility / reduces the cost of tools like 'bisect' to > determine where a fault was introduced. This reduces SQE costs and > increases product quality -- something we all have a stake in. David > Lloyd has pointed up other tooling-related benefits, such as making it > easier to maintain a git mirror. > > Most of the objections raised so far have been "(I think they will) > make my life harder." Fair enough; people should be their own > advocates. But let's not forget the significant benefits that accrue > to *everyone* as a result, and keep those in mind when judging the > pros and cons. > > > From joe.darcy at oracle.com Fri Oct 14 22:40:22 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 14 Oct 2016 15:40:22 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 -- prototype repo now on hg.openjdk.java.net In-Reply-To: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> Message-ID: On 10/10/2016 7:11 PM, joe darcy wrote: > Hello, > > Looking ahead to JDK 10, a group of JDK engineers have been exploring > consolidating the large number of Hg repositories in an open JDK > forest to a single one with the goal of using the consolidated > arrangement for JDK 10. > > This message is being sent to jdk9-dev since a jdk10-dev alias to > discuss JDK 10 doesn't exist yet. > > A JEP describing the project has been submitted : > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > repository > https://bugs.openjdk.java.net/browse/JDK-8167368 > > The text of the JEP describes the motivation and current state of the > work in more detail, including proposed changes to the file layout. > Publication of the prototype consolidated repository is planned, but > not done yet. [snip] The prototype is now available from http://hg.openjdk.java.net/jdk9/consol-proto/ As implied by the tags, at present the prototype should be functionally equivalent to jdk-9+138. Enjoy, -Joe From ivan.gerasimov at oracle.com Sat Oct 15 20:24:14 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Oct 2016 23:24:14 +0300 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: Vote: Yes On 11.10.2016 21:20, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. > > Artem is a member of the Java SE Security Libraries team at Oracle and > has been an active and productive JDK 9 Committer. He has contributed > 64 changesets [3, 4] to the JDK 9 Project. > > Votes are due by 25 October 2016, 8:00 PM UTC. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/search/?rev=author%28%22asmotrak%22%29&revcount=60 > [4] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?rev=artem.smotrakov%40oracle.com > From ivan.gerasimov at oracle.com Sat Oct 15 20:41:22 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Oct 2016 23:41:22 +0300 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: Yes On 12.10.2016 20:56, Christian Tornqvist wrote: > I hereby nominate Mikhailo Seledtsov (mseledtsov) to JDK 9 Committer. > > Mikhailo is currently a JDK 9 Author and a member of the Hotspot Runtime team at Oracle. > He has made 23 contributions to JDK 9 [3]. > > Votes are due by Oct 26, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Christian > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk9/hs/hotspot/log?revcount=1000&rev=%28keyword%28%22mikhailo.seledtsov%40oracle.com%22%29+or+author%28mseledtsov%29%29+and+not+desc%28%22Merge%22%29 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/24b753d90c4b > > From dmitry.fazunenko at oracle.com Mon Oct 17 07:14:08 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 17 Oct 2016 10:14:08 +0300 Subject: Result: New JDK9 Committer: Michail Chernov Message-ID: <7096b7ec-b5a7-c2a3-324a-384000c50215@oracle.com> Voting for Michail Chernov (mchernov) is now closed [1]. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best regards, Dmitry [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004958.html From goetz.lindenmaier at sap.com Mon Oct 17 10:10:27 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Oct 2016 10:10:27 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> Message-ID: Hi Anthony and Joe, > such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. I understand how these commands replace hg queues. I don't understand how they replace having several clones to do something like this: - Change 1 is compiling (in clone 1) - Debugging change 2 (in clone 2) - I get a review and want to immediately edit change 3 (in clone 3), without invalidating the sources I stepped in the debugging session and without canceling the builds. If I use a single clone, I can have these three changes in three branches, or in several sequential changes (like a mercurial queue) I keep reordering with histedit. But as there is only one source tree I can only work on one of the changes at a time. Hg share will do this job I assume. I have been looking at the consol-proto: hg clone takes 30 minutes. Before, get_source.sh took 20 mins. Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. The full repo requires 1.9G. A 'hg share' repo requires 0.6G A hotspot repo before required 0.2G. I will be able to live with this using modern, slower functionality ;) But it imposes a considerable overhead in hardware, tool runtime and administration on my side. Best regards, Goetz. Can I check out several > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Anthony Vanelverdinghe > Sent: Freitag, 14. Oktober 2016 22:11 > To: jdk9-dev at openjdk.java.net > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > Hi > > While I'm not an OpenJDK committer (yet, hope to become so one fine > day), I believe this is a great initiative. Since several people have > raised concerns related to the increased repository size, I just wanted > to point out that both Facebook and Mozilla work with Mercurial > repositories which dwarf a typical OpenJDK repository. For example, a > clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev is > less than 1 GB. > > There are also several Mercurial extensions which may prove to be useful > for people having to work with large repositories and/or adapt their > workflows. > During their work to scale Mercurial [2], Facebook contributed/made > several extensions, such as fsmonitor as mentioned by Joe [3], and the > ones in their BitBucket repository [4], such as remotefilelog [5]. > When working with local clones, the share extension may be helpful [6]. > Finally, note that mq is "often considered for deprecation", so this may > be an opportunity to adopt "modern tools, such as hg rebase, hg > histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. > > Kind regards, > Anthony > > [1] https://hg.mozilla.org/mozilla-central/ > [2] > https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- > facebook/ > [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > October/004990.html > [4] https://bitbucket.org/facebook/hg-experimental > [5] > https://bitbucket.org/facebook/hg- > experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel > og/?at=default > [6] https://www.mercurial-scm.org/wiki/ShareExtension > [7] https://www.mercurial-scm.org/wiki/MqExtension > > On 14/10/2016 19:03, Brian Goetz wrote: > > > >> Conversely, I think it is reasonable for engineers making changes to > >> the JDK to be wiling to offer some flexibility in adjusting > >> established worksflows optimized for the split repositories to > >> accommodate the sort of infrastructure changes being proposed here > >> for a consolidated one. > > > > Let me amplify this: OpenJDK developers are not the only stakeholders > > here. By aligning more with the way the rest of the world develops > > -- all code in one linearized, transactionally updated repo -- it > > increases the feasibility / reduces the cost of tools like 'bisect' to > > determine where a fault was introduced. This reduces SQE costs and > > increases product quality -- something we all have a stake in. David > > Lloyd has pointed up other tooling-related benefits, such as making it > > easier to maintain a git mirror. > > > > Most of the objections raised so far have been "(I think they will) > > make my life harder." Fair enough; people should be their own > > advocates. But let's not forget the significant benefits that accrue > > to *everyone* as a result, and keep those in mind when judging the > > pros and cons. > > > > > > From daniel.fuchs at oracle.com Mon Oct 17 10:40:41 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 17 Oct 2016 11:40:41 +0100 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <5832a18e-f808-4650-465f-9cdf5ac4dc3d@oracle.com> Vote: yes cheers, -- daniel On 11/10/16 19:20, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. From erik.helin at oracle.com Mon Oct 17 11:41:40 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 17 Oct 2016 13:41:40 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> Message-ID: <20161017114140.GU19291@ehelin.jrpg.bea.com> On 2016-10-17, Lindenmaier, Goetz wrote: > Hi Anthony and Joe, > > > such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. > I understand how these commands replace hg queues. > I don't understand how they replace having several > clones to do something like this: > - Change 1 is compiling (in clone 1) > - Debugging change 2 (in clone 2) > - I get a review and want to immediately edit change 3 (in clone 3), without > invalidating the sources I stepped in the debugging session and without > canceling the builds. I would recommend two similar but slighty different workflows for this: - local clones (as previously discussed). One local clone per feature/bug/review/debugging-session. - shares, using `hg share` and bookmarks. One bookmark in each hg share. > If I use a single clone, I can have these three changes in three branches, > or in several sequential changes (like a mercurial queue) I keep reordering with > histedit. But as there is only one source tree I can only work on one of > the changes at a time. > Hg share will do this job I assume. > > I have been looking at the consol-proto: The timings seems an order of magnitude off? What kind of machine are you using? See inline for my measurements, all done on a 1 year old Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg version 3.8.1. > hg clone takes 30 minutes. Before, get_source.sh took 20 mins. $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto requesting all changes adding changesets adding manifests adding file changes added 41157 changesets with 358201 changes to 148305 files updating to branch default 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved real 17m42.057s user 4m37.156s sys 0m41.153s The time for the remote clone will depend mostly on yours (and Oracle's) network. The amount of bits that needs to be transferred are almost the same (differs on a few MB IIRC) compared to a forest. The difference is that the forest downloads the metadata for multiple repositories in parallel. I know you find it cumbersome, but my recommendation here would be to not clone that often from the remote servers. Since mercurial is a DVCS, you already have most of the bits locally on your machine if you've already cloned once. > Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto $ time hg share --bookmarks consol-proto share updating working directory 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved real 0m7.528s user 0m28.442s sys 0m9.791s I have no idea why it takes 5 (or even 3) minutes on your machine? > Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto $ cd consol-proto/src/hotspot/ $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr04/hotspot.changeset $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent $ time hg diff M src/hotspot/os/linux/vm/os_linux.cpp M src/hotspot/share/tools/hsdis/hsdis.c M src/hotspot/share/vm/code/codeCache.cpp M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp M src/hotspot/share/vm/runtime/globals.hpp M src/hotspot/share/vm/runtime/vm_version.cpp M src/hotspot/share/vm/utilities/macros.hpp ? src/hotspot/hotspot.changeset ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig ? src/hotspot/share/vm/runtime/globals.hpp.orig real 0m0.787s user 0m0.587s sys 0m0.200s What patch/changes did you apply before running `hg diff`? I have hard time getting `hg diff` to take longer than 1 second... > The full repo requires 1.9G. $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto $ du -ms consol-proto 1754 consol-proto/ I don't know why yours is 191 MB larger than mine. Different filesystem and or hg version? > A 'hg share' repo requires 0.6G $ mkdir measurements && cd measurements $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto $ du -ms . 1754 . $ hg share console-proto share $ du -ms . 2415 . so 2415 - 1754 = 661 MB for a share, so similar to my measurements. Thanks, Erik > A hotspot repo before required 0.2G. > > I will be able to live with this using modern, slower functionality ;) > But it imposes a considerable overhead in hardware, tool runtime > and administration on my side. > > Best regards, > Goetz. > > > > > > > > > > > > > > > > Can I check out several > > > > > -----Original Message----- > > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > > Anthony Vanelverdinghe > > Sent: Freitag, 14. Oktober 2016 22:11 > > To: jdk9-dev at openjdk.java.net > > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > > > Hi > > > > While I'm not an OpenJDK committer (yet, hope to become so one fine > > day), I believe this is a great initiative. Since several people have > > raised concerns related to the increased repository size, I just wanted > > to point out that both Facebook and Mozilla work with Mercurial > > repositories which dwarf a typical OpenJDK repository. For example, a > > clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev is > > less than 1 GB. > > > > There are also several Mercurial extensions which may prove to be useful > > for people having to work with large repositories and/or adapt their > > workflows. > > During their work to scale Mercurial [2], Facebook contributed/made > > several extensions, such as fsmonitor as mentioned by Joe [3], and the > > ones in their BitBucket repository [4], such as remotefilelog [5]. > > When working with local clones, the share extension may be helpful [6]. > > Finally, note that mq is "often considered for deprecation", so this may > > be an opportunity to adopt "modern tools, such as hg rebase, hg > > histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. > > > > Kind regards, > > Anthony > > > > [1] https://hg.mozilla.org/mozilla-central/ > > [2] > > https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- > > facebook/ > > [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > > October/004990.html > > [4] https://bitbucket.org/facebook/hg-experimental > > [5] > > https://bitbucket.org/facebook/hg- > > experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel > > og/?at=default > > [6] https://www.mercurial-scm.org/wiki/ShareExtension > > [7] https://www.mercurial-scm.org/wiki/MqExtension > > > > On 14/10/2016 19:03, Brian Goetz wrote: > > > > > >> Conversely, I think it is reasonable for engineers making changes to > > >> the JDK to be wiling to offer some flexibility in adjusting > > >> established worksflows optimized for the split repositories to > > >> accommodate the sort of infrastructure changes being proposed here > > >> for a consolidated one. > > > > > > Let me amplify this: OpenJDK developers are not the only stakeholders > > > here. By aligning more with the way the rest of the world develops > > > -- all code in one linearized, transactionally updated repo -- it > > > increases the feasibility / reduces the cost of tools like 'bisect' to > > > determine where a fault was introduced. This reduces SQE costs and > > > increases product quality -- something we all have a stake in. David > > > Lloyd has pointed up other tooling-related benefits, such as making it > > > easier to maintain a git mirror. > > > > > > Most of the objections raised so far have been "(I think they will) > > > make my life harder." Fair enough; people should be their own > > > advocates. But let's not forget the significant benefits that accrue > > > to *everyone* as a result, and keep those in mind when judging the > > > pros and cons. > > > > > > > > > > From erik.helin at oracle.com Mon Oct 17 11:47:06 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 17 Oct 2016 13:47:06 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> Message-ID: <20161017114706.GB28184@ehelin.jrpg.bea.com> Hi Maurizio, thanks for your feedback! Please see my replies inline. On 2016-10-13, Maurizio Cimadamore wrote: > Hi Joe, > some comments on this. As my workflow typically involve cloning one > langtools repo per each new fix, I'll start with discussing local clones > first. Starting with some concrete numbers, I am currently working on 2 > forests (jdk 9 and valhalla); between these two forests I currently have ~35 > langtools clones (for various prototypes and bug fixes). Also, as I'm > working on two machines, I keep them in sync using Unison, a very common > sync tool in linux land based on rsync. > > I have been experimenting with local clones, to see to which degree a local > clone could save in terms of space. My findings are that a local clone takes > around 800M - which seems consistent with the fact that Mercurial hardlinks > the repo files but not the history, which is simply copied. You might have gotten this the wrong way around. Mercurial will use hard links for most of the metadata for local clones on a file system that support hard links. The source code files themselves won't be hard links (otherwise, if you edited one file in one local clone then the file sharing the same inode in another local clone would get changed). > For people like me, working on langtools, that's quite a significant jump in > terms of space - a clean langtools repo is around 150M. So, in my specific > case, disk usage will jump from 150M * 35 =~ 5G to 800M * 35 =~ 28G (this > is a very conservative estimate - since it's assuming that all files are > hardlinked, which will not be the case as soon as I start making some > changes in the local clones). While this is not a deal breaker in terms of > disk spaces (my SSD has 200G in total), it poses serious strain on my > ability to do regular syncing/backups. Thanks for sharing your workflow! For this use case, could you perhaps try out the `hg share` extension? You need to enable the extension in your .hgrc. A share is like a clone, but Mercurial will share the store folder between all shares. This is *not* done using hardlinks, if you look in the .hg folder for a share, you will not see the "store" folder (you will see a file named sharedpath instead). Using shares on their own can be a bit tricky, but if you combine them with bookmarks, then you get a very powerful solution. In your case, I would suggest the following: $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto $ cd consol-proto $ hg bookmark '@' # traditional name for "master" bookmark $ cd .. $ hg share -B consol-proto bugfix-1 $ cd bugfix-1 $ hg bookmark 'bugfix-1' You will now end up with two directories, consol-proto and bugfix-1, both looking like a full forest, but they will share the same Mercurial store *and* list of bookmarks (but the active bookmark won't be shared). Since the shares use different bookmarks, the work you do in a share won't interfere with the work you do in another share (you will get multiple heads, but each head will have a bookmark associated with it). For backing up, you now only need to back up the consol-proto repository (it contains all the bookmarks and all commits). There is no need to back up the shares, they can always be created from the consol-proto repository. On my machine, using Linux 4.3.3 and ext4 as my filesystem, with hg version 3.8.1, a share uses 661 MB of disk. If you know want 35 shares, you would end up using 35 * 661 = 22.6 GB. But you only have to back up one repository! > Add to this the fact that most backup/syncing tools explicitly calls out the > hardlink case as being problematic. Unison doesn't support them, rsync > supports them to some degree, and even some professional backup tools I'm > using no do support them (or recommend to do without them anyway). So, local > cloning could be a fine solution when working on one machine, but as soon as > you start considering back up, you have troubles. For this reasons I will > have to consider to change my day to day workflow, and to try and avoid > relying on clone as much as I did - which poses issues: for instance, if I > keep all my patches in the same repo (by using either MQ or bookmarks) - how > do I differentiate between the different IDE projects to work on them? If you are using shares as suggested above, you would have one folder with all the source code for each bookmark. > Last but not the least - if the local clone size I'm seeing now (800M) is > almost entirely history-driven, and that already accounts for 50% of the > total size - doesn't that mean that i.e. in 2-3 years time, the size of the > history will trump the size of the files, meaning that the advantages of > doing local clones will be smaller and smaller over time? No, it is the other way around. For a local clone, you share all of the history (using hard links). So the size of your local clones scale with size of the source files (the same is true for shares). This can easily be verified by doing `du -ms .hg` for a share, I get 6 MB. Thanks, Erik > On a separate and more note, it seems to me that this effort is two > things at once: > > * a repo consolidation: use a single repo instead of a forest > * a source restructuring > > Each of the above moves has risks and costs for people in the OpenJDK land. > For instance, as discussed above, the repo consolidation might mean > significantly change the workflow people use on a daily basis (see above). > At the same time, the source restructuring is posing issues for things like > builds, IDE support, and the likes. > > I wonder if it wouldn't be sensible to do the repo restructuring now, where > the new repo is simply a consolidated version of the new one; no need to > update build scripts to take into account new paths. Then, maybe in the next > release (JDK 11), we could attack the source restructuring problem. This way > people will have more time to adjust to the big changes that are coming. > > What do you think? > > Maurizio > > > On 11/10/16 03:11, joe darcy wrote: > >Hello, > > > >Looking ahead to JDK 10, a group of JDK engineers have been exploring > >consolidating the large number of Hg repositories in an open JDK forest to > >a single one with the goal of using the consolidated arrangement for JDK > >10. > > > >This message is being sent to jdk9-dev since a jdk10-dev alias to discuss > >JDK 10 doesn't exist yet. > > > >A JEP describing the project has been submitted : > > > > JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single > >repository > > https://bugs.openjdk.java.net/browse/JDK-8167368 > > > >The text of the JEP describes the motivation and current state of the work > >in more detail, including proposed changes to the file layout. Publication > >of the prototype consolidated repository is planned, but not done yet. The > >email below has a list of additional anticipated questions and answers. > > > >We feel this consolidated arrangement offers some significant structural > >advantages for managing the JDK's source code and we are now asking for > >feedback on this potential change. In particular, if you feel there is a > >show-stopper problem with making this change, please let us know! > > > >I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and > >Ingemar Aberg participating in discussions leading up to the prototype and > >I'd like to especially recognize the contributions of Erik Helin for savvy > >Hg manipulations and Erik Joelsson for skillful build wrangling in this > >project. > > > >Please send initial comments by October 18, 2016. > > > >Cheers, > > > >-Joe > > > >Q: What about the set of forests for JDK 10? Are we going to have master, > >dev, client, hotspot, etc. the same set as in 9? > >A: That is a separate question from the repository consolidation, but > >there will likely be simplifications here too. Discussions on that point > >will come later. > > > >Q: I usually just build the code in repo X today. Will I have have to > >build the *whole JDK* now? > >A: Not necessarily. The same top-level build targets should work in the > >consolidated forest. > > > >Q: Does disk usage change? > >A: The total disk usage of the current forest compared to the consolidated > >forest is nearly the same. > > > >Q: In more detail, how were the changesets imported? > >A: The scripts used for the consolidation conversion are attached to the > >JEP. > > > >Q: What happens to the Hg hashes? > >A: The conversion scheme used in the prototype does *not* preserve Hg > >hashes of changesets compared the current forests. However, the bug ids > >are preserved and can be searched for. In addition, one or more > >pre-consolidation forests should be archived in perpetuity so that URLs in > >bug comments continue to work, etc. > > > >A mapping of the old hashes to the corresponding new hashes might be > >generated and placed in the final new repo. > > > >Q: I'm allergic to tabs; what about jcheck? > >A: If history is preserved, the checking done by jcheck needs to be > >modified for the consolidated forest. One way to do this is to augment the > >white lists used in jcheck with the conflicting changesets. This approach > >may not be elegant, but it is effective and doesn't appear to appreciably > >impact jcheck running times. > > > >Q: Will the future 9 update forest also have this consolidation > >restructuring? > >A: The script used to do the consolidation conversion is deterministic and > >could be run to create the 9 update forest in the future at the > >discretion of the 9 update team. > > > >Q: For backports for forwardports, will there be a script to translate > >patch files across the consolidation boundary? > >A: That work is planned, but not yet done; see JDK-8165623: Create patch > >translator to update paths pre/post consolidation. > > > >Q: It's the 21st century and I develop using an IDE. That is still going > >to work, right? > >A: The prototype to date does include updating the various IDE support > >files, but bug JDK-8167142 has been filed to track that work. > > > From goetz.lindenmaier at sap.com Mon Oct 17 12:22:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Oct 2016 12:22:07 +0000 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <20161017114140.GU19291@ehelin.jrpg.bea.com> References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> Message-ID: Hi, I'm on a 1.6 TB share available to our team visible on all our servers. The machine is a 48 processor 64GB linux x86_64 server. The servers only have limited local disc space. Especially with the new setup I can not have clones on all the machines I need to compile and test on. Best regards, Goetz. > -----Original Message----- > From: Erik Helin [mailto:erik.helin at oracle.com] > Sent: Montag, 17. Oktober 2016 13:42 > To: Lindenmaier, Goetz > Cc: Anthony Vanelverdinghe ; jdk9- > dev at openjdk.java.net > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > On 2016-10-17, Lindenmaier, Goetz wrote: > > Hi Anthony and Joe, > > > > > such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg > commit --amend" [7]. > > I understand how these commands replace hg queues. > > I don't understand how they replace having several > > clones to do something like this: > > - Change 1 is compiling (in clone 1) > > - Debugging change 2 (in clone 2) > > - I get a review and want to immediately edit change 3 (in clone 3), without > > invalidating the sources I stepped in the debugging session and without > > canceling the builds. > > I would recommend two similar but slighty different workflows for this: > - local clones (as previously discussed). One local clone per > feature/bug/review/debugging-session. > - shares, using `hg share` and bookmarks. One bookmark in each hg share. > > > If I use a single clone, I can have these three changes in three branches, > > or in several sequential changes (like a mercurial queue) I keep reordering > with > > histedit. But as there is only one source tree I can only work on one of > > the changes at a time. > > Hg share will do this job I assume. > > > > I have been looking at the consol-proto: > > The timings seems an order of magnitude off? What kind of machine are > you using? See inline for my measurements, all done on a 1 year old > Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg > version 3.8.1. > > > hg clone takes 30 minutes. Before, get_source.sh took 20 mins. > > $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto > requesting all changes > adding changesets > adding manifests > adding file changes > added 41157 changesets with 358201 changes to 148305 files > updating to branch default > 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved > > real 17m42.057s > user 4m37.156s > sys 0m41.153s > > The time for the remote clone will depend mostly on yours (and > Oracle's) network. The amount of bits that needs to be transferred are > almost the same (differs on a few MB IIRC) compared to a forest. The > difference is that the forest downloads the metadata for multiple > repositories in parallel. > > I know you find it cumbersome, but my recommendation here would be to > not clone that often from the remote servers. Since mercurial is a DVCS, > you already have most of the bits locally on your machine if you've > already cloned once. > > > Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > $ time hg share --bookmarks consol-proto share > updating working directory > 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved > > real 0m7.528s > user 0m28.442s > sys 0m9.791s > > I have no idea why it takes 5 (or even 3) minutes on your machine? > > > Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > $ cd consol-proto/src/hotspot/ > $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560- > basic_s390/hotspot.wr04/hotspot.changeset > $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent > $ time hg diff > M src/hotspot/os/linux/vm/os_linux.cpp > M src/hotspot/share/tools/hsdis/hsdis.c > M src/hotspot/share/vm/code/codeCache.cpp > M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp > M src/hotspot/share/vm/runtime/globals.hpp > M src/hotspot/share/vm/runtime/vm_version.cpp > M src/hotspot/share/vm/utilities/macros.hpp > ? src/hotspot/hotspot.changeset > ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig > ? src/hotspot/share/vm/runtime/globals.hpp.orig > > real 0m0.787s > user 0m0.587s > sys 0m0.200s > > What patch/changes did you apply before running `hg diff`? I have hard > time getting `hg diff` to take longer than 1 second... > > > The full repo requires 1.9G. > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > $ du -ms consol-proto > 1754 consol-proto/ > > I don't know why yours is 191 MB larger than mine. Different filesystem > and or hg version? > > > A 'hg share' repo requires 0.6G > > $ mkdir measurements && cd measurements > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > $ du -ms . > 1754 . > > $ hg share console-proto share > $ du -ms . > 2415 . > > so 2415 - 1754 = 661 MB for a share, so similar to my measurements. > > Thanks, > Erik > > > A hotspot repo before required 0.2G. > > > > I will be able to live with this using modern, slower functionality ;) > > But it imposes a considerable overhead in hardware, tool runtime > > and administration on my side. > > > > Best regards, > > Goetz. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can I check out several > > > > > > > > > -----Original Message----- > > > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf > Of > > > Anthony Vanelverdinghe > > > Sent: Freitag, 14. Oktober 2016 22:11 > > > To: jdk9-dev at openjdk.java.net > > > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > > > > > Hi > > > > > > While I'm not an OpenJDK committer (yet, hope to become so one fine > > > day), I believe this is a great initiative. Since several people have > > > raised concerns related to the increased repository size, I just wanted > > > to point out that both Facebook and Mozilla work with Mercurial > > > repositories which dwarf a typical OpenJDK repository. For example, a > > > clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev is > > > less than 1 GB. > > > > > > There are also several Mercurial extensions which may prove to be useful > > > for people having to work with large repositories and/or adapt their > > > workflows. > > > During their work to scale Mercurial [2], Facebook contributed/made > > > several extensions, such as fsmonitor as mentioned by Joe [3], and the > > > ones in their BitBucket repository [4], such as remotefilelog [5]. > > > When working with local clones, the share extension may be helpful [6]. > > > Finally, note that mq is "often considered for deprecation", so this may > > > be an opportunity to adopt "modern tools, such as hg rebase, hg > > > histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend" [7]. > > > > > > Kind regards, > > > Anthony > > > > > > [1] https://hg.mozilla.org/mozilla-central/ > > > [2] > > > https://code.facebook.com/posts/218678814984400/scaling-mercurial- > at- > > > facebook/ > > > [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > > > October/004990.html > > > [4] https://bitbucket.org/facebook/hg-experimental > > > [5] > > > https://bitbucket.org/facebook/hg- > > > > experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel > > > og/?at=default > > > [6] https://www.mercurial-scm.org/wiki/ShareExtension > > > [7] https://www.mercurial-scm.org/wiki/MqExtension > > > > > > On 14/10/2016 19:03, Brian Goetz wrote: > > > > > > > >> Conversely, I think it is reasonable for engineers making changes to > > > >> the JDK to be wiling to offer some flexibility in adjusting > > > >> established worksflows optimized for the split repositories to > > > >> accommodate the sort of infrastructure changes being proposed here > > > >> for a consolidated one. > > > > > > > > Let me amplify this: OpenJDK developers are not the only stakeholders > > > > here. By aligning more with the way the rest of the world develops > > > > -- all code in one linearized, transactionally updated repo -- it > > > > increases the feasibility / reduces the cost of tools like 'bisect' to > > > > determine where a fault was introduced. This reduces SQE costs and > > > > increases product quality -- something we all have a stake in. David > > > > Lloyd has pointed up other tooling-related benefits, such as making it > > > > easier to maintain a git mirror. > > > > > > > > Most of the objections raised so far have been "(I think they will) > > > > make my life harder." Fair enough; people should be their own > > > > advocates. But let's not forget the significant benefits that accrue > > > > to *everyone* as a result, and keep those in mind when judging the > > > > pros and cons. > > > > > > > > > > > > > > From uschindler at apache.org Sun Oct 16 21:33:11 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 16 Oct 2016 23:33:11 +0200 Subject: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!) Message-ID: <003701d227f4$e7a41780$b6ec4680$@apache.org> Hi, (I cc'ed jdk-dev at openjdk, reader there please read the previous mails below, too). I analyzed the problem, although I don't know exactly why it happens: - On Windows it does not happen on my machine (no idea why!) - On Linux it happens when tests are running with security manager (this is the default for Lucene and Jenkins does this) - On Linux it does not happen if I run Lucene tests with "-Dtests.useSecurityManager=false" This makes me think it is related to this: "Remove pathname canonicalization from FilePermission" (https://bugs.openjdk.java.net/browse/JDK-8164705) What seems to happen: The code calls Class.getResource to get back an URL. As the JAR file is somehow outside of the FilePermissions given to the test suite, it seems to fail. Maybe because some of the checks failed, Class.getResource then returns a null reference, because it was not able to access the JAR file. Were there some changes related to this: URLClassLoader and FilePermission checks? How should we proceed? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Uwe Schindler [mailto:uwe at thetaphi.de] > Sent: Sunday, October 16, 2016 10:10 PM > To: dev at lucene.apache.org > Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > Kolarkunnu' ; 'Dawid Weiss' > > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > Build # 18064 - Unstable! > > Hi, > > I reverted the Lucene builds to build Java 9 138 for now. I will later check if > this also happens with build 139, which I have to download first. I will also > debug locally. > > The code fails because this code hits "null" on getResource() at > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > https://github.com/morfologik/morfologik- > stemming/blob/master/morfologik- > polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32 > > This is impossible to happen, because the dict file is in same package. I have > no idea why this only fails here and not at other places in Lucene. The main > difference looks like the use of URL instead of getResourceAsStream() like > other places in Lucene. > > So this seems to be a major regression in Java 9 build 140. > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: uwe at thetaphi.de > > > -----Original Message----- > > From: Uwe Schindler [mailto:uwe at thetaphi.de] > > Sent: Sunday, October 16, 2016 8:38 PM > > To: dev at lucene.apache.org > > Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > > Kolarkunnu' ; 'Dawid Weiss' > > ; dev at lucene.apache.org > > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > > Build # 18064 - Unstable! > > > > Hi, > > > > this seems to be a new regression in Java 9 ea build 140. Interestingly this > > only affects 2 libraries (morphologic and commons-codec phonetic). We > use > > loading of resources from classloaders at many places; it is unclear to me, > > why it only fails here. I will look into the code, but this is outside of Lucene. > I > > think it might be some crazyness like using context class loader in non- > proper > > ways or similar. > > > > Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one > > was build 138). > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: uwe at thetaphi.de > > > > > -----Original Message----- > > > From: Policeman Jenkins Server [mailto:jenkins at thetaphi.de] > > > Sent: Sunday, October 16, 2016 8:20 PM > > > To: dev at lucene.apache.org > > > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > Build > > # > > > 18064 - Unstable! > > > Importance: Low > > > > > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/ > > > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC > > > > > > 24 tests failed. > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > > > ens > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9 > > > A]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > > > ens(TestMorfologikAnalyzer.java:44) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:55EF45E52DB9129 > > > B]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom( > > > TestMorfologikAnalyzer.java:201) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:88AC75BEA84F2F4 > > > D]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase(Test > > > MorfologikAnalyzer.java:111) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > > > tems > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:AE90F581CE44382 > > > ]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > > > tems(TestMorfologikAnalyzer.java:90) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > > > okens > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:E0465B37C534996 > > > 1]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > > > okens(TestMorfologikAnalyzer.java:54) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > > > AttrTokens > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:2B64B15327EFD51 > > > F]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer$1.(Test > > > MorfologikAnalyzer.java:174) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > > > AttrTokens(TestMorfologikAnalyzer.java:174) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > > > ute > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:86D7B88D4CD696 > > > 2B]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > Analyzer.java:52) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > zer(TestMorfologikAnalyzer.java:39) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > > > ute(TestMorfologikAnalyzer.java:148) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 39 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > > > ltDictionary > > > > > > Error Message: > > > Could not read dictionary data. > > > > > > Stack Trace: > > > java.lang.RuntimeException: Could not read dictionary data. > > > at > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:77E7676752C75E7 > > > 1]:0) > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > at > > > > > > org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.inform(Morfo > > > logikFilterFactory.java:85) > > > at > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > > > ltDictionary(TestMorfologikFilterFactory.java:56) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > at > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > ... 38 more > > > > > > > > > FAILED: > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers > > > > > > Error Message: > > > > > > > > > Stack Trace: > > > java.lang.ExceptionInInitializerError > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E3117A948221F6D > > > C]:0) > > > at > > > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > ents(TestBeiderMorseFilter.java:49) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:358) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:388) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers(Tes > > > tBeiderMorseFilter.java:101) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.lang.IllegalArgumentException: Unable to resolve > required > > > resource: org/apache/commons/codec/language/bm/ash_languages.txt > > > at > > > > > > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > > > java:175) > > > at > > > > > > org.apache.commons.codec.language.bm.Languages.(Languages.java: > > > 161) > > > ... 45 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > > > ute > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:D36838D48CB19E1 > > > 4]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > > > ute(TestBeiderMorseFilter.java:128) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:1C94D74A60E4B53 > > > F]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > ents(TestBeiderMorseFilter.java:49) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:511) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:434) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom(Test > > > BeiderMorseFilter.java:109) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > > > A]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$3.createCompon > > > ents(TestBeiderMorseFilter.java:86) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:358) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:388) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet( > > > TestBeiderMorseFilter.java:91) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > > > D]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$4.createCompon > > > ents(TestBeiderMorseFilter.java:117) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:358) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:368) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > > > okenStreamTestCase.java:429) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm(T > > > estBeiderMorseFilter.java:120) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:35CB4BA05D8C5C > > > AC]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > ents(TestBeiderMorseFilter.java:49) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:358) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:388) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage(T > > > estBeiderMorseFilter.java:63) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > > > > > > Error Message: > > > > > > > > > Stack Trace: > > > java.lang.ExceptionInInitializerError > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:53005C69E96A5D3 > > > C]:0) > > > at > > > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > MorseFilterFactory.java:56) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > > > (TestBeiderMorseFilterFactory.java:29) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.lang.IllegalArgumentException: Unable to resolve > required > > > resource: org/apache/commons/codec/language/bm/ash_languages.txt > > > at > > > > > > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > > > java:175) > > > at > > > > > > org.apache.commons.codec.language.bm.Languages.(Languages.java: > > > 161) > > > ... 41 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > > > ns > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:CCFC21040ED1AB3 > > > A]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > MorseFilterFactory.java:56) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > > > ns(TestBeiderMorseFilterFactory.java:54) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > > > ageSet > > > > > > Error Message: > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > > > A]:0) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > MorseFilterFactory.java:56) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > > > ageSet(TestBeiderMorseFilterFactory.java:41) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > > > Arguments > > > > > > Error Message: > > > Unexpected exception type, expected IllegalArgumentException > > > > > > Stack Trace: > > > junit.framework.AssertionFailedError: Unexpected exception type, > > expected > > > IllegalArgumentException > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8BC3C48769987F7 > > > B]:0) > > > at > > > > > > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > > > 681) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > > > Arguments(TestBeiderMorseFilterFactory.java:65) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.bm.Lang > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:317) > > > at > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > ine.java:293) > > > at > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > MorseFilterFactory.java:56) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.lambda$t > > > estBogusArguments$0(TestBeiderMorseFilterFactory.java:66) > > > at > > > > > > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > > > 676) > > > ... 37 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > > > mptyTerm > > > > > > Error Message: > > > > > > > > > Stack Trace: > > > java.lang.ExceptionInInitializerError > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > > > D]:0) > > > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$3.cre > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:80) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:358) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > eTokenStreamTestCase.java:368) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > > > okenStreamTestCase.java:429) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > > > mptyTerm(TestDaitchMokotoffSoundexFilter.java:83) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > estSuites.java:54) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > Caused by: java.lang.IllegalArgumentException: Unable to load resource: > > > org/apache/commons/codec/language/dmrules.txt > > > at > > > > > > org.apache.commons.codec.language.DaitchMokotoffSoundex.(Daitc > > > hMokotoffSoundex.java:231) > > > ... 44 more > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > andomStrings > > > > > > Error Message: > > > Could not initialize class > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > > > Stack Trace: > > > java.lang.NoClassDefFoundError: Could not initialize class > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB7280547 > > > 9]:0) > > > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > > > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:511) > > > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:434) > > > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > ea/Method.java:535) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > dRunner.java:1764) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > mizedRunner.java:871) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > mizedRunner.java:907) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > omizedRunner.java:921) > > > at > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > SetupTeardownChained.java:49) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > eadAndTestName.java:48) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAfterMaxFailures.java:64) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > un(ThreadLeakControl.java:367) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > (ThreadLeakControl.java:809) > > > at > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > eakControl.java:460) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > domizedRunner.java:880) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > mizedRunner.java:781) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > mizedRunner.java:816) > > > at > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > mizedRunner.java:827) > > > at > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > terRule.java:45) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > ssName.java:41) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > mentAdapter.java:36) > > > at > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > rtionsRequired.java:53) > > > at > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > java:47) > > > at > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > gnoreAft > > > > > > [...truncated too long message...] > > > > > > dtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB72805479]:0) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > > > [junit4] > at > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > BaseTokenStreamTestCase.java:392) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:511) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > seTokenStreamTestCase.java:434) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > [junit4] > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > [junit4] > at java.lang.Thread.run(java.base at 9- > ea/Thread.java:843) > > > [junit4] 2> NOTE: reproduce with: ant test - > > > Dtestcase=TestDaitchMokotoffSoundexFilter - > > Dtests.method=testAlgorithms > > > -Dtests.seed=6ED8F245D184034C -Dtests.multiplier=3 -Dtests.slow=true - > > > Dtests.locale=ps -Dtests.timezone=America/Antigua -Dtests.asserts=true - > > > Dtests.file.encoding=UTF-8 > > > [junit4] ERROR 0.00s J0 | > > TestDaitchMokotoffSoundexFilter.testAlgorithms > > > <<< > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > initialize class > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > [junit4] > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:3823E49E787418B > > > 7]:0) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.asser > > > tAlgorithm(TestDaitchMokotoffSoundexFilter.java:46) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testAl > > > gorithms(TestDaitchMokotoffSoundexFilter.java:35) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > [junit4] > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > [junit4] > at java.lang.Thread.run(java.base at 9- > ea/Thread.java:843) > > > [junit4] 2> NOTE: test params are: codec=Lucene70, > > sim=ClassicSimilarity, > > > locale=ps, timezone=America/Antigua > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > (32- > > > bit)/cpus=12,threads=1,free=47297104,total=81526784 > > > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > > > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter] > > > [junit4] Completed [5/8 (3!)] on J0 in 0.04s, 3 tests, 3 errors <<< > FAILURES! > > > > > > [...truncated 1 lines...] > > > [junit4] Suite: > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > y > > > [junit4] 2> NOTE: reproduce with: ant test - > > > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > > > Dtests.method=testDefaults -Dtests.seed=6ED8F245D184034C - > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > > > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > > > Dtests.file.encoding=UTF-8 > > > [junit4] ERROR 0.02s J0 | > > > TestDaitchMokotoffSoundexFilterFactory.testDefaults <<< > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > initialize class > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > [junit4] > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:C17CBC6FF981506 > > > 0]:0) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > > > eate(DaitchMokotoffSoundexFilterFactory.java:63) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > y.testDefaults(TestDaitchMokotoffSoundexFilterFactory.java:36) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > [junit4] > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > [junit4] > at java.lang.Thread.run(java.base at 9- > ea/Thread.java:843) > > > [junit4] 2> NOTE: reproduce with: ant test - > > > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > > > Dtests.method=testSettingInject -Dtests.seed=6ED8F245D184034C - > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > > > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > > > Dtests.file.encoding=UTF-8 > > > [junit4] ERROR 0.00s J0 | > > > TestDaitchMokotoffSoundexFilterFactory.testSettingInject <<< > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > initialize class > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > [junit4] > at > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8B47767F15CB356 > > > 1]:0) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > tchMokotoffSoundexFilter.java:38) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > > > eate(DaitchMokotoffSoundexFilterFactory.java:63) > > > [junit4] > at > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > y.testSettingInject(TestDaitchMokotoffSoundexFilterFactory.java:49) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > [junit4] > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > [junit4] > at java.lang.Thread.run(java.base at 9- > ea/Thread.java:843) > > > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {}, > > > docValues:{}, maxPointsInLeafNode=1560, > > > maxMBSortInHeap=6.407822741000916, sim=ClassicSimilarity, > locale=guz, > > > timezone=America/Indiana/Marengo > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > (32- > > > bit)/cpus=12,threads=1,free=103729528,total=115605504 > > > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > > > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter, > > > TestDaitchMokotoffSoundexFilterFactory] > > > [junit4] Completed [6/8 (4!)] on J0 in 0.06s, 3 tests, 2 errors <<< > FAILURES! > > > > > > [...truncated 1966 lines...] > > > [junit4] Suite: > > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser > > > [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestHtmlParser - > > > Dtests.method=testEntities -Dtests.seed=7EC5D3E55917236B - > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es-PH - > > > Dtests.timezone=Canada/Mountain -Dtests.asserts=true - > > > Dtests.file.encoding=ISO-8859-1 > > > [junit4] ERROR 0.01s J1 | TestHtmlParser.testEntities <<< > > > [junit4] > Throwable #1: java.lang.ExceptionInInitializerError > > > [junit4] > at > > > > > > __randomizedtesting.SeedInfo.seed([7EC5D3E55917236B:EDC240C50B38B8B > > > 2]:0) > > > [junit4] > at > > > org.cyberneko.html.HTMLScanner.scanEntityRef(HTMLScanner.java:1405) > > > [junit4] > at > > > > > > org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java: > > > 2007) > > > [junit4] > at > > > > org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:918) > > > [junit4] > at > > > > > > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) > > > [junit4] > at > > > > > > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) > > > [junit4] > at > org.apache.xerces.parsers.XMLParser.parse(Unknown > > > Source) > > > [junit4] > at > > > org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > > > [junit4] > at > > > > > > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > > > (DemoHTMLParser.java:140) > > > [junit4] > at > > > > > > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > > > (DemoHTMLParser.java:51) > > > [junit4] > at > > > > > > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser.testEntities(Test > > > HtmlParser.java:37) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > ea/Native Method) > > > [junit4] > at > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > ea/NativeMethodAccessorImpl.java:62) > > > [junit4] > at > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > ea/DelegatingMethodAccessorImpl.java:43) > > > [junit4] > at java.lang.Thread.run(java.base at 9- > ea/Thread.java:843) > > > [junit4] > Caused by: java.lang.NullPointerException: inStream > > parameter > > > is null > > > [junit4] > at java.util.Objects.requireNonNull(java.base at 9- > > > ea/Objects.java:246) > > > [junit4] > at java.util.Properties.load(java.base at 9- > > > ea/Properties.java:364) > > > [junit4] > at > > > org.cyberneko.html.HTMLEntities.load0(HTMLEntities.java:99) > > > [junit4] > at > > > org.cyberneko.html.HTMLEntities.(HTMLEntities.java:52) > > > [junit4] > ... 46 more > > > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70), > > > sim=RandomSimilarity(queryNorm=false): {}, locale=es-PH, > > > timezone=Canada/Mountain > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > (32- > > > bit)/cpus=12,threads=1,free=47165080,total=81526784 > > > [junit4] 2> NOTE: All tests run in this JVM: [SearchWithSortTaskTest, > > > TestHtmlParser] > > > [junit4] Completed [4/18 (1!)] on J1 in 0.10s, 12 tests, 1 error <<< > > FAILURES! > > > > > > [...truncated 56873 lines...] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > > For additional commands, e-mail: dev-help at lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > For additional commands, e-mail: dev-help at lucene.apache.org From uschindler at apache.org Sun Oct 16 22:09:41 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 17 Oct 2016 00:09:41 +0200 Subject: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!) In-Reply-To: <003701d227f4$e7a41780$b6ec4680$@apache.org> References: <003701d227f4$e7a41780$b6ec4680$@apache.org> Message-ID: <003e01d227fa$00cb81d0$02628570$@apache.org> Hi again, with jdk.io.permissionsUseCanonicalPath=true it also works, so it is related to the new FilePermission code, so my first guess was true, the issue is JDK-8164705. Uwe > (I cc'ed jdk-dev at openjdk, reader there please read the previous mails > below, too). > > I analyzed the problem, although I don't know exactly why it happens: > - On Windows it does not happen on my machine (no idea why!) > - On Linux it happens when tests are running with security manager (this is > the default for Lucene and Jenkins does this) > - On Linux it does not happen if I run Lucene tests with "- > Dtests.useSecurityManager=false" > > This makes me think it is related to this: "Remove pathname canonicalization > from FilePermission" (https://bugs.openjdk.java.net/browse/JDK-8164705) > > What seems to happen: The code calls Class.getResource to get back an URL. > As the JAR file is somehow outside of the FilePermissions given to the test > suite, it seems to fail. Maybe because some of the checks failed, > Class.getResource then returns a null reference, because it was not able to > access the JAR file. > > Were there some changes related to this: URLClassLoader and FilePermission > checks? > > How should we proceed? > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > > > -----Original Message----- > > From: Uwe Schindler [mailto:uwe at thetaphi.de] > > Sent: Sunday, October 16, 2016 10:10 PM > > To: dev at lucene.apache.org > > Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > > Kolarkunnu' ; 'Dawid Weiss' > > > > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > > Build # 18064 - Unstable! > > > > Hi, > > > > I reverted the Lucene builds to build Java 9 138 for now. I will later check if > > this also happens with build 139, which I have to download first. I will also > > debug locally. > > > > The code fails because this code hits "null" on getResource() at > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > https://github.com/morfologik/morfologik- > > stemming/blob/master/morfologik- > > > polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32 > > > > This is impossible to happen, because the dict file is in same package. I > have > > no idea why this only fails here and not at other places in Lucene. The main > > difference looks like the use of URL instead of getResourceAsStream() like > > other places in Lucene. > > > > So this seems to be a major regression in Java 9 build 140. > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: uwe at thetaphi.de > > > > > -----Original Message----- > > > From: Uwe Schindler [mailto:uwe at thetaphi.de] > > > Sent: Sunday, October 16, 2016 8:38 PM > > > To: dev at lucene.apache.org > > > Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > > > Kolarkunnu' ; 'Dawid Weiss' > > > ; dev at lucene.apache.org > > > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > > > Build # 18064 - Unstable! > > > > > > Hi, > > > > > > this seems to be a new regression in Java 9 ea build 140. Interestingly this > > > only affects 2 libraries (morphologic and commons-codec phonetic). We > > use > > > loading of resources from classloaders at many places; it is unclear to me, > > > why it only fails here. I will look into the code, but this is outside of > Lucene. > > I > > > think it might be some crazyness like using context class loader in non- > > proper > > > ways or similar. > > > > > > Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one > > > was build 138). > > > > > > Uwe > > > > > > ----- > > > Uwe Schindler > > > H.-H.-Meier-Allee 63, D-28213 Bremen > > > http://www.thetaphi.de > > > eMail: uwe at thetaphi.de > > > > > > > -----Original Message----- > > > > From: Policeman Jenkins Server [mailto:jenkins at thetaphi.de] > > > > Sent: Sunday, October 16, 2016 8:20 PM > > > > To: dev at lucene.apache.org > > > > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > > Build > > > # > > > > 18064 - Unstable! > > > > Importance: Low > > > > > > > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/ > > > > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC > > > > > > > > 24 tests failed. > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > > > > ens > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9 > > > > A]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > > > > ens(TestMorfologikAnalyzer.java:44) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:55EF45E52DB9129 > > > > B]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom( > > > > TestMorfologikAnalyzer.java:201) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:88AC75BEA84F2F4 > > > > D]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase(Test > > > > MorfologikAnalyzer.java:111) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > > > > tems > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:AE90F581CE44382 > > > > ]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > > > > tems(TestMorfologikAnalyzer.java:90) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > > > > okens > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:E0465B37C534996 > > > > 1]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > > > > okens(TestMorfologikAnalyzer.java:54) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > > > > AttrTokens > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:2B64B15327EFD51 > > > > F]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer$1.(Test > > > > MorfologikAnalyzer.java:174) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > > > > AttrTokens(TestMorfologikAnalyzer.java:174) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > > > > ute > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:86D7B88D4CD696 > > > > 2B]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > > > > Analyzer.java:52) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > > > > zer(TestMorfologikAnalyzer.java:39) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > > > > ute(TestMorfologikAnalyzer.java:148) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 39 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > > > > ltDictionary > > > > > > > > Error Message: > > > > Could not read dictionary data. > > > > > > > > Stack Trace: > > > > java.lang.RuntimeException: Could not read dictionary data. > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:77E7676752C75E7 > > > > 1]:0) > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.inform(Morfo > > > > logikFilterFactory.java:85) > > > > at > > > > > > > > > > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > > > > ltDictionary(TestMorfologikFilterFactory.java:56) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.io.IOException: Polish dictionary resource not found. > > > > at > > > > > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > ... 38 more > > > > > > > > > > > > FAILED: > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers > > > > > > > > Error Message: > > > > > > > > > > > > Stack Trace: > > > > java.lang.ExceptionInInitializerError > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E3117A948221F6D > > > > C]:0) > > > > at > > > > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > > ents(TestBeiderMorseFilter.java:49) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:358) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:388) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers(Tes > > > > tBeiderMorseFilter.java:101) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.lang.IllegalArgumentException: Unable to resolve > > required > > > > resource: > org/apache/commons/codec/language/bm/ash_languages.txt > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > > > > java:175) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.Languages.(Languages.java: > > > > 161) > > > > ... 45 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > > > > ute > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:D36838D48CB19E1 > > > > 4]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > > > > ute(TestBeiderMorseFilter.java:128) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:1C94D74A60E4B53 > > > > F]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > > ents(TestBeiderMorseFilter.java:49) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:511) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:434) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom(Test > > > > BeiderMorseFilter.java:109) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > > > > A]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$3.createCompon > > > > ents(TestBeiderMorseFilter.java:86) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:358) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:388) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet( > > > > TestBeiderMorseFilter.java:91) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > > > > D]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$4.createCompon > > > > ents(TestBeiderMorseFilter.java:117) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:358) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:368) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > > > > okenStreamTestCase.java:429) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm(T > > > > estBeiderMorseFilter.java:120) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:35CB4BA05D8C5C > > > > AC]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > > > > ents(TestBeiderMorseFilter.java:49) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:358) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:388) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage(T > > > > estBeiderMorseFilter.java:63) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > > > > > > > > Error Message: > > > > > > > > > > > > Stack Trace: > > > > java.lang.ExceptionInInitializerError > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:53005C69E96A5D3 > > > > C]:0) > > > > at > > > > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > > MorseFilterFactory.java:56) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > > > > (TestBeiderMorseFilterFactory.java:29) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.lang.IllegalArgumentException: Unable to resolve > > required > > > > resource: > org/apache/commons/codec/language/bm/ash_languages.txt > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > > > > java:175) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.Languages.(Languages.java: > > > > 161) > > > > ... 41 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > > > > ns > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:CCFC21040ED1AB3 > > > > A]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > > MorseFilterFactory.java:56) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > > > > ns(TestBeiderMorseFilterFactory.java:54) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > > > > ageSet > > > > > > > > Error Message: > > > > Could not initialize class org.apache.commons.codec.language.bm.Lang > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > > > > A]:0) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > > MorseFilterFactory.java:56) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > > > > ageSet(TestBeiderMorseFilterFactory.java:41) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > > > > Arguments > > > > > > > > Error Message: > > > > Unexpected exception type, expected IllegalArgumentException > > > > > > > > Stack Trace: > > > > junit.framework.AssertionFailedError: Unexpected exception type, > > > expected > > > > IllegalArgumentException > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8BC3C48769987F7 > > > > B]:0) > > > > at > > > > > > > > > > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > > > > 681) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > > > > Arguments(TestBeiderMorseFilterFactory.java:65) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.bm.Lang > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:317) > > > > at > > > > > > > > > > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > > > > ine.java:293) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > > > > MorseFilterFactory.java:56) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.lambda$t > > > > estBogusArguments$0(TestBeiderMorseFilterFactory.java:66) > > > > at > > > > > > > > > > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > > > > 676) > > > > ... 37 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > > > > mptyTerm > > > > > > > > Error Message: > > > > > > > > > > > > Stack Trace: > > > > java.lang.ExceptionInInitializerError > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > > > > D]:0) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$3.cre > > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:80) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:358) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > > > > eTokenStreamTestCase.java:368) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > > > > okenStreamTestCase.java:429) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > > > > mptyTerm(TestDaitchMokotoffSoundexFilter.java:83) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > > > > estSuites.java:54) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > > > > Caused by: java.lang.IllegalArgumentException: Unable to load > resource: > > > > org/apache/commons/codec/language/dmrules.txt > > > > at > > > > > > > > > > org.apache.commons.codec.language.DaitchMokotoffSoundex.(Daitc > > > > hMokotoffSoundex.java:231) > > > > ... 44 more > > > > > > > > > > > > FAILED: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > > andomStrings > > > > > > > > Error Message: > > > > Could not initialize class > > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > > > > > Stack Trace: > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB7280547 > > > > 9]:0) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:511) > > > > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:434) > > > > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(java.base at 9- > > > > ea/Method.java:535) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > > > > dRunner.java:1764) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > > > > mizedRunner.java:871) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > > > > mizedRunner.java:907) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > > > > omizedRunner.java:921) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > > > > SetupTeardownChained.java:49) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > > > > eadAndTestName.java:48) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAfterMaxFailures.java:64) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > > > > un(ThreadLeakControl.java:367) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > > > > (ThreadLeakControl.java:809) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > > > > eakControl.java:460) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > > > > domizedRunner.java:880) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > > > > mizedRunner.java:781) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > > > > mizedRunner.java:816) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > > > > mizedRunner.java:827) > > > > at > > > > > > > > > > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > > > > terRule.java:45) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > > > > ssName.java:41) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > > > > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > > > > mentAdapter.java:36) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > > > > rtionsRequired.java:53) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > > > > java:47) > > > > at > > > > > > > > > > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > > > > gnoreAft > > > > > > > > [...truncated too long message...] > > > > > > > > dtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB72805479]:0) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > > > > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > > > > [junit4] > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > > > > BaseTokenStreamTestCase.java:392) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:511) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > > > > seTokenStreamTestCase.java:434) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > > > > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > [junit4] > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > [junit4] > at java.lang.Thread.run(java.base at 9- > > ea/Thread.java:843) > > > > [junit4] 2> NOTE: reproduce with: ant test - > > > > Dtestcase=TestDaitchMokotoffSoundexFilter - > > > Dtests.method=testAlgorithms > > > > -Dtests.seed=6ED8F245D184034C -Dtests.multiplier=3 -Dtests.slow=true > - > > > > Dtests.locale=ps -Dtests.timezone=America/Antigua - > Dtests.asserts=true - > > > > Dtests.file.encoding=UTF-8 > > > > [junit4] ERROR 0.00s J0 | > > > TestDaitchMokotoffSoundexFilter.testAlgorithms > > > > <<< > > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > > initialize class > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > [junit4] > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:3823E49E787418B > > > > 7]:0) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.asser > > > > tAlgorithm(TestDaitchMokotoffSoundexFilter.java:46) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testAl > > > > gorithms(TestDaitchMokotoffSoundexFilter.java:35) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > [junit4] > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > [junit4] > at java.lang.Thread.run(java.base at 9- > > ea/Thread.java:843) > > > > [junit4] 2> NOTE: test params are: codec=Lucene70, > > > sim=ClassicSimilarity, > > > > locale=ps, timezone=America/Antigua > > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > > (32- > > > > bit)/cpus=12,threads=1,free=47297104,total=81526784 > > > > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > > > > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter] > > > > [junit4] Completed [5/8 (3!)] on J0 in 0.04s, 3 tests, 3 errors <<< > > FAILURES! > > > > > > > > [...truncated 1 lines...] > > > > [junit4] Suite: > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > > y > > > > [junit4] 2> NOTE: reproduce with: ant test - > > > > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > > > > Dtests.method=testDefaults -Dtests.seed=6ED8F245D184034C - > > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > > > > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > > > > Dtests.file.encoding=UTF-8 > > > > [junit4] ERROR 0.02s J0 | > > > > TestDaitchMokotoffSoundexFilterFactory.testDefaults <<< > > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > > initialize class > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > [junit4] > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:C17CBC6FF981506 > > > > 0]:0) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > > > > eate(DaitchMokotoffSoundexFilterFactory.java:63) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > > y.testDefaults(TestDaitchMokotoffSoundexFilterFactory.java:36) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > [junit4] > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > [junit4] > at java.lang.Thread.run(java.base at 9- > > ea/Thread.java:843) > > > > [junit4] 2> NOTE: reproduce with: ant test - > > > > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > > > > Dtests.method=testSettingInject -Dtests.seed=6ED8F245D184034C - > > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > > > > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > > > > Dtests.file.encoding=UTF-8 > > > > [junit4] ERROR 0.00s J0 | > > > > TestDaitchMokotoffSoundexFilterFactory.testSettingInject <<< > > > > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > > > > initialize class > > > org.apache.commons.codec.language.DaitchMokotoffSoundex > > > > [junit4] > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8B47767F15CB356 > > > > 1]:0) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > > > > tchMokotoffSoundexFilter.java:38) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > > > > eate(DaitchMokotoffSoundexFilterFactory.java:63) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > > > > y.testSettingInject(TestDaitchMokotoffSoundexFilterFactory.java:49) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > [junit4] > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > [junit4] > at java.lang.Thread.run(java.base at 9- > > ea/Thread.java:843) > > > > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {}, > > > > docValues:{}, maxPointsInLeafNode=1560, > > > > maxMBSortInHeap=6.407822741000916, sim=ClassicSimilarity, > > locale=guz, > > > > timezone=America/Indiana/Marengo > > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > > (32- > > > > bit)/cpus=12,threads=1,free=103729528,total=115605504 > > > > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > > > > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter, > > > > TestDaitchMokotoffSoundexFilterFactory] > > > > [junit4] Completed [6/8 (4!)] on J0 in 0.06s, 3 tests, 2 errors <<< > > FAILURES! > > > > > > > > [...truncated 1966 lines...] > > > > [junit4] Suite: > > > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser > > > > [junit4] 2> NOTE: reproduce with: ant test - > Dtestcase=TestHtmlParser - > > > > Dtests.method=testEntities -Dtests.seed=7EC5D3E55917236B - > > > > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es-PH - > > > > Dtests.timezone=Canada/Mountain -Dtests.asserts=true - > > > > Dtests.file.encoding=ISO-8859-1 > > > > [junit4] ERROR 0.01s J1 | TestHtmlParser.testEntities <<< > > > > [junit4] > Throwable #1: java.lang.ExceptionInInitializerError > > > > [junit4] > at > > > > > > > > > > __randomizedtesting.SeedInfo.seed([7EC5D3E55917236B:EDC240C50B38B8B > > > > 2]:0) > > > > [junit4] > at > > > > > org.cyberneko.html.HTMLScanner.scanEntityRef(HTMLScanner.java:1405) > > > > [junit4] > at > > > > > > > > > > org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java: > > > > 2007) > > > > [junit4] > at > > > > > > org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:918) > > > > [junit4] > at > > > > > > > > > > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) > > > > [junit4] > at > > > > > > > > > > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) > > > > [junit4] > at > > org.apache.xerces.parsers.XMLParser.parse(Unknown > > > > Source) > > > > [junit4] > at > > > > org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > > > > (DemoHTMLParser.java:140) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > > > > (DemoHTMLParser.java:51) > > > > [junit4] > at > > > > > > > > > > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser.testEntities(Test > > > > HtmlParser.java:37) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > > > > ea/Native Method) > > > > [junit4] > at > > > > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > > > > ea/NativeMethodAccessorImpl.java:62) > > > > [junit4] > at > > > > > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > > > > ea/DelegatingMethodAccessorImpl.java:43) > > > > [junit4] > at java.lang.Thread.run(java.base at 9- > > ea/Thread.java:843) > > > > [junit4] > Caused by: java.lang.NullPointerException: inStream > > > parameter > > > > is null > > > > [junit4] > at java.util.Objects.requireNonNull(java.base at 9- > > > > ea/Objects.java:246) > > > > [junit4] > at java.util.Properties.load(java.base at 9- > > > > ea/Properties.java:364) > > > > [junit4] > at > > > > org.cyberneko.html.HTMLEntities.load0(HTMLEntities.java:99) > > > > [junit4] > at > > > > org.cyberneko.html.HTMLEntities.(HTMLEntities.java:52) > > > > [junit4] > ... 46 more > > > > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70), > > > > sim=RandomSimilarity(queryNorm=false): {}, locale=es-PH, > > > > timezone=Canada/Mountain > > > > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > > > (32- > > > > bit)/cpus=12,threads=1,free=47165080,total=81526784 > > > > [junit4] 2> NOTE: All tests run in this JVM: [SearchWithSortTaskTest, > > > > TestHtmlParser] > > > > [junit4] Completed [4/18 (1!)] on J1 in 0.10s, 12 tests, 1 error <<< > > > FAILURES! > > > > > > > > [...truncated 56873 lines...] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > > > For additional commands, e-mail: dev-help at lucene.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > > For additional commands, e-mail: dev-help at lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > For additional commands, e-mail: dev-help at lucene.apache.org From uschindler at apache.org Mon Oct 17 12:16:40 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 17 Oct 2016 14:16:40 +0200 Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable! In-Reply-To: References: <1015461895.91.1476642111617.JavaMail.jenkins@serv1> <002b01d227dc$5eff3e40$1cfdbac0$@thetaphi.de> <003401d227e9$40cebec0$c26c3c40$@thetaphi.de> Message-ID: <00dc01d22870$53ba1d40$fb2e57c0$@apache.org> Hi, yes I checked more already: The issue is caused by the mentioned change (canonicalize of FilePermission). According to the docs of SecurityManager and FilePermission, code should always be able to read stuff below the classpath where the code was loaded from (in our case its part of a JAR file). So there is no need to add permissions for this, it should work automatically. So the following code must work without any extra permissions: URL url = this.getClass().getResource("somefilenexttoclassfile"); InputStream is = url.openStream(); Interestingly the first line already returns "null", means "resource not found", you don't get any SecurityException! As said before the code works without any problems if I pass the special JDK property jdk.io.permissionsUseCanonicalPath=true to the code. This is why I said that JDK-8164705 is causing the issue. I will write a short reproducer and post it here. The code should work with SecurityManager enabled and empty policy file, as the resource is covered by the rule (everything below code source). Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Dawid Weiss [mailto:dawid.weiss at gmail.com] > Sent: Monday, October 17, 2016 9:26 AM > To: Uwe Schindler > Cc: dev at lucene.apache.org; Dalibor Topic ; > Balchandra Vaidya ; Muneer Kolarkunnu > > Subject: Re: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > Build # 18064 - Unstable! > > Yeah, this doesn't look so good. This class and the resource it tries > to access are within the same JAR file -- if I understand correctly > the JDK issue you quoted as the source of the problem, the code here > should be able to pass regardless of file restrictions/ policies? > > Dawid > > On Sun, Oct 16, 2016 at 10:09 PM, Uwe Schindler wrote: > > Hi, > > > > I reverted the Lucene builds to build Java 9 138 for now. I will later check if > this also happens with build 139, which I have to download first. I will also > debug locally. > > > > The code fails because this code hits "null" on getResource() at > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > > > > https://github.com/morfologik/morfologik- > stemming/blob/master/morfologik- > polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32 > > > > This is impossible to happen, because the dict file is in same package. I > have no idea why this only fails here and not at other places in Lucene. The > main difference looks like the use of URL instead of getResourceAsStream() > like other places in Lucene. > > > > So this seems to be a major regression in Java 9 build 140. > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: uwe at thetaphi.de > > > >> -----Original Message----- > >> From: Uwe Schindler [mailto:uwe at thetaphi.de] > >> Sent: Sunday, October 16, 2016 8:38 PM > >> To: dev at lucene.apache.org > >> Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > >> Kolarkunnu' ; 'Dawid Weiss' > >> ; dev at lucene.apache.org > >> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > >> Build # 18064 - Unstable! > >> > >> Hi, > >> > >> this seems to be a new regression in Java 9 ea build 140. Interestingly this > >> only affects 2 libraries (morphologic and commons-codec phonetic). We > use > >> loading of resources from classloaders at many places; it is unclear to me, > >> why it only fails here. I will look into the code, but this is outside of > Lucene. I > >> think it might be some crazyness like using context class loader in non- > proper > >> ways or similar. > >> > >> Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one > >> was build 138). > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> H.-H.-Meier-Allee 63, D-28213 Bremen > >> http://www.thetaphi.de > >> eMail: uwe at thetaphi.de > >> > >> > -----Original Message----- > >> > From: Policeman Jenkins Server [mailto:jenkins at thetaphi.de] > >> > Sent: Sunday, October 16, 2016 8:20 PM > >> > To: dev at lucene.apache.org > >> > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > Build > >> # > >> > 18064 - Unstable! > >> > Importance: Low > >> > > >> > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/ > >> > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC > >> > > >> > 24 tests failed. > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > >> > ens > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9 > >> > A]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > >> > ens(TestMorfologikAnalyzer.java:44) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:55EF45E52DB9129 > >> > B]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom( > >> > TestMorfologikAnalyzer.java:201) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:88AC75BEA84F2F4 > >> > D]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase(Test > >> > MorfologikAnalyzer.java:111) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > >> > tems > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:AE90F581CE44382 > >> > ]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > >> > tems(TestMorfologikAnalyzer.java:90) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > >> > okens > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:E0465B37C534996 > >> > 1]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > >> > okens(TestMorfologikAnalyzer.java:54) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > >> > AttrTokens > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:2B64B15327EFD51 > >> > F]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer$1.(Test > >> > MorfologikAnalyzer.java:174) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > >> > AttrTokens(TestMorfologikAnalyzer.java:174) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > >> > ute > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:86D7B88D4CD696 > >> > 2B]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >> > Analyzer.java:52) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >> > zer(TestMorfologikAnalyzer.java:39) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > >> > ute(TestMorfologikAnalyzer.java:148) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 39 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > >> > ltDictionary > >> > > >> > Error Message: > >> > Could not read dictionary data. > >> > > >> > Stack Trace: > >> > java.lang.RuntimeException: Could not read dictionary data. > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:77E7676752C75E7 > >> > 1]:0) > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.inform(Morfo > >> > logikFilterFactory.java:85) > >> > at > >> > > >> > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > >> > ltDictionary(TestMorfologikFilterFactory.java:56) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.io.IOException: Polish dictionary resource not found. > >> > at > >> > > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >> > ... 38 more > >> > > >> > > >> > FAILED: > >> > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers > >> > > >> > Error Message: > >> > > >> > > >> > Stack Trace: > >> > java.lang.ExceptionInInitializerError > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E3117A948221F6D > >> > C]:0) > >> > at > >> > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >> > ents(TestBeiderMorseFilter.java:49) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:358) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:388) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers(Tes > >> > tBeiderMorseFilter.java:101) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.lang.IllegalArgumentException: Unable to resolve > required > >> > resource: org/apache/commons/codec/language/bm/ash_languages.txt > >> > at > >> > > >> > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > >> > java:175) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.Languages.(Languages.java: > >> > 161) > >> > ... 45 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > >> > ute > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:D36838D48CB19E1 > >> > 4]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > >> > ute(TestBeiderMorseFilter.java:128) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:1C94D74A60E4B53 > >> > F]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >> > ents(TestBeiderMorseFilter.java:49) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:511) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:434) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom(Test > >> > BeiderMorseFilter.java:109) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > >> > A]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$3.createCompon > >> > ents(TestBeiderMorseFilter.java:86) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:358) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:388) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet( > >> > TestBeiderMorseFilter.java:91) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > >> > D]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$4.createCompon > >> > ents(TestBeiderMorseFilter.java:117) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:358) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:368) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > >> > okenStreamTestCase.java:429) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm(T > >> > estBeiderMorseFilter.java:120) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:35CB4BA05D8C5C > >> > AC]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >> > ents(TestBeiderMorseFilter.java:49) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:358) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:388) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage(T > >> > estBeiderMorseFilter.java:63) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > >> > > >> > Error Message: > >> > > >> > > >> > Stack Trace: > >> > java.lang.ExceptionInInitializerError > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:53005C69E96A5D3 > >> > C]:0) > >> > at > >> > org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >> > MorseFilterFactory.java:56) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > >> > (TestBeiderMorseFilterFactory.java:29) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.lang.IllegalArgumentException: Unable to resolve > required > >> > resource: org/apache/commons/codec/language/bm/ash_languages.txt > >> > at > >> > > >> > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > >> > java:175) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.Languages.(Languages.java: > >> > 161) > >> > ... 41 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > >> > ns > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:CCFC21040ED1AB3 > >> > A]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >> > MorseFilterFactory.java:56) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > >> > ns(TestBeiderMorseFilterFactory.java:54) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > >> > ageSet > >> > > >> > Error Message: > >> > Could not initialize class org.apache.commons.codec.language.bm.Lang > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > >> > A]:0) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >> > MorseFilterFactory.java:56) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > >> > ageSet(TestBeiderMorseFilterFactory.java:41) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > >> > Arguments > >> > > >> > Error Message: > >> > Unexpected exception type, expected IllegalArgumentException > >> > > >> > Stack Trace: > >> > junit.framework.AssertionFailedError: Unexpected exception type, > >> expected > >> > IllegalArgumentException > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8BC3C48769987F7 > >> > B]:0) > >> > at > >> > > >> > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > >> > 681) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > >> > Arguments(TestBeiderMorseFilterFactory.java:65) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.bm.Lang > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:317) > >> > at > >> > > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >> > ine.java:293) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >> > MorseFilterFactory.java:56) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.lambda$t > >> > estBogusArguments$0(TestBeiderMorseFilterFactory.java:66) > >> > at > >> > > >> > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > >> > 676) > >> > ... 37 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > >> > mptyTerm > >> > > >> > Error Message: > >> > > >> > > >> > Stack Trace: > >> > java.lang.ExceptionInInitializerError > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > >> > D]:0) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$3.cre > >> > ateComponents(TestDaitchMokotoffSoundexFilter.java:80) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:358) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >> > eTokenStreamTestCase.java:368) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > >> > okenStreamTestCase.java:429) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > >> > mptyTerm(TestDaitchMokotoffSoundexFilter.java:83) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >> > estSuites.java:54) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > Caused by: java.lang.IllegalArgumentException: Unable to load resource: > >> > org/apache/commons/codec/language/dmrules.txt > >> > at > >> > > >> > org.apache.commons.codec.language.DaitchMokotoffSoundex.(Daitc > >> > hMokotoffSoundex.java:231) > >> > ... 44 more > >> > > >> > > >> > FAILED: > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >> > andomStrings > >> > > >> > Error Message: > >> > Could not initialize class > >> > org.apache.commons.codec.language.DaitchMokotoffSoundex > >> > > >> > Stack Trace: > >> > java.lang.NoClassDefFoundError: Could not initialize class > >> > org.apache.commons.codec.language.DaitchMokotoffSoundex > >> > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB7280547 > >> > 9]:0) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > >> > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > >> > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:511) > >> > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:434) > >> > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >> > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > at java.lang.reflect.Method.invoke(java.base at 9- > >> > ea/Method.java:535) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >> > dRunner.java:1764) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >> > mizedRunner.java:871) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >> > mizedRunner.java:907) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >> > omizedRunner.java:921) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >> > SetupTeardownChained.java:49) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >> > eadAndTestName.java:48) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAfterMaxFailures.java:64) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >> > un(ThreadLeakControl.java:367) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >> > (ThreadLeakControl.java:809) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >> > eakControl.java:460) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >> > domizedRunner.java:880) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >> > mizedRunner.java:781) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >> > mizedRunner.java:816) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >> > mizedRunner.java:827) > >> > at > >> > > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >> > terRule.java:45) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >> > ssName.java:41) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >> > > hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >> > mentAdapter.java:36) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >> > rtionsRequired.java:53) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >> > java:47) > >> > at > >> > > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >> > gnoreAft > >> > > >> > [...truncated too long message...] > >> > > >> > dtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB72805479]:0) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > >> > ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > >> > [junit4] > at > >> > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >> > BaseTokenStreamTestCase.java:392) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:511) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >> > seTokenStreamTestCase.java:434) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >> > andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > [junit4] > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > [junit4] > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > [junit4] 2> NOTE: reproduce with: ant test - > >> > Dtestcase=TestDaitchMokotoffSoundexFilter - > >> Dtests.method=testAlgorithms > >> > -Dtests.seed=6ED8F245D184034C -Dtests.multiplier=3 -Dtests.slow=true > - > >> > Dtests.locale=ps -Dtests.timezone=America/Antigua -Dtests.asserts=true > - > >> > Dtests.file.encoding=UTF-8 > >> > [junit4] ERROR 0.00s J0 | > >> TestDaitchMokotoffSoundexFilter.testAlgorithms > >> > <<< > >> > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > >> > initialize class > >> org.apache.commons.codec.language.DaitchMokotoffSoundex > >> > [junit4] > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:3823E49E787418B > >> > 7]:0) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.asser > >> > tAlgorithm(TestDaitchMokotoffSoundexFilter.java:46) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testAl > >> > gorithms(TestDaitchMokotoffSoundexFilter.java:35) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > [junit4] > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > [junit4] > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > [junit4] 2> NOTE: test params are: codec=Lucene70, > >> sim=ClassicSimilarity, > >> > locale=ps, timezone=America/Antigua > >> > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > >> (32- > >> > bit)/cpus=12,threads=1,free=47297104,total=81526784 > >> > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > >> > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter] > >> > [junit4] Completed [5/8 (3!)] on J0 in 0.04s, 3 tests, 3 errors <<< > FAILURES! > >> > > >> > [...truncated 1 lines...] > >> > [junit4] Suite: > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >> > y > >> > [junit4] 2> NOTE: reproduce with: ant test - > >> > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > >> > Dtests.method=testDefaults -Dtests.seed=6ED8F245D184034C - > >> > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > >> > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > >> > Dtests.file.encoding=UTF-8 > >> > [junit4] ERROR 0.02s J0 | > >> > TestDaitchMokotoffSoundexFilterFactory.testDefaults <<< > >> > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > >> > initialize class > >> org.apache.commons.codec.language.DaitchMokotoffSoundex > >> > [junit4] > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:C17CBC6FF981506 > >> > 0]:0) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > >> > eate(DaitchMokotoffSoundexFilterFactory.java:63) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >> > y.testDefaults(TestDaitchMokotoffSoundexFilterFactory.java:36) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > [junit4] > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > [junit4] > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > [junit4] 2> NOTE: reproduce with: ant test - > >> > Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > >> > Dtests.method=testSettingInject -Dtests.seed=6ED8F245D184034C - > >> > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > >> > Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > >> > Dtests.file.encoding=UTF-8 > >> > [junit4] ERROR 0.00s J0 | > >> > TestDaitchMokotoffSoundexFilterFactory.testSettingInject <<< > >> > [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could not > >> > initialize class > >> org.apache.commons.codec.language.DaitchMokotoffSoundex > >> > [junit4] > at > >> > > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8B47767F15CB356 > >> > 1]:0) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >> > tchMokotoffSoundexFilter.java:38) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > >> > eate(DaitchMokotoffSoundexFilterFactory.java:63) > >> > [junit4] > at > >> > > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >> > y.testSettingInject(TestDaitchMokotoffSoundexFilterFactory.java:49) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > [junit4] > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > [junit4] > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {}, > >> > docValues:{}, maxPointsInLeafNode=1560, > >> > maxMBSortInHeap=6.407822741000916, sim=ClassicSimilarity, > locale=guz, > >> > timezone=America/Indiana/Marengo > >> > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > >> (32- > >> > bit)/cpus=12,threads=1,free=103729528,total=115605504 > >> > [junit4] 2> NOTE: All tests run in this JVM: [TestPhoneticFilterFactory, > >> > TestDoubleMetaphoneFilterFactory, TestDaitchMokotoffSoundexFilter, > >> > TestDaitchMokotoffSoundexFilterFactory] > >> > [junit4] Completed [6/8 (4!)] on J0 in 0.06s, 3 tests, 2 errors <<< > FAILURES! > >> > > >> > [...truncated 1966 lines...] > >> > [junit4] Suite: > >> org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser > >> > [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestHtmlParser > - > >> > Dtests.method=testEntities -Dtests.seed=7EC5D3E55917236B - > >> > Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es-PH - > >> > Dtests.timezone=Canada/Mountain -Dtests.asserts=true - > >> > Dtests.file.encoding=ISO-8859-1 > >> > [junit4] ERROR 0.01s J1 | TestHtmlParser.testEntities <<< > >> > [junit4] > Throwable #1: java.lang.ExceptionInInitializerError > >> > [junit4] > at > >> > > >> > __randomizedtesting.SeedInfo.seed([7EC5D3E55917236B:EDC240C50B38B8B > >> > 2]:0) > >> > [junit4] > at > >> > > org.cyberneko.html.HTMLScanner.scanEntityRef(HTMLScanner.java:1405) > >> > [junit4] > at > >> > > >> > org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java: > >> > 2007) > >> > [junit4] > at > >> > > org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:918) > >> > [junit4] > at > >> > > >> > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) > >> > [junit4] > at > >> > > >> > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) > >> > [junit4] > at org.apache.xerces.parsers.XMLParser.parse(Unknown > >> > Source) > >> > [junit4] > at > >> > org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > >> > [junit4] > at > >> > > >> > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > >> > (DemoHTMLParser.java:140) > >> > [junit4] > at > >> > > >> > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > >> > (DemoHTMLParser.java:51) > >> > [junit4] > at > >> > > >> > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser.testEntities(Test > >> > HtmlParser.java:37) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >> > ea/Native Method) > >> > [junit4] > at > >> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >> > ea/NativeMethodAccessorImpl.java:62) > >> > [junit4] > at > >> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >> > ea/DelegatingMethodAccessorImpl.java:43) > >> > [junit4] > at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >> > [junit4] > Caused by: java.lang.NullPointerException: inStream > >> parameter > >> > is null > >> > [junit4] > at java.util.Objects.requireNonNull(java.base at 9- > >> > ea/Objects.java:246) > >> > [junit4] > at java.util.Properties.load(java.base at 9- > >> > ea/Properties.java:364) > >> > [junit4] > at > >> > org.cyberneko.html.HTMLEntities.load0(HTMLEntities.java:99) > >> > [junit4] > at > >> > org.cyberneko.html.HTMLEntities.(HTMLEntities.java:52) > >> > [junit4] > ... 46 more > >> > [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70), > >> > sim=RandomSimilarity(queryNorm=false): {}, locale=es-PH, > >> > timezone=Canada/Mountain > >> > [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9-ea > >> (32- > >> > bit)/cpus=12,threads=1,free=47165080,total=81526784 > >> > [junit4] 2> NOTE: All tests run in this JVM: [SearchWithSortTaskTest, > >> > TestHtmlParser] > >> > [junit4] Completed [4/18 (1!)] on J1 in 0.10s, 12 tests, 1 error <<< > >> FAILURES! > >> > > >> > [...truncated 56873 lines...] > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > >> For additional commands, e-mail: dev-help at lucene.apache.org > > From Alan.Bateman at oracle.com Mon Oct 17 17:08:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Oct 2016 18:08:00 +0100 Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable! In-Reply-To: <00dc01d22870$53ba1d40$fb2e57c0$@apache.org> References: <1015461895.91.1476642111617.JavaMail.jenkins@serv1> <002b01d227dc$5eff3e40$1cfdbac0$@thetaphi.de> <003401d227e9$40cebec0$c26c3c40$@thetaphi.de> <00dc01d22870$53ba1d40$fb2e57c0$@apache.org> Message-ID: <7f253a8e-70de-a460-72e8-40fdf0e7feac@oracle.com> On 17/10/2016 13:16, Uwe Schindler wrote: > Hi, > > yes I checked more already: The issue is caused by the mentioned change (canonicalize of FilePermission). According to the docs of SecurityManager and FilePermission, code should always be able to read stuff below the classpath where the code was loaded from (in our case its part of a JAR file). So there is no need to add permissions for this, it should work automatically. > > So the following code must work without any extra permissions: > > URL url = this.getClass().getResource("somefilenexttoclassfile"); > InputStream is = url.openStream(); > > Interestingly the first line already returns "null", means "resource not found", you don't get any SecurityException! As said before the code works without any problems if I pass the special JDK property jdk.io.permissionsUseCanonicalPath=true to the code. This is why I said that JDK-8164705 is causing the issue. > > I will write a short reproducer and post it here. The code should work with SecurityManager enabled and empty policy file, as the resource is covered by the rule (everything below code source). > The getResourceXXX methods are specified to return null when denied by the security manager so you can't distinguish it from not found. If you can get trace output with -Djava.security.debug=failure,access then it might help diagnose this. It's probably best to follow-up on security-dev rather than jdk9-dev as that is the mailing list where permission classes are maintained. -Alan From sean.mullan at oracle.com Mon Oct 17 17:35:06 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Oct 2016 13:35:06 -0400 Subject: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!) In-Reply-To: <003e01d227fa$00cb81d0$02628570$@apache.org> References: <003701d227f4$e7a41780$b6ec4680$@apache.org> <003e01d227fa$00cb81d0$02628570$@apache.org> Message-ID: <17071e2d-788a-9dad-55ef-f2fa4c59c929@oracle.com> Weijun Wang is the best person to respond as he is the RE of JDK-8164705 - right now it is the middle of the night for him, but I would expect a response from him once he comes online. --Sean On 10/16/2016 06:09 PM, Uwe Schindler wrote: > Hi again, > > with jdk.io.permissionsUseCanonicalPath=true it also works, so it is related to the new FilePermission code, so my first guess was true, the issue is JDK-8164705. > > Uwe > >> > (I cc'ed jdk-dev at openjdk, reader there please read the previous mails >> > below, too). >> > >> > I analyzed the problem, although I don't know exactly why it happens: >> > - On Windows it does not happen on my machine (no idea why!) >> > - On Linux it happens when tests are running with security manager (this is >> > the default for Lucene and Jenkins does this) >> > - On Linux it does not happen if I run Lucene tests with "- >> > Dtests.useSecurityManager=false" >> > >> > This makes me think it is related to this: "Remove pathname canonicalization >> > from FilePermission" (https://bugs.openjdk.java.net/browse/JDK-8164705) >> > >> > What seems to happen: The code calls Class.getResource to get back an URL. >> > As the JAR file is somehow outside of the FilePermissions given to the test >> > suite, it seems to fail. Maybe because some of the checks failed, >> > Class.getResource then returns a null reference, because it was not able to >> > access the JAR file. >> > >> > Were there some changes related to this: URLClassLoader and FilePermission >> > checks? >> > >> > How should we proceed? From uschindler at apache.org Mon Oct 17 17:44:05 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 17 Oct 2016 19:44:05 +0200 Subject: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!) In-Reply-To: <68e97a08-f956-5796-3dea-ead52cad1422@oracle.com> References: <003701d227f4$e7a41780$b6ec4680$@apache.org> <003e01d227fa$00cb81d0$02628570$@apache.org> <68e97a08-f956-5796-3dea-ead52cad1422@oracle.com> Message-ID: <016501d2289e$10d7d610$32878230$@apache.org> Hi, we already had off-list contact, initiated by Rory O'Donnel - thanks! The issue was indeed caused by symlinks. The issue here: The Jenkins server where the tests are running had a home directory that was symlinked somewhere else. All file paths during tests runs and also JAR files had the "correct" (canonical path). But the homedir was defined with the alternate, symlinked "old" path in /etc/passwd. Effect was that the test's policy file referring to the IVY cache in ~/.ivy/cache for loading JAR files used the path extracted from ${user.home}. Of course this broke. I am sure this will hit many people, so I have some suggestions how to solve this: In short, when parsing policy files and FilePermissions inside, just "expand" the symlink to be canonic and add *both* (the symlink and the canonic path) as 2 separate FilePermissions to the collection. This spares the runtime check on every file access but still catches all "known" paths. In addition, there is also a "bug" in the security permissions system that made the above extra permission needed. We have some third party JARs, that use Class#getResource() to load their own resources. But as getResource does not document any security exceptions or other implications, almost all code out there does not wrap with doPrivileged(). This very old bug required the extra permission to the lib/ folder. The workaround just broke. Here is what I wrote in the private discussion: --snip-- > Yes, this is where the problem is. > > So it looks like the permission is granted in a policy file instead of being > granted by the class loader itself. In this case, the path of the permission > must match how you access that file. Yes. I think the problem is that the 3rd party JAR file does not have a doPrivileged block around the getResource/openStream part, so ist running with the permissions of the calling code (a different JAR file - the test runner). IMHO, this is one of the really strange things of the security model in Java and most people do it wrong. Especially it is not clear from Class#getResource that this can be affected by any security policy! It does not even throw a declared SecurityException (because it is swallowed). We have the extra path in our policy file for exactly that reason (to work around issues in 3rd party JARs) that don't wrap this into doPrivileged! > I'll think about your suggestion. However, can you guarantee the code always > accesses the file using the canonicalized path? For example, suppose the > actual file is /x, both /a and /b symlink to it, and you grant the permission on > /a in a policy file. Even if I canonicalize /a to /x and grant permissions on > both /a and /x, you will still see a failure if the code access /b. I am coming from the full text search engine people. I see the issue that you have with getting the canonical name on every file access (this slows down!). The approach the full text people use is to make "synonyms" of terms and index all of them. Somebody searching for the term will find it under any name. To be ported over to your issue: Instead of doing the canonicalized check on every access, just put *both* known file names into the "search index" (in your case policy file). Means: When parsing the policy file, create 2 file permissions: One as given in the policy and an additional one with the canonical name. This does not solve all problems, but helps around issues like the one we encountered. I changed the setup of the Jenkins machine that hit this issue first to not have a symlinked entry in /etc/passwd - instead I placed the real path there - so ${user.home} is right. I will see if the issues are gone. Nevertheless I have just brought this into your attention, so we can figure out what could get wrong on people's systems after this change. I will also figure out with my colleagues how to solve the permission checks in 3rd party jars - especially as they did not do anything wrong - why should one wrap Class#getResource() with doPrivileged?! --snip-- Maybe we can discuss the ideas on the public mailing list. Was quite hard to figure out (with lots of debugging output) until I discovered the problem. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Sean Mullan [mailto:sean.mullan at oracle.com] > Sent: Monday, October 17, 2016 7:33 PM > To: Uwe Schindler ; dev at lucene.apache.org > Cc: 'jdk9-dev' ; 'Dawid Weiss' > ; balchandra.vaidya at oracle.com > Subject: Re: Class#getResource returns null in JDK9 b140 if security manager > is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9- > ea+140) - Build # 18064 - Unstable!) > > Weijun Wang is the best person to respond as he is the RE of JDK-8164705 > - right now it is the middle of the night for him, but I would expect a > response from him once he comes online. > > --Sean > > On 10/16/2016 06:09 PM, Uwe Schindler wrote: > > Hi again, > > > > with jdk.io.permissionsUseCanonicalPath=true it also works, so it is related > to the new FilePermission code, so my first guess was true, the issue is JDK- > 8164705. > > > > Uwe > > > >> (I cc'ed jdk-dev at openjdk, reader there please read the previous mails > >> below, too). > >> > >> I analyzed the problem, although I don't know exactly why it happens: > >> - On Windows it does not happen on my machine (no idea why!) > >> - On Linux it happens when tests are running with security manager (this > is > >> the default for Lucene and Jenkins does this) > >> - On Linux it does not happen if I run Lucene tests with "- > >> Dtests.useSecurityManager=false" > >> > >> This makes me think it is related to this: "Remove pathname > canonicalization > >> from FilePermission" (https://bugs.openjdk.java.net/browse/JDK- > 8164705) > >> > >> What seems to happen: The code calls Class.getResource to get back an > URL. > >> As the JAR file is somehow outside of the FilePermissions given to the test > >> suite, it seems to fail. Maybe because some of the checks failed, > >> Class.getResource then returns a null reference, because it was not able > to > >> access the JAR file. > >> > >> Were there some changes related to this: URLClassLoader and > FilePermission > >> checks? > >> > >> How should we proceed? > >> > >> Uwe > >> > >> ----- > >> Uwe Schindler > >> uschindler at apache.org > >> ASF Member, Apache Lucene PMC / Committer > >> Bremen, Germany > >> http://lucene.apache.org/ > >> > >>> -----Original Message----- > >>> From: Uwe Schindler [mailto:uwe at thetaphi.de] > >>> Sent: Sunday, October 16, 2016 10:10 PM > >>> To: dev at lucene.apache.org > >>> Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer > >>> Kolarkunnu' ; 'Dawid Weiss' > >>> > >>> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) > - > >>> Build # 18064 - Unstable! > >>> > >>> Hi, > >>> > >>> I reverted the Lucene builds to build Java 9 138 for now. I will later check > if > >>> this also happens with build 139, which I have to download first. I will > also > >>> debug locally. > >>> > >>> The code fails because this code hits "null" on getResource() at > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>> > >>> https://github.com/morfologik/morfologik- > >>> stemming/blob/master/morfologik- > >>> > >> > polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32 > >>> > >>> This is impossible to happen, because the dict file is in same package. I > >> have > >>> no idea why this only fails here and not at other places in Lucene. The > main > >>> difference looks like the use of URL instead of getResourceAsStream() > like > >>> other places in Lucene. > >>> > >>> So this seems to be a major regression in Java 9 build 140. > >>> > >>> Uwe > >>> > >>> ----- > >>> Uwe Schindler > >>> H.-H.-Meier-Allee 63, D-28213 Bremen > >>> http://www.thetaphi.de > >>> eMail: uwe at thetaphi.de > >>> > >>>> -----Original Message----- > >>>> From: Uwe Schindler [mailto:uwe at thetaphi.de] > >>>> Sent: Sunday, October 16, 2016 8:38 PM > >>>> To: dev at lucene.apache.org > >>>> Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; > 'Muneer > >>>> Kolarkunnu' ; 'Dawid Weiss' > >>>> ; dev at lucene.apache.org > >>>> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9- > ea+140) - > >>>> Build # 18064 - Unstable! > >>>> > >>>> Hi, > >>>> > >>>> this seems to be a new regression in Java 9 ea build 140. Interestingly > this > >>>> only affects 2 libraries (morphologic and commons-codec phonetic). We > >>> use > >>>> loading of resources from classloaders at many places; it is unclear to > me, > >>>> why it only fails here. I will look into the code, but this is outside of > >> Lucene. > >>> I > >>>> think it might be some crazyness like using context class loader in non- > >>> proper > >>>> ways or similar. > >>>> > >>>> Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working > one > >>>> was build 138). > >>>> > >>>> Uwe > >>>> > >>>> ----- > >>>> Uwe Schindler > >>>> H.-H.-Meier-Allee 63, D-28213 Bremen > >>>> http://www.thetaphi.de > >>>> eMail: uwe at thetaphi.de > >>>> > >>>>> -----Original Message----- > >>>>> From: Policeman Jenkins Server [mailto:jenkins at thetaphi.de] > >>>>> Sent: Sunday, October 16, 2016 8:20 PM > >>>>> To: dev at lucene.apache.org > >>>>> Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - > >>> Build > >>>> # > >>>>> 18064 - Unstable! > >>>>> Importance: Low > >>>>> > >>>>> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master- > Linux/18064/ > >>>>> Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC > >>>>> > >>>>> 24 tests failed. > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > >>>>> ens > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9 > >>>>> A]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok > >>>>> ens(TestMorfologikAnalyzer.java:44) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:55EF45E52DB9129 > >>>>> B]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom( > >>>>> TestMorfologikAnalyzer.java:201) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:88AC75BEA84F2F4 > >>>>> D]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testCase(Test > >>>>> MorfologikAnalyzer.java:111) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > >>>>> tems > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:AE90F581CE44382 > >>>>> ]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testLeftoverS > >>>>> tems(TestMorfologikAnalyzer.java:90) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > >>>>> okens > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:E0465B37C534996 > >>>>> 1]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleT > >>>>> okens(TestMorfologikAnalyzer.java:54) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > >>>>> AttrTokens > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:2B64B15327EFD51 > >>>>> F]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer$1.(Test > >>>>> MorfologikAnalyzer.java:174) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testKeyword > >>>>> AttrTokens(TestMorfologikAnalyzer.java:174) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > >>>>> ute > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:86D7B88D4CD696 > >>>>> 2B]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik > >>>>> Analyzer.java:52) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly > >>>>> zer(TestMorfologikAnalyzer.java:39) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testPOSAttrib > >>>>> ute(TestMorfologikAnalyzer.java:148) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 39 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > >>>>> ltDictionary > >>>>> > >>>>> Error Message: > >>>>> Could not read dictionary data. > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.RuntimeException: Could not read dictionary data. > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:77E7676752C75E7 > >>>>> 1]:0) > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.MorfologikFilterFactory.inform(Morfo > >>>>> logikFilterFactory.java:85) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.morfologik.TestMorfologikFilterFactory.testDefau > >>>>> ltDictionary(TestMorfologikFilterFactory.java:56) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.io.IOException: Polish dictionary resource not found. > >>>>> at > >>>>> > >>> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) > >>>>> ... 38 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >> org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers > >>>>> > >>>>> Error Message: > >>>>> > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.ExceptionInInitializerError > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E3117A948221F6D > >>>>> C]:0) > >>>>> at > >>>>> org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >>>>> ents(TestBeiderMorseFilter.java:49) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:358) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:388) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testNumbers(Tes > >>>>> tBeiderMorseFilter.java:101) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.lang.IllegalArgumentException: Unable to resolve > >>> required > >>>>> resource: > >> org/apache/commons/codec/language/bm/ash_languages.txt > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > >>>>> java:175) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.Languages.(Languages.java: > >>>>> 161) > >>>>> ... 45 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > >>>>> ute > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:D36838D48CB19E1 > >>>>> 4]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testCustomAttrib > >>>>> ute(TestBeiderMorseFilter.java:128) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:1C94D74A60E4B53 > >>>>> F]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >>>>> ents(TestBeiderMorseFilter.java:49) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:511) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:434) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testRandom(Test > >>>>> BeiderMorseFilter.java:109) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > >>>>> A]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$3.createCompon > >>>>> ents(TestBeiderMorseFilter.java:86) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:358) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:388) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testLanguageSet( > >>>>> TestBeiderMorseFilter.java:91) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > >>>>> D]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$4.createCompon > >>>>> ents(TestBeiderMorseFilter.java:117) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:358) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:368) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > >>>>> okenStreamTestCase.java:429) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testEmptyTerm(T > >>>>> estBeiderMorseFilter.java:120) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:35CB4BA05D8C5C > >>>>> AC]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter$1.createCompon > >>>>> ents(TestBeiderMorseFilter.java:49) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:358) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:388) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilter.testBasicUsage(T > >>>>> estBeiderMorseFilter.java:63) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > >>>>> > >>>>> Error Message: > >>>>> > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.ExceptionInInitializerError > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:53005C69E96A5D3 > >>>>> C]:0) > >>>>> at > >>>>> org.apache.commons.codec.language.bm.Lang.(Lang.java:102) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >>>>> MorseFilterFactory.java:56) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBasics > >>>>> (TestBeiderMorseFilterFactory.java:29) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.lang.IllegalArgumentException: Unable to resolve > >>> required > >>>>> resource: > >> org/apache/commons/codec/language/bm/ash_languages.txt > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.Languages.getInstance(Languages. > >>>>> java:175) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.Languages.(Languages.java: > >>>>> 161) > >>>>> ... 41 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > >>>>> ns > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:CCFC21040ED1AB3 > >>>>> A]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >>>>> MorseFilterFactory.java:56) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testOptio > >>>>> ns(TestBeiderMorseFilterFactory.java:54) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > >>>>> ageSet > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > org.apache.commons.codec.language.bm.Lang > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:6D67491F0653B4C > >>>>> A]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >>>>> MorseFilterFactory.java:56) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testLangu > >>>>> ageSet(TestBeiderMorseFilterFactory.java:41) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > >>>>> Arguments > >>>>> > >>>>> Error Message: > >>>>> Unexpected exception type, expected IllegalArgumentException > >>>>> > >>>>> Stack Trace: > >>>>> junit.framework.AssertionFailedError: Unexpected exception type, > >>>> expected > >>>>> IllegalArgumentException > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8BC3C48769987F7 > >>>>> B]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > >>>>> 681) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.testBogus > >>>>> Arguments(TestBeiderMorseFilterFactory.java:65) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.bm.Lang > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:317) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.bm.PhoneticEngine.(PhoneticEng > >>>>> ine.java:293) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.BeiderMorseFilterFactory.(Beider > >>>>> MorseFilterFactory.java:56) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestBeiderMorseFilterFactory.lambda$t > >>>>> estBogusArguments$0(TestBeiderMorseFilterFactory.java:66) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2 > >>>>> 676) > >>>>> ... 37 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > >>>>> mptyTerm > >>>>> > >>>>> Error Message: > >>>>> > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.ExceptionInInitializerError > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:ACE4AA1785957C5 > >>>>> D]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$3.cre > >>>>> ateComponents(TestDaitchMokotoffSoundexFilter.java:80) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:358) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertAnalyzesTo(Bas > >>>>> eTokenStreamTestCase.java:368) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkOneTerm(BaseT > >>>>> okenStreamTestCase.java:429) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testE > >>>>> mptyTerm(TestDaitchMokotoffSoundexFilter.java:83) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreT > >>>>> estSuites.java:54) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at java.lang.Thread.run(java.base at 9-ea/Thread.java:843) > >>>>> Caused by: java.lang.IllegalArgumentException: Unable to load > >> resource: > >>>>> org/apache/commons/codec/language/dmrules.txt > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.commons.codec.language.DaitchMokotoffSoundex.(Daitc > >>>>> hMokotoffSoundex.java:231) > >>>>> ... 44 more > >>>>> > >>>>> > >>>>> FAILED: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >>>>> andomStrings > >>>>> > >>>>> Error Message: > >>>>> Could not initialize class > >>>>> org.apache.commons.codec.language.DaitchMokotoffSoundex > >>>>> > >>>>> Stack Trace: > >>>>> java.lang.NoClassDefFoundError: Could not initialize class > >>>>> org.apache.commons.codec.language.DaitchMokotoffSoundex > >>>>> at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB7280547 > >>>>> 9]:0) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > >>>>> ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > >>>>> at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:511) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:434) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >>>>> andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> at java.lang.reflect.Method.invoke(java.base at 9- > >>>>> ea/Method.java:535) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize > >>>>> dRunner.java:1764) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando > >>>>> mizedRunner.java:871) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando > >>>>> mizedRunner.java:907) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand > >>>>> omizedRunner.java:921) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule > >>>>> SetupTeardownChained.java:49) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr > >>>>> eadAndTestName.java:48) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAfterMaxFailures.java:64) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r > >>>>> un(ThreadLeakControl.java:367) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask > >>>>> (ThreadLeakControl.java:809) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL > >>>>> eakControl.java:460) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran > >>>>> domizedRunner.java:880) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando > >>>>> mizedRunner.java:781) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando > >>>>> mizedRunner.java:816) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando > >>>>> mizedRunner.java:827) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf > >>>>> terRule.java:45) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla > >>>>> ssName.java:41) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet > >>>>> > >> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State > >>>>> mentAdapter.java:36) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAsse > >>>>> rtionsRequired.java:53) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure. > >>>>> java:47) > >>>>> at > >>>>> > >>>> > >>> > >> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI > >>>>> gnoreAft > >>>>> > >>>>> [...truncated too long message...] > >>>>> > >>>>> dtesting.SeedInfo.seed([6ED8F245D184034C:E651F2FB72805479]:0) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter$1.cre > >>>>> ateComponents(TestDaitchMokotoffSoundexFilter.java:56) > >>>>> [junit4] > at > >>>>> org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:198) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkResetException( > >>>>> BaseTokenStreamTestCase.java:392) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:511) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(Ba > >>>>> seTokenStreamTestCase.java:434) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testR > >>>>> andomStrings(TestDaitchMokotoffSoundexFilter.java:60) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> [junit4] > at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> [junit4] > at java.lang.Thread.run(java.base at 9- > >>> ea/Thread.java:843) > >>>>> [junit4] 2> NOTE: reproduce with: ant test - > >>>>> Dtestcase=TestDaitchMokotoffSoundexFilter - > >>>> Dtests.method=testAlgorithms > >>>>> -Dtests.seed=6ED8F245D184034C -Dtests.multiplier=3 - > Dtests.slow=true > >> - > >>>>> Dtests.locale=ps -Dtests.timezone=America/Antigua - > >> Dtests.asserts=true - > >>>>> Dtests.file.encoding=UTF-8 > >>>>> [junit4] ERROR 0.00s J0 | > >>>> TestDaitchMokotoffSoundexFilter.testAlgorithms > >>>>> <<< > >>>>> [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could > not > >>>>> initialize class > >>>> org.apache.commons.codec.language.DaitchMokotoffSoundex > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:3823E49E787418B > >>>>> 7]:0) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.asser > >>>>> tAlgorithm(TestDaitchMokotoffSoundexFilter.java:46) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilter.testAl > >>>>> gorithms(TestDaitchMokotoffSoundexFilter.java:35) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> [junit4] > at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> [junit4] > at java.lang.Thread.run(java.base at 9- > >>> ea/Thread.java:843) > >>>>> [junit4] 2> NOTE: test params are: codec=Lucene70, > >>>> sim=ClassicSimilarity, > >>>>> locale=ps, timezone=America/Antigua > >>>>> [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9- > ea > >>>> (32- > >>>>> bit)/cpus=12,threads=1,free=47297104,total=81526784 > >>>>> [junit4] 2> NOTE: All tests run in this JVM: > [TestPhoneticFilterFactory, > >>>>> TestDoubleMetaphoneFilterFactory, > TestDaitchMokotoffSoundexFilter] > >>>>> [junit4] Completed [5/8 (3!)] on J0 in 0.04s, 3 tests, 3 errors <<< > >>> FAILURES! > >>>>> > >>>>> [...truncated 1 lines...] > >>>>> [junit4] Suite: > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >>>>> y > >>>>> [junit4] 2> NOTE: reproduce with: ant test - > >>>>> Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > >>>>> Dtests.method=testDefaults -Dtests.seed=6ED8F245D184034C - > >>>>> Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > >>>>> Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > >>>>> Dtests.file.encoding=UTF-8 > >>>>> [junit4] ERROR 0.02s J0 | > >>>>> TestDaitchMokotoffSoundexFilterFactory.testDefaults <<< > >>>>> [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could > not > >>>>> initialize class > >>>> org.apache.commons.codec.language.DaitchMokotoffSoundex > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:C17CBC6FF981506 > >>>>> 0]:0) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > >>>>> eate(DaitchMokotoffSoundexFilterFactory.java:63) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >>>>> y.testDefaults(TestDaitchMokotoffSoundexFilterFactory.java:36) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> [junit4] > at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> [junit4] > at java.lang.Thread.run(java.base at 9- > >>> ea/Thread.java:843) > >>>>> [junit4] 2> NOTE: reproduce with: ant test - > >>>>> Dtestcase=TestDaitchMokotoffSoundexFilterFactory - > >>>>> Dtests.method=testSettingInject -Dtests.seed=6ED8F245D184034C - > >>>>> Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=guz - > >>>>> Dtests.timezone=America/Indiana/Marengo -Dtests.asserts=true - > >>>>> Dtests.file.encoding=UTF-8 > >>>>> [junit4] ERROR 0.00s J0 | > >>>>> TestDaitchMokotoffSoundexFilterFactory.testSettingInject <<< > >>>>> [junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could > not > >>>>> initialize class > >>>> org.apache.commons.codec.language.DaitchMokotoffSoundex > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([6ED8F245D184034C:8B47767F15CB356 > >>>>> 1]:0) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilter.(Dai > >>>>> tchMokotoffSoundexFilter.java:38) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.DaitchMokotoffSoundexFilterFactory.cr > >>>>> eate(DaitchMokotoffSoundexFilterFactory.java:63) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.analysis.phonetic.TestDaitchMokotoffSoundexFilterFactor > >>>>> y.testSettingInject(TestDaitchMokotoffSoundexFilterFactory.java:49) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> [junit4] > at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> [junit4] > at java.lang.Thread.run(java.base at 9- > >>> ea/Thread.java:843) > >>>>> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {}, > >>>>> docValues:{}, maxPointsInLeafNode=1560, > >>>>> maxMBSortInHeap=6.407822741000916, sim=ClassicSimilarity, > >>> locale=guz, > >>>>> timezone=America/Indiana/Marengo > >>>>> [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9- > ea > >>>> (32- > >>>>> bit)/cpus=12,threads=1,free=103729528,total=115605504 > >>>>> [junit4] 2> NOTE: All tests run in this JVM: > [TestPhoneticFilterFactory, > >>>>> TestDoubleMetaphoneFilterFactory, > TestDaitchMokotoffSoundexFilter, > >>>>> TestDaitchMokotoffSoundexFilterFactory] > >>>>> [junit4] Completed [6/8 (4!)] on J0 in 0.06s, 3 tests, 2 errors <<< > >>> FAILURES! > >>>>> > >>>>> [...truncated 1966 lines...] > >>>>> [junit4] Suite: > >>>> org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser > >>>>> [junit4] 2> NOTE: reproduce with: ant test - > >> Dtestcase=TestHtmlParser - > >>>>> Dtests.method=testEntities -Dtests.seed=7EC5D3E55917236B - > >>>>> Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=es-PH - > >>>>> Dtests.timezone=Canada/Mountain -Dtests.asserts=true - > >>>>> Dtests.file.encoding=ISO-8859-1 > >>>>> [junit4] ERROR 0.01s J1 | TestHtmlParser.testEntities <<< > >>>>> [junit4] > Throwable #1: java.lang.ExceptionInInitializerError > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > __randomizedtesting.SeedInfo.seed([7EC5D3E55917236B:EDC240C50B38B8B > >>>>> 2]:0) > >>>>> [junit4] > at > >>>>> > >> org.cyberneko.html.HTMLScanner.scanEntityRef(HTMLScanner.java:1405) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java: > >>>>> 2007) > >>>>> [junit4] > at > >>>>> > >>> > org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:918) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) > >>>>> [junit4] > at > >>> org.apache.xerces.parsers.XMLParser.parse(Unknown > >>>>> Source) > >>>>> [junit4] > at > >>>>> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > >>>>> (DemoHTMLParser.java:140) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.benchmark.byTask.feeds.DemoHTMLParser$Parser. > >>>>> (DemoHTMLParser.java:51) > >>>>> [junit4] > at > >>>>> > >>>> > >>> > >> > org.apache.lucene.benchmark.byTask.feeds.TestHtmlParser.testEntities(Test > >>>>> HtmlParser.java:37) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9- > >>>>> ea/Native Method) > >>>>> [junit4] > at > >>>>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/NativeMethodAccessorImpl.java:62) > >>>>> [junit4] > at > >>>>> > >> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9- > >>>>> ea/DelegatingMethodAccessorImpl.java:43) > >>>>> [junit4] > at java.lang.Thread.run(java.base at 9- > >>> ea/Thread.java:843) > >>>>> [junit4] > Caused by: java.lang.NullPointerException: inStream > >>>> parameter > >>>>> is null > >>>>> [junit4] > at java.util.Objects.requireNonNull(java.base at 9- > >>>>> ea/Objects.java:246) > >>>>> [junit4] > at java.util.Properties.load(java.base at 9- > >>>>> ea/Properties.java:364) > >>>>> [junit4] > at > >>>>> org.cyberneko.html.HTMLEntities.load0(HTMLEntities.java:99) > >>>>> [junit4] > at > >>>>> org.cyberneko.html.HTMLEntities.(HTMLEntities.java:52) > >>>>> [junit4] > ... 46 more > >>>>> [junit4] 2> NOTE: test params are: codec=Asserting(Lucene70), > >>>>> sim=RandomSimilarity(queryNorm=false): {}, locale=es-PH, > >>>>> timezone=Canada/Mountain > >>>>> [junit4] 2> NOTE: Linux 4.4.0-36-generic i386/Oracle Corporation 9- > ea > >>>> (32- > >>>>> bit)/cpus=12,threads=1,free=47165080,total=81526784 > >>>>> [junit4] 2> NOTE: All tests run in this JVM: [SearchWithSortTaskTest, > >>>>> TestHtmlParser] > >>>>> [junit4] Completed [4/18 (1!)] on J1 in 0.10s, 12 tests, 1 error <<< > >>>> FAILURES! > >>>>> > >>>>> [...truncated 56873 lines...] > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > >>>> For additional commands, e-mail: dev-help at lucene.apache.org > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > >>> For additional commands, e-mail: dev-help at lucene.apache.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > >> For additional commands, e-mail: dev-help at lucene.apache.org > > From weijun.wang at oracle.com Tue Oct 18 02:31:17 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 18 Oct 2016 10:31:17 +0800 Subject: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!) In-Reply-To: <016501d2289e$10d7d610$32878230$@apache.org> References: <003701d227f4$e7a41780$b6ec4680$@apache.org> <003e01d227fa$00cb81d0$02628570$@apache.org> <68e97a08-f956-5796-3dea-ead52cad1422@oracle.com> <016501d2289e$10d7d610$32878230$@apache.org> Message-ID: <8EECD0F4-17B2-42F9-810E-01F648929C57@oracle.com> I do some investigation, looks like a method in randomizedtesting-runner-2.3.4.jar is trying to call a method in morfologik-polish-2.1.0.jar and this 2nd method uses getResource() to read something inside this 2nd jar. This will fail because the 1st jar's ProtectionDomain is not granted the permission to read the 2nd jar. And yes, this means the 2nd jar should call getResource() in a doPrivileged block. Otherwise you need to grant that permission to every caller on the stack. This is not a bug. This can be demonstrated with a simple example: class T5 { public static void main(String[] args) throws Exception { go(args[0]); } public static void go(String arg) throws Exception { System.out.println(new T5().getClass().getResource(arg)); } } class T6 { public static void main(String[] args) throws Exception { T5.go(args[0]); } } Now you pack T5.class into 5.jar and T6.class into 6.jar. 5.jar is automatically granted the permission to read itself: $ java -Djava.security.manager -cp 5.jar:6.jar T5 T5.class jar:file:/Volumes/ServerHD/old/work/space/nb/build/classes/5.jar!/T5.class But not 6.jar: $ java -Djava.security.manager -cp 5.jar:6.jar T6 T5.class null Thanks Max > On Oct 18, 2016, at 1:44 AM, Uwe Schindler wrote: > > Hi, > > we already had off-list contact, initiated by Rory O'Donnel - thanks! > > The issue was indeed caused by symlinks. The issue here: The Jenkins server where the tests are running had a home directory that was symlinked somewhere else. All file paths during tests runs and also JAR files had the "correct" (canonical path). But the homedir was defined with the alternate, symlinked "old" path in /etc/passwd. Effect was that the test's policy file referring to the IVY cache in ~/.ivy/cache for loading JAR files used the path extracted from ${user.home}. Of course this broke. > > I am sure this will hit many people, so I have some suggestions how to solve this: In short, when parsing policy files and FilePermissions inside, just "expand" the symlink to be canonic and add *both* (the symlink and the canonic path) as 2 separate FilePermissions to the collection. This spares the runtime check on every file access but still catches all "known" paths. > > In addition, there is also a "bug" in the security permissions system that made the above extra permission needed. We have some third party JARs, that use Class#getResource() to load their own resources. But as getResource does not document any security exceptions or other implications, almost all code out there does not wrap with doPrivileged(). This very old bug required the extra permission to the lib/ folder. The workaround just broke. > > Here is what I wrote in the private discussion: > > --snip-- >> Yes, this is where the problem is. >> >> So it looks like the permission is granted in a policy file instead of being >> granted by the class loader itself. In this case, the path of the permission >> must match how you access that file. > > Yes. I think the problem is that the 3rd party JAR file does not have a doPrivileged block around the getResource/openStream part, so ist running with the permissions of the calling code (a different JAR file - the test runner). IMHO, this is one of the really strange things of the security model in Java and most people do it wrong. Especially it is not clear from Class#getResource that this can be affected by any security policy! It does not even throw a declared SecurityException (because it is swallowed). > > We have the extra path in our policy file for exactly that reason (to work around issues in 3rd party JARs) that don't wrap this into doPrivileged! > >> I'll think about your suggestion. However, can you guarantee the code always >> accesses the file using the canonicalized path? For example, suppose the >> actual file is /x, both /a and /b symlink to it, and you grant the permission on >> /a in a policy file. Even if I canonicalize /a to /x and grant permissions on >> both /a and /x, you will still see a failure if the code access /b. > > I am coming from the full text search engine people. I see the issue that you have with getting the canonical name on every file access (this slows down!). The approach the full text people use is to make "synonyms" of terms and index all of them. Somebody searching for the term will find it under any name. To be ported over to your issue: Instead of doing the canonicalized check on every access, just put *both* known file names into the "search index" (in your case policy file). Means: When parsing the policy file, create 2 file permissions: One as given in the policy and an additional one with the canonical name. This does not solve all problems, but helps around issues like the one we encountered. > > I changed the setup of the Jenkins machine that hit this issue first to not have a symlinked entry in /etc/passwd - instead I placed the real path there - so ${user.home} is right. I will see if the issues are gone. Nevertheless I have just brought this into your attention, so we can figure out what could get wrong on people's systems after this change. I will also figure out with my colleagues how to solve the permission checks in 3rd party jars - especially as they did not do anything wrong - why should one wrap Class#getResource() with doPrivileged?! > --snip-- > > Maybe we can discuss the ideas on the public mailing list. Was quite hard to figure out (with lots of debugging output) until I discovered the problem. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Sean Mullan [mailto:sean.mullan at oracle.com] >> Sent: Monday, October 17, 2016 7:33 PM >> To: Uwe Schindler ; dev at lucene.apache.org >> Cc: 'jdk9-dev' ; 'Dawid Weiss' >> ; balchandra.vaidya at oracle.com >> Subject: Re: Class#getResource returns null in JDK9 b140 if security manager >> is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9- >> ea+140) - Build # 18064 - Unstable!) >> >> Weijun Wang is the best person to respond as he is the RE of JDK-8164705 >> - right now it is the middle of the night for him, but I would expect a >> response from him once he comes online. >> >> --Sean >> >> On 10/16/2016 06:09 PM, Uwe Schindler wrote: >>> Hi again, >>> >>> with jdk.io.permissionsUseCanonicalPath=true it also works, so it is related >> to the new FilePermission code, so my first guess was true, the issue is JDK- >> 8164705. >>> >>> Uwe >>> >>>> (I cc'ed jdk-dev at openjdk, reader there please read the previous mails >>>> below, too). >>>> >>>> I analyzed the problem, although I don't know exactly why it happens: >>>> - On Windows it does not happen on my machine (no idea why!) >>>> - On Linux it happens when tests are running with security manager (this >> is >>>> the default for Lucene and Jenkins does this) >>>> - On Linux it does not happen if I run Lucene tests with "- >>>> Dtests.useSecurityManager=false" >>>> >>>> This makes me think it is related to this: "Remove pathname >> canonicalization >>>> from FilePermission" (https://bugs.openjdk.java.net/browse/JDK- >> 8164705) >>>> >>>> What seems to happen: The code calls Class.getResource to get back an >> URL. >>>> As the JAR file is somehow outside of the FilePermissions given to the test >>>> suite, it seems to fail. Maybe because some of the checks failed, >>>> Class.getResource then returns a null reference, because it was not able >> to >>>> access the JAR file. >>>> >>>> Were there some changes related to this: URLClassLoader and >> FilePermission >>>> checks? >>>> >>>> How should we proceed? >>>> >>>> Uwe >>>> >>>> ----- >>>> Uwe Schindler >>>> uschindler at apache.org >>>> ASF Member, Apache Lucene PMC / Committer >>>> Bremen, Germany >>>> http://lucene.apache.org/ >>>> >>>>> -----Original Message----- >>>>> From: Uwe Schindler [mailto:uwe at thetaphi.de] >>>>> Sent: Sunday, October 16, 2016 10:10 PM >>>>> To: dev at lucene.apache.org >>>>> Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; 'Muneer >>>>> Kolarkunnu' ; 'Dawid Weiss' >>>>> >>>>> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) >> - >>>>> Build # 18064 - Unstable! >>>>> >>>>> Hi, >>>>> >>>>> I reverted the Lucene builds to build Java 9 138 for now. I will later check >> if >>>>> this also happens with build 139, which I have to download first. I will >> also >>>>> debug locally. >>>>> >>>>> The code fails because this code hits "null" on getResource() at >>>>> >> morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34) >>>>> >>>>> https://github.com/morfologik/morfologik- >>>>> stemming/blob/master/morfologik- >>>>> >>>> >> polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32 >>>>> >>>>> This is impossible to happen, because the dict file is in same package. I >>>> have >>>>> no idea why this only fails here and not at other places in Lucene. The >> main >>>>> difference looks like the use of URL instead of getResourceAsStream() >> like >>>>> other places in Lucene. >>>>> >>>>> So this seems to be a major regression in Java 9 build 140. >>>>> >>>>> Uwe >>>>> >>>>> ----- >>>>> Uwe Schindler >>>>> H.-H.-Meier-Allee 63, D-28213 Bremen >>>>> http://www.thetaphi.de >>>>> eMail: uwe at thetaphi.de >>>>> >>>>>> -----Original Message----- >>>>>> From: Uwe Schindler [mailto:uwe at thetaphi.de] >>>>>> Sent: Sunday, October 16, 2016 8:38 PM >>>>>> To: dev at lucene.apache.org >>>>>> Cc: dalibor.topic at oracle.com; balchandra.vaidya at oracle.com; >> 'Muneer >>>>>> Kolarkunnu' ; 'Dawid Weiss' >>>>>> ; dev at lucene.apache.org >>>>>> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9- >> ea+140) - >>>>>> Build # 18064 - Unstable! >>>>>> >>>>>> Hi, >>>>>> >>>>>> this seems to be a new regression in Java 9 ea build 140. Interestingly >> this >>>>>> only affects 2 libraries (morphologic and commons-codec phonetic). We >>>>> use >>>>>> loading of resources from classloaders at many places; it is unclear to >> me, >>>>>> why it only fails here. I will look into the code, but this is outside of >>>> Lucene. >>>>> I >>>>>> think it might be some crazyness like using context class loader in non- >>>>> proper >>>>>> ways or similar. >>>>>> >>>>>> Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working >> one >>>>>> was build 138). >>>>>> >>>>>> Uwe >>>>>> >>>>>> ----- >>>>>> Uwe Schindler >>>>>> H.-H.-Meier-Allee 63, D-28213 Bremen >>>>>> http://www.thetaphi.de >>>>>> eMail: uwe at thetaphi.de >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Policeman Jenkins Server [mailto:jenkins at thetaphi.de] From dalibor.topic at oracle.com Tue Oct 18 09:10:42 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 18 Oct 2016 11:10:42 +0200 Subject: CFV: New JDK9 Committer: Mikhailo Seledtsov In-Reply-To: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> References: <2b7d1c4f-2fe6-46ec-bc75-6ab40a2813a7@default> Message-ID: Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From masayoshi.okutsu at oracle.com Tue Oct 18 09:35:37 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 18 Oct 2016 18:35:37 +0900 Subject: CFV: New JDK9 Committer: Nishit Jain Message-ID: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> I hereby nominate Nishit Jain to JDK 9 Committer. Nishit is currently a JDK 9 Author and a member of the Internationalization team at Oracle. He has made 18 contributions to JDK 9 [3]. Votes are due by Oct 31, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Masayoshi [1]http://openjdk.java.net/census [2]http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) From dalibor.topic at oracle.com Tue Oct 18 09:50:27 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 18 Oct 2016 11:50:27 +0200 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: <3cbca892-a80f-cb91-f250-02f7ba487b8a@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From vyom.tewari at oracle.com Tue Oct 18 09:52:08 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Tue, 18 Oct 2016 15:22:08 +0530 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: Vote: Yes On Tuesday 18 October 2016 03:05 PM, Masayoshi Okutsu wrote: > I hereby nominate Nishit Jain to JDK 9 Committer. > > Nishit is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. > He has made 18 contributions to JDK 9 [3]. > > Votes are due by Oct 31, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Masayoshi > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) > From yuka.kamiya at oracle.com Tue Oct 18 10:34:38 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Tue, 18 Oct 2016 19:34:38 +0900 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: <657c88f6-ef12-676e-8f6c-6ac53e7f887e@oracle.com> Vote: Yes On 2016/10/18 18:35, Masayoshi Okutsu wrote: > I hereby nominate Nishit Jain to JDK 9 Committer. > > Nishit is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. > He has made 18 contributions to JDK 9 [3]. > > Votes are due by Oct 31, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Masayoshi > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) > From maurizio.cimadamore at oracle.com Tue Oct 18 11:01:11 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Oct 2016 12:01:11 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <20161017114706.GB28184@ehelin.jrpg.bea.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> <20161017114706.GB28184@ehelin.jrpg.bea.com> Message-ID: <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> Hi Erik - thanks for the comments. I indeed got the hardlink story backwards - which means the size of a local clone will be relatively stable in time - good news! Regarding shaare/bookmarks, that is a good suggestion. I tried bookmarks extensively, and I found them a bit too finicky to use with a single repo (as with branches, you need to be very aware in which bookmark you are on, or mistakes can be very common). Additionally, using just a single repo creates problem when you want to store 'project' specific metadata (tempoarry tests, IDE config and the likes). So, using 'share' seems like a major step forward because it allows you to 'forget' about branches being there (each folder will be on a separate branch). One thing that will remain convoluted (if I'm understanding how bookmarks work correctly) is for instance when you want to fetch new changes from the remote repo. In that case, I think you need to: * go in the main repo forest (the one with the 'main' bookmark) * do a pull/update * go in the share you were working with * do an hg pull 'main' Is that correct? And, more importantly, could other bookmarks/shares be left as they are (i.e. not updated) ? I'd like the various shares to be as independent as possible. On a separate note, langtools is one of those cases (there are probably others, like Nashorn) where the repo is currently fairly isolated from the rest of the JDK - meaning that you can just fetch a langtools repo, build it and test it in isolation. A similar case could arise if a JDK developer would like to work, say, only on a reduced set of JDK modules. While cloning all files is perfectly acceptable disk size-wise I find the lack of granularity a tad annoying in the general case (and I've built some tools to overcome that problem). Maurizio On 17/10/16 12:47, Erik Helin wrote: > Hi Maurizio, > > thanks for your feedback! Please see my replies inline. > > On 2016-10-13, Maurizio Cimadamore wrote: >> Hi Joe, >> some comments on this. As my workflow typically involve cloning one >> langtools repo per each new fix, I'll start with discussing local clones >> first. Starting with some concrete numbers, I am currently working on 2 >> forests (jdk 9 and valhalla); between these two forests I currently have ~35 >> langtools clones (for various prototypes and bug fixes). Also, as I'm >> working on two machines, I keep them in sync using Unison, a very common >> sync tool in linux land based on rsync. >> >> I have been experimenting with local clones, to see to which degree a local >> clone could save in terms of space. My findings are that a local clone takes >> around 800M - which seems consistent with the fact that Mercurial hardlinks >> the repo files but not the history, which is simply copied. > You might have gotten this the wrong way around. Mercurial will use > hard links for most of the metadata for local clones on a > file system that support hard links. The source code files themselves > won't be hard links (otherwise, if you edited one file in one local > clone then the file sharing the same inode in another local clone would > get changed). > >> For people like me, working on langtools, that's quite a significant jump in >> terms of space - a clean langtools repo is around 150M. So, in my specific >> case, disk usage will jump from 150M * 35 =~ 5G to 800M * 35 =~ 28G (this >> is a very conservative estimate - since it's assuming that all files are >> hardlinked, which will not be the case as soon as I start making some >> changes in the local clones). While this is not a deal breaker in terms of >> disk spaces (my SSD has 200G in total), it poses serious strain on my >> ability to do regular syncing/backups. > Thanks for sharing your workflow! For this use case, could you perhaps > try out the `hg share` extension? You need to enable the extension in > your .hgrc. A share is like a clone, but Mercurial will share the store > folder between all shares. This is *not* done using hardlinks, if you > look in the .hg folder for a share, you will not see the "store" folder > (you will see a file named sharedpath instead). > > Using shares on their own can be a bit tricky, but if you combine them > with bookmarks, then you get a very powerful solution. In your case, I > would suggest the following: > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > $ cd consol-proto > $ hg bookmark '@' # traditional name for "master" bookmark > $ cd .. > $ hg share -B consol-proto bugfix-1 > $ cd bugfix-1 > $ hg bookmark 'bugfix-1' > > You will now end up with two directories, consol-proto and bugfix-1, > both looking like a full forest, but they will share the same Mercurial > store *and* list of bookmarks (but the active bookmark won't be shared). > Since the shares use different bookmarks, the work you do in a share > won't interfere with the work you do in another share (you will get > multiple heads, but each head will have a bookmark associated with it). > > For backing up, you now only need to back up the consol-proto > repository (it contains all the bookmarks and all commits). There is no > need to back up the shares, they can always be created from the > consol-proto repository. > > On my machine, using Linux 4.3.3 and ext4 as my filesystem, with hg > version 3.8.1, a share uses 661 MB of disk. If you know want 35 shares, > you would end up using 35 * 661 = 22.6 GB. But you only have to back up > one repository! > >> Add to this the fact that most backup/syncing tools explicitly calls out the >> hardlink case as being problematic. Unison doesn't support them, rsync >> supports them to some degree, and even some professional backup tools I'm >> using no do support them (or recommend to do without them anyway). So, local >> cloning could be a fine solution when working on one machine, but as soon as >> you start considering back up, you have troubles. For this reasons I will >> have to consider to change my day to day workflow, and to try and avoid >> relying on clone as much as I did - which poses issues: for instance, if I >> keep all my patches in the same repo (by using either MQ or bookmarks) - how >> do I differentiate between the different IDE projects to work on them? > If you are using shares as suggested above, you would have one folder > with all the source code for each bookmark. > >> Last but not the least - if the local clone size I'm seeing now (800M) is >> almost entirely history-driven, and that already accounts for 50% of the >> total size - doesn't that mean that i.e. in 2-3 years time, the size of the >> history will trump the size of the files, meaning that the advantages of >> doing local clones will be smaller and smaller over time? > No, it is the other way around. For a local clone, you share all of the > history (using hard links). So the size of your local clones scale with > size of the source files (the same is true for shares). This can easily > be verified by doing `du -ms .hg` for a share, I get 6 MB. > > Thanks, > Erik > >> On a separate and more note, it seems to me that this effort is two >> things at once: >> >> * a repo consolidation: use a single repo instead of a forest >> * a source restructuring >> >> Each of the above moves has risks and costs for people in the OpenJDK land. >> For instance, as discussed above, the repo consolidation might mean >> significantly change the workflow people use on a daily basis (see above). >> At the same time, the source restructuring is posing issues for things like >> builds, IDE support, and the likes. >> >> I wonder if it wouldn't be sensible to do the repo restructuring now, where >> the new repo is simply a consolidated version of the new one; no need to >> update build scripts to take into account new paths. Then, maybe in the next >> release (JDK 11), we could attack the source restructuring problem. This way >> people will have more time to adjust to the big changes that are coming. >> >> What do you think? >> >> Maurizio >> >> >> On 11/10/16 03:11, joe darcy wrote: >>> Hello, >>> >>> Looking ahead to JDK 10, a group of JDK engineers have been exploring >>> consolidating the large number of Hg repositories in an open JDK forest to >>> a single one with the goal of using the consolidated arrangement for JDK >>> 10. >>> >>> This message is being sent to jdk9-dev since a jdk10-dev alias to discuss >>> JDK 10 doesn't exist yet. >>> >>> A JEP describing the project has been submitted : >>> >>> JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single >>> repository >>> https://bugs.openjdk.java.net/browse/JDK-8167368 >>> >>> The text of the JEP describes the motivation and current state of the work >>> in more detail, including proposed changes to the file layout. Publication >>> of the prototype consolidated repository is planned, but not done yet. The >>> email below has a list of additional anticipated questions and answers. >>> >>> We feel this consolidated arrangement offers some significant structural >>> advantages for managing the JDK's source code and we are now asking for >>> feedback on this potential change. In particular, if you feel there is a >>> show-stopper problem with making this change, please let us know! >>> >>> I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and >>> Ingemar Aberg participating in discussions leading up to the prototype and >>> I'd like to especially recognize the contributions of Erik Helin for savvy >>> Hg manipulations and Erik Joelsson for skillful build wrangling in this >>> project. >>> >>> Please send initial comments by October 18, 2016. >>> >>> Cheers, >>> >>> -Joe >>> >>> Q: What about the set of forests for JDK 10? Are we going to have master, >>> dev, client, hotspot, etc. the same set as in 9? >>> A: That is a separate question from the repository consolidation, but >>> there will likely be simplifications here too. Discussions on that point >>> will come later. >>> >>> Q: I usually just build the code in repo X today. Will I have have to >>> build the *whole JDK* now? >>> A: Not necessarily. The same top-level build targets should work in the >>> consolidated forest. >>> >>> Q: Does disk usage change? >>> A: The total disk usage of the current forest compared to the consolidated >>> forest is nearly the same. >>> >>> Q: In more detail, how were the changesets imported? >>> A: The scripts used for the consolidation conversion are attached to the >>> JEP. >>> >>> Q: What happens to the Hg hashes? >>> A: The conversion scheme used in the prototype does *not* preserve Hg >>> hashes of changesets compared the current forests. However, the bug ids >>> are preserved and can be searched for. In addition, one or more >>> pre-consolidation forests should be archived in perpetuity so that URLs in >>> bug comments continue to work, etc. >>> >>> A mapping of the old hashes to the corresponding new hashes might be >>> generated and placed in the final new repo. >>> >>> Q: I'm allergic to tabs; what about jcheck? >>> A: If history is preserved, the checking done by jcheck needs to be >>> modified for the consolidated forest. One way to do this is to augment the >>> white lists used in jcheck with the conflicting changesets. This approach >>> may not be elegant, but it is effective and doesn't appear to appreciably >>> impact jcheck running times. >>> >>> Q: Will the future 9 update forest also have this consolidation >>> restructuring? >>> A: The script used to do the consolidation conversion is deterministic and >>> could be run to create the 9 update forest in the future at the >>> discretion of the 9 update team. >>> >>> Q: For backports for forwardports, will there be a script to translate >>> patch files across the consolidation boundary? >>> A: That work is planned, but not yet done; see JDK-8165623: Create patch >>> translator to update paths pre/post consolidation. >>> >>> Q: It's the 21st century and I develop using an IDE. That is still going >>> to work, right? >>> A: The prototype to date does include updating the various IDE support >>> files, but bug JDK-8167142 has been filed to track that work. >>> From nadeesh.tv at oracle.com Tue Oct 18 12:20:24 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 18 Oct 2016 17:50:24 +0530 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <657c88f6-ef12-676e-8f6c-6ac53e7f887e@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> <657c88f6-ef12-676e-8f6c-6ac53e7f887e@oracle.com> Message-ID: <58061388.3050606@oracle.com> Vote: Yes On 10/18/2016 4:04 PM, Yuka Kamiya wrote: > Vote: Yes > > On 2016/10/18 18:35, Masayoshi Okutsu wrote: >> I hereby nominate Nishit Jain to JDK 9 Committer. >> >> Nishit is currently a JDK 9 Author and a member of the >> Internationalization team at Oracle. >> He has made 18 contributions to JDK 9 [3]. >> >> Votes are due by Oct 31, 2016. >> >> Only current JDK 9 Committers [1] are eligible to vote on this >> nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> Masayoshi >> >> [1]http://openjdk.java.net/census >> [2]http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) >> > -- Thanks and Regards, Nadeesh TV From sibabrata.sahoo at oracle.com Tue Oct 18 13:05:03 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 18 Oct 2016 06:05:03 -0700 (PDT) Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: <32bf3b54-4d62-44be-9b44-1b34f27d6ea7@default> Vote: Yes -----Original Message----- From: Masayoshi Okutsu Sent: Tuesday, October 18, 2016 3:06 PM To: jdk9-dev at openjdk.java.net Subject: CFV: New JDK9 Committer: Nishit Jain I hereby nominate Nishit Jain to JDK 9 Committer. Nishit is currently a JDK 9 Author and a member of the Internationalization team at Oracle. He has made 18 contributions to JDK 9 [3]. Votes are due by Oct 31, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Masayoshi [1]http://openjdk.java.net/census [2]http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) From erik.helin at oracle.com Tue Oct 18 13:59:18 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 18 Oct 2016 15:59:18 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> <20161017114706.GB28184@ehelin.jrpg.bea.com> <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> Message-ID: <172f636e-1a3d-c22c-be72-b92d3935a097@oracle.com> On 10/18/2016 01:01 PM, Maurizio Cimadamore wrote: > Hi Erik - thanks for the comments. I indeed got the hardlink story > backwards - which means the size of a local clone will be relatively > stable in time - good news! > > Regarding shaare/bookmarks, that is a good suggestion. I tried bookmarks > extensively, and I found them a bit too finicky to use with a single > repo (as with branches, you need to be very aware in which bookmark you > are on, or mistakes can be very common). Additionally, using just a > single repo creates problem when you want to store 'project' specific > metadata (tempoarry tests, IDE config and the likes). > > So, using 'share' seems like a major step forward because it allows you > to 'forget' about branches being there (each folder will be on a > separate branch). > > One thing that will remain convoluted (if I'm understanding how > bookmarks work correctly) is for instance when you want to fetch new > changes from the remote repo. In that case, I think you need to: > > * go in the main repo forest (the one with the 'main' bookmark) > > * do a pull/update > > * go in the share you were working with > > * do an hg pull 'main' > > Is that correct? And, more importantly, could other bookmarks/shares be > left as they are (i.e. not updated) ? I'd like the various shares to be > as independent as possible. Well, this is one case when you have to remember that all 'hg shares' share the same "store". When you do `hg pull -u` in the your 'default' folder, this will advance the "@" bookmark (assuming that is the name of your bookmark in the default folder) to the latest commit. However, your other bookmarks won't be updated (intentionally). Now, when you change to the folder bugfix-1, the most common way to sync your work on the anonymous branch described by the bookmark bugfix-1 and the work on the default branch described by the bookmark "@" is to rebase the parents to the bookmark bugfix-1 on top of the changeset labeled @. Using my limited ASCII-art skills, this would look like the following. After doing `hg pull -u` in the 'default' directory: * (@) | * | (bugfix-1) * * | | * * | | *----* | * | You then change directory to 'bugfix-1' and run `hg rebase -d @`, which means "rebase all changesets that are parents of the active bookmark on top of of the changeset described by the @ bookmark". After running the above command, the changeset graph would look like: (bugfix-1) * | * | * | * (@) | * | * | * | * | * | To use rebase, you must enable the rebase extension in your .hgrc. `hg rebase` uses the exact same logic as `hg merge` if a conflict arises. > On a separate note, langtools is one of those cases (there are probably > others, like Nashorn) where the repo is currently fairly isolated from > the rest of the JDK - meaning that you can just fetch a langtools repo, > build it and test it in isolation. A similar case could arise if a JDK > developer would like to work, say, only on a reduced set of JDK modules. > While cloning all files is perfectly acceptable disk size-wise I find > the lack of granularity a tad annoying in the general case (and I've > built some tools to overcome that problem). You mean that you can work on the langtools repository only? Do you only need a boot JDK? How do you build in those cases? I assumed that langtools, like all the other repositories, were building from the top repository? In general, with a consolidated forest, you will have to carry all the files in the repository along with you. If you just copy the langtools directory somewhere, then you won't get the hg metadata (there is no longer any .hg directory in the langtools directory). However, as you noticed, it is perfectly fine to only work with a small part of the files in the repository. I myself often build only hotspot by running `make hotspot` from the top-level directory. Or did I miss your point? Thanks, Erik > Maurizio > > > On 17/10/16 12:47, Erik Helin wrote: >> Hi Maurizio, >> >> thanks for your feedback! Please see my replies inline. >> >> On 2016-10-13, Maurizio Cimadamore wrote: >>> Hi Joe, >>> some comments on this. As my workflow typically involve cloning one >>> langtools repo per each new fix, I'll start with discussing local clones >>> first. Starting with some concrete numbers, I am currently working on 2 >>> forests (jdk 9 and valhalla); between these two forests I currently >>> have ~35 >>> langtools clones (for various prototypes and bug fixes). Also, as I'm >>> working on two machines, I keep them in sync using Unison, a very common >>> sync tool in linux land based on rsync. >>> >>> I have been experimenting with local clones, to see to which degree a >>> local >>> clone could save in terms of space. My findings are that a local >>> clone takes >>> around 800M - which seems consistent with the fact that Mercurial >>> hardlinks >>> the repo files but not the history, which is simply copied. >> You might have gotten this the wrong way around. Mercurial will use >> hard links for most of the metadata for local clones on a >> file system that support hard links. The source code files themselves >> won't be hard links (otherwise, if you edited one file in one local >> clone then the file sharing the same inode in another local clone would >> get changed). >> >>> For people like me, working on langtools, that's quite a significant >>> jump in >>> terms of space - a clean langtools repo is around 150M. So, in my >>> specific >>> case, disk usage will jump from 150M * 35 =~ 5G to 800M * 35 =~ 28G >>> (this >>> is a very conservative estimate - since it's assuming that all files are >>> hardlinked, which will not be the case as soon as I start making some >>> changes in the local clones). While this is not a deal breaker in >>> terms of >>> disk spaces (my SSD has 200G in total), it poses serious strain on my >>> ability to do regular syncing/backups. >> Thanks for sharing your workflow! For this use case, could you perhaps >> try out the `hg share` extension? You need to enable the extension in >> your .hgrc. A share is like a clone, but Mercurial will share the store >> folder between all shares. This is *not* done using hardlinks, if you >> look in the .hg folder for a share, you will not see the "store" folder >> (you will see a file named sharedpath instead). >> >> Using shares on their own can be a bit tricky, but if you combine them >> with bookmarks, then you get a very powerful solution. In your case, I >> would suggest the following: >> >> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >> $ cd consol-proto >> $ hg bookmark '@' # traditional name for "master" bookmark >> $ cd .. >> $ hg share -B consol-proto bugfix-1 >> $ cd bugfix-1 >> $ hg bookmark 'bugfix-1' >> >> You will now end up with two directories, consol-proto and bugfix-1, >> both looking like a full forest, but they will share the same Mercurial >> store *and* list of bookmarks (but the active bookmark won't be shared). >> Since the shares use different bookmarks, the work you do in a share >> won't interfere with the work you do in another share (you will get >> multiple heads, but each head will have a bookmark associated with it). >> >> For backing up, you now only need to back up the consol-proto >> repository (it contains all the bookmarks and all commits). There is no >> need to back up the shares, they can always be created from the >> consol-proto repository. >> >> On my machine, using Linux 4.3.3 and ext4 as my filesystem, with hg >> version 3.8.1, a share uses 661 MB of disk. If you know want 35 shares, >> you would end up using 35 * 661 = 22.6 GB. But you only have to back up >> one repository! >> >>> Add to this the fact that most backup/syncing tools explicitly calls >>> out the >>> hardlink case as being problematic. Unison doesn't support them, rsync >>> supports them to some degree, and even some professional backup tools >>> I'm >>> using no do support them (or recommend to do without them anyway). >>> So, local >>> cloning could be a fine solution when working on one machine, but as >>> soon as >>> you start considering back up, you have troubles. For this reasons I >>> will >>> have to consider to change my day to day workflow, and to try and avoid >>> relying on clone as much as I did - which poses issues: for instance, >>> if I >>> keep all my patches in the same repo (by using either MQ or >>> bookmarks) - how >>> do I differentiate between the different IDE projects to work on them? >> If you are using shares as suggested above, you would have one folder >> with all the source code for each bookmark. >> >>> Last but not the least - if the local clone size I'm seeing now >>> (800M) is >>> almost entirely history-driven, and that already accounts for 50% of the >>> total size - doesn't that mean that i.e. in 2-3 years time, the size >>> of the >>> history will trump the size of the files, meaning that the advantages of >>> doing local clones will be smaller and smaller over time? >> No, it is the other way around. For a local clone, you share all of the >> history (using hard links). So the size of your local clones scale with >> size of the source files (the same is true for shares). This can easily >> be verified by doing `du -ms .hg` for a share, I get 6 MB. >> >> Thanks, >> Erik >> >>> On a separate and more note, it seems to me that this effort >>> is two >>> things at once: >>> >>> * a repo consolidation: use a single repo instead of a forest >>> * a source restructuring >>> >>> Each of the above moves has risks and costs for people in the OpenJDK >>> land. >>> For instance, as discussed above, the repo consolidation might mean >>> significantly change the workflow people use on a daily basis (see >>> above). >>> At the same time, the source restructuring is posing issues for >>> things like >>> builds, IDE support, and the likes. >>> >>> I wonder if it wouldn't be sensible to do the repo restructuring now, >>> where >>> the new repo is simply a consolidated version of the new one; no need to >>> update build scripts to take into account new paths. Then, maybe in >>> the next >>> release (JDK 11), we could attack the source restructuring problem. >>> This way >>> people will have more time to adjust to the big changes that are coming. >>> >>> What do you think? >>> >>> Maurizio >>> >>> >>> On 11/10/16 03:11, joe darcy wrote: >>>> Hello, >>>> >>>> Looking ahead to JDK 10, a group of JDK engineers have been exploring >>>> consolidating the large number of Hg repositories in an open JDK >>>> forest to >>>> a single one with the goal of using the consolidated arrangement for >>>> JDK >>>> 10. >>>> >>>> This message is being sent to jdk9-dev since a jdk10-dev alias to >>>> discuss >>>> JDK 10 doesn't exist yet. >>>> >>>> A JEP describing the project has been submitted : >>>> >>>> JDK-8167368: Consolidate JDK 10 OpenJDK repositories to a single >>>> repository >>>> https://bugs.openjdk.java.net/browse/JDK-8167368 >>>> >>>> The text of the JEP describes the motivation and current state of >>>> the work >>>> in more detail, including proposed changes to the file layout. >>>> Publication >>>> of the prototype consolidated repository is planned, but not done >>>> yet. The >>>> email below has a list of additional anticipated questions and answers. >>>> >>>> We feel this consolidated arrangement offers some significant >>>> structural >>>> advantages for managing the JDK's source code and we are now asking for >>>> feedback on this potential change. In particular, if you feel there >>>> is a >>>> show-stopper problem with making this change, please let us know! >>>> >>>> I'd like to acknowledge the work of Stefan Sarne, Stuart Marks, and >>>> Ingemar Aberg participating in discussions leading up to the >>>> prototype and >>>> I'd like to especially recognize the contributions of Erik Helin for >>>> savvy >>>> Hg manipulations and Erik Joelsson for skillful build wrangling in this >>>> project. >>>> >>>> Please send initial comments by October 18, 2016. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> Q: What about the set of forests for JDK 10? Are we going to have >>>> master, >>>> dev, client, hotspot, etc. the same set as in 9? >>>> A: That is a separate question from the repository consolidation, but >>>> there will likely be simplifications here too. Discussions on that >>>> point >>>> will come later. >>>> >>>> Q: I usually just build the code in repo X today. Will I have have to >>>> build the *whole JDK* now? >>>> A: Not necessarily. The same top-level build targets should work in the >>>> consolidated forest. >>>> >>>> Q: Does disk usage change? >>>> A: The total disk usage of the current forest compared to the >>>> consolidated >>>> forest is nearly the same. >>>> >>>> Q: In more detail, how were the changesets imported? >>>> A: The scripts used for the consolidation conversion are attached to >>>> the >>>> JEP. >>>> >>>> Q: What happens to the Hg hashes? >>>> A: The conversion scheme used in the prototype does *not* preserve Hg >>>> hashes of changesets compared the current forests. However, the bug ids >>>> are preserved and can be searched for. In addition, one or more >>>> pre-consolidation forests should be archived in perpetuity so that >>>> URLs in >>>> bug comments continue to work, etc. >>>> >>>> A mapping of the old hashes to the corresponding new hashes might be >>>> generated and placed in the final new repo. >>>> >>>> Q: I'm allergic to tabs; what about jcheck? >>>> A: If history is preserved, the checking done by jcheck needs to be >>>> modified for the consolidated forest. One way to do this is to >>>> augment the >>>> white lists used in jcheck with the conflicting changesets. This >>>> approach >>>> may not be elegant, but it is effective and doesn't appear to >>>> appreciably >>>> impact jcheck running times. >>>> >>>> Q: Will the future 9 update forest also have this consolidation >>>> restructuring? >>>> A: The script used to do the consolidation conversion is >>>> deterministic and >>>> could be run to create the 9 update forest in the future at the >>>> discretion of the 9 update team. >>>> >>>> Q: For backports for forwardports, will there be a script to translate >>>> patch files across the consolidation boundary? >>>> A: That work is planned, but not yet done; see JDK-8165623: Create >>>> patch >>>> translator to update paths pre/post consolidation. >>>> >>>> Q: It's the 21st century and I develop using an IDE. That is still >>>> going >>>> to work, right? >>>> A: The prototype to date does include updating the various IDE support >>>> files, but bug JDK-8167142 has been filed to track that work. >>>> > From thomas.stuefe at gmail.com Tue Oct 18 14:39:30 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Oct 2016 16:39:30 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> Message-ID: Hi all, On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > I'm on a 1.6 TB share available to our team visible on all our > servers. The machine is a 48 processor 64GB linux x86_64 server. > The servers only have limited local disc space. Especially with the > new setup I can not have clones on all the machines I need to compile > and test on. > > Best regards, > Goetz. > > I'm on Goetz team at SAP. Just wanted to give some additional information: I keep reading "use local repos". This is unfortunately not practical for us. Limited local disk space on build machines is only the smallest of the problems. A bigger problem is our platform breadth. We have a large zoo of machines running a number of cpu/os combinations. When we develop for the OpenJDK, we want to build and test on multiple - preferably all - machines and platforms the OpenJDK is supported on, to make sure we do not introduce regressions. But we have no automatic build system for these platforms, nor do we have access to your jprt. So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc, s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave out platforms I think are safe - in this case 32bit and zero - but at my own risk, because if I introduce a regression because I do not build, I risk the annoyance of other developers. Therefore local repos are not practical - syncing local repos across many machines is a pain and very error prone. So, every developer keeps his repos on a filer (NFS) and so if the NFS client on a certain machine is not good, we wait and suffer. So performance matters for us a lot. Kind Regards, Thomas > > -----Original Message----- > > From: Erik Helin [mailto:erik.helin at oracle.com] > > Sent: Montag, 17. Oktober 2016 13:42 > > To: Lindenmaier, Goetz > > Cc: Anthony Vanelverdinghe ; jdk9- > > dev at openjdk.java.net > > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 > > > > On 2016-10-17, Lindenmaier, Goetz wrote: > > > Hi Anthony and Joe, > > > > > > > such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, > and hg > > commit --amend" [7]. > > > I understand how these commands replace hg queues. > > > I don't understand how they replace having several > > > clones to do something like this: > > > - Change 1 is compiling (in clone 1) > > > - Debugging change 2 (in clone 2) > > > - I get a review and want to immediately edit change 3 (in clone 3), > without > > > invalidating the sources I stepped in the debugging session and > without > > > canceling the builds. > > > > I would recommend two similar but slighty different workflows for this: > > - local clones (as previously discussed). One local clone per > > feature/bug/review/debugging-session. > > - shares, using `hg share` and bookmarks. One bookmark in each hg share. > > > > > If I use a single clone, I can have these three changes in three > branches, > > > or in several sequential changes (like a mercurial queue) I keep > reordering > > with > > > histedit. But as there is only one source tree I can only work on one > of > > > the changes at a time. > > > Hg share will do this job I assume. > > > > > > I have been looking at the consol-proto: > > > > The timings seems an order of magnitude off? What kind of machine are > > you using? See inline for my measurements, all done on a 1 year old > > Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg > > version 3.8.1. > > > > > hg clone takes 30 minutes. Before, get_source.sh took 20 mins. > > > > $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto > > requesting all changes > > adding changesets > > adding manifests > > adding file changes > > added 41157 changesets with 358201 changes to 148305 files > > updating to branch default > > 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved > > > > real 17m42.057s > > user 4m37.156s > > sys 0m41.153s > > > > The time for the remote clone will depend mostly on yours (and > > Oracle's) network. The amount of bits that needs to be transferred are > > almost the same (differs on a few MB IIRC) compared to a forest. The > > difference is that the forest downloads the metadata for multiple > > repositories in parallel. > > > > I know you find it cumbersome, but my recommendation here would be to > > not clone that often from the remote servers. Since mercurial is a DVCS, > > you already have most of the bits locally on your machine if you've > > already cloned once. > > > > > Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. > > > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > > $ time hg share --bookmarks consol-proto share > > updating working directory > > 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved > > > > real 0m7.528s > > user 0m28.442s > > sys 0m9.791s > > > > I have no idea why it takes 5 (or even 3) minutes on your machine? > > > > > Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. > > > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > > $ cd consol-proto/src/hotspot/ > > $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560- > > basic_s390/hotspot.wr04/hotspot.changeset > > $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent > > $ time hg diff > > M src/hotspot/os/linux/vm/os_linux.cpp > > M src/hotspot/share/tools/hsdis/hsdis.c > > M src/hotspot/share/vm/code/codeCache.cpp > > M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp > > M src/hotspot/share/vm/runtime/globals.hpp > > M src/hotspot/share/vm/runtime/vm_version.cpp > > M src/hotspot/share/vm/utilities/macros.hpp > > ? src/hotspot/hotspot.changeset > > ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig > > ? src/hotspot/share/vm/runtime/globals.hpp.orig > > > > real 0m0.787s > > user 0m0.587s > > sys 0m0.200s > > > > What patch/changes did you apply before running `hg diff`? I have hard > > time getting `hg diff` to take longer than 1 second... > > > > > The full repo requires 1.9G. > > > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > > $ du -ms consol-proto > > 1754 consol-proto/ > > > > I don't know why yours is 191 MB larger than mine. Different filesystem > > and or hg version? > > > > > A 'hg share' repo requires 0.6G > > > > $ mkdir measurements && cd measurements > > $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto > > $ du -ms . > > 1754 . > > > > $ hg share console-proto share > > $ du -ms . > > 2415 . > > > > so 2415 - 1754 = 661 MB for a share, so similar to my measurements. > > > > Thanks, > > Erik > > > > > A hotspot repo before required 0.2G. > > > > > > I will be able to live with this using modern, slower functionality ;) > > > But it imposes a considerable overhead in hardware, tool runtime > > > and administration on my side. > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can I check out several > > > > > > > > > > > > > -----Original Message----- > > > > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf > > Of > > > > Anthony Vanelverdinghe > > > > Sent: Freitag, 14. Oktober 2016 22:11 > > > > To: jdk9-dev at openjdk.java.net > > > > Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK > 10 > > > > > > > > Hi > > > > > > > > While I'm not an OpenJDK committer (yet, hope to become so one fine > > > > day), I believe this is a great initiative. Since several people have > > > > raised concerns related to the increased repository size, I just > wanted > > > > to point out that both Facebook and Mozilla work with Mercurial > > > > repositories which dwarf a typical OpenJDK repository. For example, a > > > > clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev > is > > > > less than 1 GB. > > > > > > > > There are also several Mercurial extensions which may prove to be > useful > > > > for people having to work with large repositories and/or adapt their > > > > workflows. > > > > During their work to scale Mercurial [2], Facebook contributed/made > > > > several extensions, such as fsmonitor as mentioned by Joe [3], and > the > > > > ones in their BitBucket repository [4], such as remotefilelog [5]. > > > > When working with local clones, the share extension may be helpful > [6]. > > > > Finally, note that mq is "often considered for deprecation", so this > may > > > > be an opportunity to adopt "modern tools, such as hg rebase, hg > > > > histedit, hg graft, hg strip, hg strip --keep, and hg commit > --amend" [7]. > > > > > > > > Kind regards, > > > > Anthony > > > > > > > > [1] https://hg.mozilla.org/mozilla-central/ > > > > [2] > > > > https://code.facebook.com/posts/218678814984400/scaling-mercurial- > > at- > > > > facebook/ > > > > [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > > > > October/004990.html > > > > [4] https://bitbucket.org/facebook/hg-experimental > > > > [5] > > > > https://bitbucket.org/facebook/hg- > > > > > > experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel > > > > og/?at=default > > > > [6] https://www.mercurial-scm.org/wiki/ShareExtension > > > > [7] https://www.mercurial-scm.org/wiki/MqExtension > > > > > > > > On 14/10/2016 19:03, Brian Goetz wrote: > > > > > > > > > >> Conversely, I think it is reasonable for engineers making changes > to > > > > >> the JDK to be wiling to offer some flexibility in adjusting > > > > >> established worksflows optimized for the split repositories to > > > > >> accommodate the sort of infrastructure changes being proposed here > > > > >> for a consolidated one. > > > > > > > > > > Let me amplify this: OpenJDK developers are not the only > stakeholders > > > > > here. By aligning more with the way the rest of the world > develops > > > > > -- all code in one linearized, transactionally updated repo -- it > > > > > increases the feasibility / reduces the cost of tools like > 'bisect' to > > > > > determine where a fault was introduced. This reduces SQE costs and > > > > > increases product quality -- something we all have a stake in. > David > > > > > Lloyd has pointed up other tooling-related benefits, such as > making it > > > > > easier to maintain a git mirror. > > > > > > > > > > Most of the objections raised so far have been "(I think they will) > > > > > make my life harder." Fair enough; people should be their own > > > > > advocates. But let's not forget the significant benefits that > accrue > > > > > to *everyone* as a result, and keep those in mind when judging the > > > > > pros and cons. > > > > > > > > > > > > > > > > > > > From mark.reinhold at oracle.com Tue Oct 18 14:56:25 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 18 Oct 2016 07:56:25 -0700 Subject: JDK 9 release schedule In-Reply-To: <20160913155640.71291CD3B6@eggemoggin.niobe.net> References: <20160913155640.71291CD3B6@eggemoggin.niobe.net> Message-ID: <20161018075625.243636391eggemoggin.niobe.net> 2016/9/13 8:56:40 -0700, mark.reinhold at oracle.com: > ... > > For these reasons I hereby propose a four-month extension of the JDK 9 > schedule, moving the General Availability (GA) milestone to July 2017. > I'll make a more detailed proposal for that date and other milestones > in the next few weeks, but for now I suggest we defer the start of the > Rampdown process [8] and continue to operate with the previously-adopted > Feature Complete extension-request process [9]. > > Minor enhancements and even strongly-justified proposals to target new > JEPs to JDK 9 will be considered, so long as they do not add undue risk > to the overall release. As before, however, our main focus should be to > use this additional time to stabilize, polish, and fine-tune the features > that we already have rather than add a bunch of new ones. > > Comments on this proposal from JDK 9 Committers are welcome, as are > reasoned objections. If no such objections are raised by 16:00 UTC next > Tuesday, 20 September, or if they're raised and satisfactorily answered, > then per the JEP 2.0 process proposal [a] this will be adopted as the > new schedule for JDK 9. Hearing no objections, I've recorded the new GA date on the JDK 9 Project page [1]. Here are the proposed dates for the interim milestones: 2016/05/26 Feature Complete 2016/12/22 Feature Extension Complete 2017/01/05 Rampdown Start 2017/02/09 All Tests Run 2017/02/16 Zero Bug Bounce 2017/03/16 Rampdown Phase 2 2017/07/06 Final Release Candidate 2017/07/27 General Availability The milestone definitions are as before except for "Feature Extension Complete", which is the date by which JEPs and small enhancements that have been granted extensions via the existing process [1] must be integrated into the master forest. I didn't include the interim milestones in the initial proposal, so I'll leave them open for discussion under the same terms until 15:00 UTC next Tuesday, 25 October. - Mark [1] http://openjdk.java.net/projects/jdk9/ [2] http://localhost:8081/projects/jdk9/fc-extension-process From mark.reinhold at oracle.com Tue Oct 18 15:03:49 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 18 Oct 2016 08:03:49 -0700 Subject: JDK 9 release schedule In-Reply-To: <20161018075625.243636391eggemoggin.niobe.net> References: <20160913155640.71291CD3B6@eggemoggin.niobe.net> <20161018075625.243636391eggemoggin.niobe.net> Message-ID: <20161018080349.199713821eggemoggin.niobe.net> 2016/10/18 7:56:25 -0700, mark.reinhold at oracle.com: > ... > > [2] http://localhost:8081/projects/jdk9/fc-extension-process Correction: [2] http://openjdk.java.net/projects/jdk9/fc-extension-process (D'oh!) - Mark From naoto.sato at oracle.com Tue Oct 18 16:00:50 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 18 Oct 2016 09:00:50 -0700 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: Vote: yes Naoto On 10/18/16 2:35 AM, Masayoshi Okutsu wrote: > I hereby nominate Nishit Jain to JDK 9 Committer. > > Nishit is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. > He has made 18 contributions to JDK 9 [3]. > > Votes are due by Oct 31, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Masayoshi > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) > > From dean.long at oracle.com Tue Oct 18 19:43:32 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Oct 2016 12:43:32 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> Message-ID: <2d9c263e-c6c1-c2e3-9ac4-12f330bf78ce@oracle.com> Hi Thomas, On 10/18/16 7:39 AM, Thomas St?fe wrote: > Hi all, > > On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi, >> >> I'm on a 1.6 TB share available to our team visible on all our >> servers. The machine is a 48 processor 64GB linux x86_64 server. >> The servers only have limited local disc space. Especially with the >> new setup I can not have clones on all the machines I need to compile >> and test on. >> >> Best regards, >> Goetz. >> >> > I'm on Goetz team at SAP. Just wanted to give some additional information: > > I keep reading "use local repos". This is unfortunately not practical for > us. Limited local disk space on build machines is only the smallest of the > problems. A bigger problem is our platform breadth. > > We have a large zoo of machines running a number of cpu/os combinations. > When we develop for the OpenJDK, we want to build and test on multiple - > preferably all - machines and platforms the OpenJDK is supported on, to > make sure we do not introduce regressions. But we have no automatic build > system for these platforms, nor do we have access to your jprt. > > So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc, > s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave > out platforms I think are safe - in this case 32bit and zero - but at my > own risk, because if I introduce a regression because I do not build, I > risk the annoyance of other developers. > > Therefore local repos are not practical - syncing local repos across many > machines is a pain and very error prone. So, every developer keeps his > repos on a filer (NFS) and so if the NFS client on a certain machine is not > good, we wait and suffer. > > So performance matters for us a lot. I'm curious if you are using file caching on the NFS clients. That feature should be available on linux and solaris at least, and would hopefully improve performance. dl > Kind Regards, Thomas > > >>> -----Original Message----- >>> From: Erik Helin [mailto:erik.helin at oracle.com] >>> Sent: Montag, 17. Oktober 2016 13:42 >>> To: Lindenmaier, Goetz >>> Cc: Anthony Vanelverdinghe ; jdk9- >>> dev at openjdk.java.net >>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 >>> >>> On 2016-10-17, Lindenmaier, Goetz wrote: >>>> Hi Anthony and Joe, >>>> >>>>> such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, >> and hg >>> commit --amend" [7]. >>>> I understand how these commands replace hg queues. >>>> I don't understand how they replace having several >>>> clones to do something like this: >>>> - Change 1 is compiling (in clone 1) >>>> - Debugging change 2 (in clone 2) >>>> - I get a review and want to immediately edit change 3 (in clone 3), >> without >>>> invalidating the sources I stepped in the debugging session and >> without >>>> canceling the builds. >>> I would recommend two similar but slighty different workflows for this: >>> - local clones (as previously discussed). One local clone per >>> feature/bug/review/debugging-session. >>> - shares, using `hg share` and bookmarks. One bookmark in each hg share. >>> >>>> If I use a single clone, I can have these three changes in three >> branches, >>>> or in several sequential changes (like a mercurial queue) I keep >> reordering >>> with >>>> histedit. But as there is only one source tree I can only work on one >> of >>>> the changes at a time. >>>> Hg share will do this job I assume. >>>> >>>> I have been looking at the consol-proto: >>> The timings seems an order of magnitude off? What kind of machine are >>> you using? See inline for my measurements, all done on a 1 year old >>> Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg >>> version 3.8.1. >>> >>>> hg clone takes 30 minutes. Before, get_source.sh took 20 mins. >>> $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>> requesting all changes >>> adding changesets >>> adding manifests >>> adding file changes >>> added 41157 changesets with 358201 changes to 148305 files >>> updating to branch default >>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>> >>> real 17m42.057s >>> user 4m37.156s >>> sys 0m41.153s >>> >>> The time for the remote clone will depend mostly on yours (and >>> Oracle's) network. The amount of bits that needs to be transferred are >>> almost the same (differs on a few MB IIRC) compared to a forest. The >>> difference is that the forest downloads the metadata for multiple >>> repositories in parallel. >>> >>> I know you find it cumbersome, but my recommendation here would be to >>> not clone that often from the remote servers. Since mercurial is a DVCS, >>> you already have most of the bits locally on your machine if you've >>> already cloned once. >>> >>>> Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. >>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>> $ time hg share --bookmarks consol-proto share >>> updating working directory >>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>> >>> real 0m7.528s >>> user 0m28.442s >>> sys 0m9.791s >>> >>> I have no idea why it takes 5 (or even 3) minutes on your machine? >>> >>>> Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. >>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>> $ cd consol-proto/src/hotspot/ >>> $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560- >>> basic_s390/hotspot.wr04/hotspot.changeset >>> $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent >>> $ time hg diff >>> M src/hotspot/os/linux/vm/os_linux.cpp >>> M src/hotspot/share/tools/hsdis/hsdis.c >>> M src/hotspot/share/vm/code/codeCache.cpp >>> M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp >>> M src/hotspot/share/vm/runtime/globals.hpp >>> M src/hotspot/share/vm/runtime/vm_version.cpp >>> M src/hotspot/share/vm/utilities/macros.hpp >>> ? src/hotspot/hotspot.changeset >>> ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig >>> ? src/hotspot/share/vm/runtime/globals.hpp.orig >>> >>> real 0m0.787s >>> user 0m0.587s >>> sys 0m0.200s >>> >>> What patch/changes did you apply before running `hg diff`? I have hard >>> time getting `hg diff` to take longer than 1 second... >>> >>>> The full repo requires 1.9G. >>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>> $ du -ms consol-proto >>> 1754 consol-proto/ >>> >>> I don't know why yours is 191 MB larger than mine. Different filesystem >>> and or hg version? >>> >>>> A 'hg share' repo requires 0.6G >>> $ mkdir measurements && cd measurements >>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>> $ du -ms . >>> 1754 . >>> >>> $ hg share console-proto share >>> $ du -ms . >>> 2415 . >>> >>> so 2415 - 1754 = 661 MB for a share, so similar to my measurements. >>> >>> Thanks, >>> Erik >>> >>>> A hotspot repo before required 0.2G. >>>> >>>> I will be able to live with this using modern, slower functionality ;) >>>> But it imposes a considerable overhead in hardware, tool runtime >>>> and administration on my side. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Can I check out several >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf >>> Of >>>>> Anthony Vanelverdinghe >>>>> Sent: Freitag, 14. Oktober 2016 22:11 >>>>> To: jdk9-dev at openjdk.java.net >>>>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK >> 10 >>>>> Hi >>>>> >>>>> While I'm not an OpenJDK committer (yet, hope to become so one fine >>>>> day), I believe this is a great initiative. Since several people have >>>>> raised concerns related to the increased repository size, I just >> wanted >>>>> to point out that both Facebook and Mozilla work with Mercurial >>>>> repositories which dwarf a typical OpenJDK repository. For example, a >>>>> clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev >> is >>>>> less than 1 GB. >>>>> >>>>> There are also several Mercurial extensions which may prove to be >> useful >>>>> for people having to work with large repositories and/or adapt their >>>>> workflows. >>>>> During their work to scale Mercurial [2], Facebook contributed/made >>>>> several extensions, such as fsmonitor as mentioned by Joe [3], and >> the >>>>> ones in their BitBucket repository [4], such as remotefilelog [5]. >>>>> When working with local clones, the share extension may be helpful >> [6]. >>>>> Finally, note that mq is "often considered for deprecation", so this >> may >>>>> be an opportunity to adopt "modern tools, such as hg rebase, hg >>>>> histedit, hg graft, hg strip, hg strip --keep, and hg commit >> --amend" [7]. >>>>> Kind regards, >>>>> Anthony >>>>> >>>>> [1] https://hg.mozilla.org/mozilla-central/ >>>>> [2] >>>>> https://code.facebook.com/posts/218678814984400/scaling-mercurial- >>> at- >>>>> facebook/ >>>>> [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >>>>> October/004990.html >>>>> [4] https://bitbucket.org/facebook/hg-experimental >>>>> [5] >>>>> https://bitbucket.org/facebook/hg- >>>>> >>> experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel >>>>> og/?at=default >>>>> [6] https://www.mercurial-scm.org/wiki/ShareExtension >>>>> [7] https://www.mercurial-scm.org/wiki/MqExtension >>>>> >>>>> On 14/10/2016 19:03, Brian Goetz wrote: >>>>>>> Conversely, I think it is reasonable for engineers making changes >> to >>>>>>> the JDK to be wiling to offer some flexibility in adjusting >>>>>>> established worksflows optimized for the split repositories to >>>>>>> accommodate the sort of infrastructure changes being proposed here >>>>>>> for a consolidated one. >>>>>> Let me amplify this: OpenJDK developers are not the only >> stakeholders >>>>>> here. By aligning more with the way the rest of the world >> develops >>>>>> -- all code in one linearized, transactionally updated repo -- it >>>>>> increases the feasibility / reduces the cost of tools like >> 'bisect' to >>>>>> determine where a fault was introduced. This reduces SQE costs and >>>>>> increases product quality -- something we all have a stake in. >> David >>>>>> Lloyd has pointed up other tooling-related benefits, such as >> making it >>>>>> easier to maintain a git mirror. >>>>>> >>>>>> Most of the objections raised so far have been "(I think they will) >>>>>> make my life harder." Fair enough; people should be their own >>>>>> advocates. But let's not forget the significant benefits that >> accrue >>>>>> to *everyone* as a result, and keep those in mind when judging the >>>>>> pros and cons. >>>>>> >>>>>> >>>>>> From jonathan.gibbons at oracle.com Wed Oct 19 00:22:49 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 18 Oct 2016 17:22:49 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <172f636e-1a3d-c22c-be72-b92d3935a097@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> <20161017114706.GB28184@ehelin.jrpg.bea.com> <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> <172f636e-1a3d-c22c-be72-b92d3935a097@oracle.com> Message-ID: <5806BCD9.1020409@oracle.com> On 10/18/2016 06:59 AM, Erik Helin wrote: >> > > You mean that you can work on the langtools repository only? Do you > only need a boot JDK? How do you build in those cases? I assumed that > langtools, like all the other repositories, were building from the top > repository? Currently, with the langtools repo, you only need the repo and a reasonably-recent build of JDK. The langtools repo has its own Ant script to build the langtools modules, which is easy enough since it's all Java code. The Ant script is set up to support IDE integration and debugging: some of us use NetBeans, others use IntelliJ. The --patch-path option is used to override the langtools modules in the JDK image with the new locally built versions. The technique should be reasonably applicable to anyone just working on plain old Java code. -- Jon From thomas.stuefe at gmail.com Wed Oct 19 05:20:34 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 19 Oct 2016 07:20:34 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <2d9c263e-c6c1-c2e3-9ac4-12f330bf78ce@oracle.com> References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> <2d9c263e-c6c1-c2e3-9ac4-12f330bf78ce@oracle.com> Message-ID: Hi Dean, On Tue, Oct 18, 2016 at 9:43 PM, wrote: > Hi Thomas, > > > > On 10/18/16 7:39 AM, Thomas St?fe wrote: > > Hi all, >> >> On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz < >> goetz.lindenmaier at sap.com> wrote: >> >> Hi, >>> >>> I'm on a 1.6 TB share available to our team visible on all our >>> servers. The machine is a 48 processor 64GB linux x86_64 server. >>> The servers only have limited local disc space. Especially with the >>> new setup I can not have clones on all the machines I need to compile >>> and test on. >>> >>> Best regards, >>> Goetz. >>> >>> >>> I'm on Goetz team at SAP. Just wanted to give some additional >> information: >> >> I keep reading "use local repos". This is unfortunately not practical for >> us. Limited local disk space on build machines is only the smallest of the >> problems. A bigger problem is our platform breadth. >> >> We have a large zoo of machines running a number of cpu/os combinations. >> When we develop for the OpenJDK, we want to build and test on multiple - >> preferably all - machines and platforms the OpenJDK is supported on, to >> make sure we do not introduce regressions. But we have no automatic build >> system for these platforms, nor do we have access to your jprt. >> >> So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc, >> s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave >> out platforms I think are safe - in this case 32bit and zero - but at my >> own risk, because if I introduce a regression because I do not build, I >> risk the annoyance of other developers. >> >> Therefore local repos are not practical - syncing local repos across many >> machines is a pain and very error prone. So, every developer keeps his >> repos on a filer (NFS) and so if the NFS client on a certain machine is >> not >> good, we wait and suffer. >> >> So performance matters for us a lot. >> > > I'm curious if you are using file caching on the NFS clients. That > feature should be available on linux and solaris at least, and would > hopefully improve performance. > > Thanks for the hint! We have not all machines we work under our control, but we can see what we can do. Thomas > dl > > > Kind Regards, Thomas >> >> >> -----Original Message----- >>>> From: Erik Helin [mailto:erik.helin at oracle.com] >>>> Sent: Montag, 17. Oktober 2016 13:42 >>>> To: Lindenmaier, Goetz >>>> Cc: Anthony Vanelverdinghe ; jdk9- >>>> dev at openjdk.java.net >>>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 >>>> >>>> On 2016-10-17, Lindenmaier, Goetz wrote: >>>> >>>>> Hi Anthony and Joe, >>>>> >>>>> such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, >>>>>> >>>>> and hg >>> >>>> commit --amend" [7]. >>>> >>>>> I understand how these commands replace hg queues. >>>>> I don't understand how they replace having several >>>>> clones to do something like this: >>>>> - Change 1 is compiling (in clone 1) >>>>> - Debugging change 2 (in clone 2) >>>>> - I get a review and want to immediately edit change 3 (in clone 3), >>>>> >>>> without >>> >>>> invalidating the sources I stepped in the debugging session and >>>>> >>>> without >>> >>>> canceling the builds. >>>>> >>>> I would recommend two similar but slighty different workflows for this: >>>> - local clones (as previously discussed). One local clone per >>>> feature/bug/review/debugging-session. >>>> - shares, using `hg share` and bookmarks. One bookmark in each hg share. >>>> >>>> If I use a single clone, I can have these three changes in three >>>>> >>>> branches, >>> >>>> or in several sequential changes (like a mercurial queue) I keep >>>>> >>>> reordering >>> >>>> with >>>> >>>>> histedit. But as there is only one source tree I can only work on one >>>>> >>>> of >>> >>>> the changes at a time. >>>>> Hg share will do this job I assume. >>>>> >>>>> I have been looking at the consol-proto: >>>>> >>>> The timings seems an order of magnitude off? What kind of machine are >>>> you using? See inline for my measurements, all done on a 1 year old >>>> Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg >>>> version 3.8.1. >>>> >>>> hg clone takes 30 minutes. Before, get_source.sh took 20 mins. >>>>> >>>> $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>> requesting all changes >>>> adding changesets >>>> adding manifests >>>> adding file changes >>>> added 41157 changesets with 358201 changes to 148305 files >>>> updating to branch default >>>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>>> >>>> real 17m42.057s >>>> user 4m37.156s >>>> sys 0m41.153s >>>> >>>> The time for the remote clone will depend mostly on yours (and >>>> Oracle's) network. The amount of bits that needs to be transferred are >>>> almost the same (differs on a few MB IIRC) compared to a forest. The >>>> difference is that the forest downloads the metadata for multiple >>>> repositories in parallel. >>>> >>>> I know you find it cumbersome, but my recommendation here would be to >>>> not clone that often from the remote servers. Since mercurial is a DVCS, >>>> you already have most of the bits locally on your machine if you've >>>> already cloned once. >>>> >>>> Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. >>>>> >>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>> $ time hg share --bookmarks consol-proto share >>>> updating working directory >>>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>>> >>>> real 0m7.528s >>>> user 0m28.442s >>>> sys 0m9.791s >>>> >>>> I have no idea why it takes 5 (or even 3) minutes on your machine? >>>> >>>> Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. >>>>> >>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>> $ cd consol-proto/src/hotspot/ >>>> $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560- >>>> basic_s390/hotspot.wr04/hotspot.changeset >>>> $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent >>>> $ time hg diff >>>> M src/hotspot/os/linux/vm/os_linux.cpp >>>> M src/hotspot/share/tools/hsdis/hsdis.c >>>> M src/hotspot/share/vm/code/codeCache.cpp >>>> M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp >>>> M src/hotspot/share/vm/runtime/globals.hpp >>>> M src/hotspot/share/vm/runtime/vm_version.cpp >>>> M src/hotspot/share/vm/utilities/macros.hpp >>>> ? src/hotspot/hotspot.changeset >>>> ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig >>>> ? src/hotspot/share/vm/runtime/globals.hpp.orig >>>> >>>> real 0m0.787s >>>> user 0m0.587s >>>> sys 0m0.200s >>>> >>>> What patch/changes did you apply before running `hg diff`? I have hard >>>> time getting `hg diff` to take longer than 1 second... >>>> >>>> The full repo requires 1.9G. >>>>> >>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>> $ du -ms consol-proto >>>> 1754 consol-proto/ >>>> >>>> I don't know why yours is 191 MB larger than mine. Different filesystem >>>> and or hg version? >>>> >>>> A 'hg share' repo requires 0.6G >>>>> >>>> $ mkdir measurements && cd measurements >>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>> $ du -ms . >>>> 1754 . >>>> >>>> $ hg share console-proto share >>>> $ du -ms . >>>> 2415 . >>>> >>>> so 2415 - 1754 = 661 MB for a share, so similar to my measurements. >>>> >>>> Thanks, >>>> Erik >>>> >>>> A hotspot repo before required 0.2G. >>>>> >>>>> I will be able to live with this using modern, slower functionality ;) >>>>> But it imposes a considerable overhead in hardware, tool runtime >>>>> and administration on my side. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Can I check out several >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>>> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf >>>>>> >>>>> Of >>>> >>>>> Anthony Vanelverdinghe >>>>>> Sent: Freitag, 14. Oktober 2016 22:11 >>>>>> To: jdk9-dev at openjdk.java.net >>>>>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK >>>>>> >>>>> 10 >>> >>>> Hi >>>>>> >>>>>> While I'm not an OpenJDK committer (yet, hope to become so one fine >>>>>> day), I believe this is a great initiative. Since several people have >>>>>> raised concerns related to the increased repository size, I just >>>>>> >>>>> wanted >>> >>>> to point out that both Facebook and Mozilla work with Mercurial >>>>>> repositories which dwarf a typical OpenJDK repository. For example, a >>>>>> clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev >>>>>> >>>>> is >>> >>>> less than 1 GB. >>>>>> >>>>>> There are also several Mercurial extensions which may prove to be >>>>>> >>>>> useful >>> >>>> for people having to work with large repositories and/or adapt their >>>>>> workflows. >>>>>> During their work to scale Mercurial [2], Facebook contributed/made >>>>>> several extensions, such as fsmonitor as mentioned by Joe [3], and >>>>>> >>>>> the >>> >>>> ones in their BitBucket repository [4], such as remotefilelog [5]. >>>>>> When working with local clones, the share extension may be helpful >>>>>> >>>>> [6]. >>> >>>> Finally, note that mq is "often considered for deprecation", so this >>>>>> >>>>> may >>> >>>> be an opportunity to adopt "modern tools, such as hg rebase, hg >>>>>> histedit, hg graft, hg strip, hg strip --keep, and hg commit >>>>>> >>>>> --amend" [7]. >>> >>>> Kind regards, >>>>>> Anthony >>>>>> >>>>>> [1] https://hg.mozilla.org/mozilla-central/ >>>>>> [2] >>>>>> https://code.facebook.com/posts/218678814984400/scaling-mercurial- >>>>>> >>>>> at- >>>> >>>>> facebook/ >>>>>> [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >>>>>> October/004990.html >>>>>> [4] https://bitbucket.org/facebook/hg-experimental >>>>>> [5] >>>>>> https://bitbucket.org/facebook/hg- >>>>>> >>>>>> experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel >>>> >>>>> og/?at=default >>>>>> [6] https://www.mercurial-scm.org/wiki/ShareExtension >>>>>> [7] https://www.mercurial-scm.org/wiki/MqExtension >>>>>> >>>>>> On 14/10/2016 19:03, Brian Goetz wrote: >>>>>> >>>>>>> Conversely, I think it is reasonable for engineers making changes >>>>>>>> >>>>>>> to >>> >>>> the JDK to be wiling to offer some flexibility in adjusting >>>>>>>> established worksflows optimized for the split repositories to >>>>>>>> accommodate the sort of infrastructure changes being proposed here >>>>>>>> for a consolidated one. >>>>>>>> >>>>>>> Let me amplify this: OpenJDK developers are not the only >>>>>>> >>>>>> stakeholders >>> >>>> here. By aligning more with the way the rest of the world >>>>>>> >>>>>> develops >>> >>>> -- all code in one linearized, transactionally updated repo -- it >>>>>>> increases the feasibility / reduces the cost of tools like >>>>>>> >>>>>> 'bisect' to >>> >>>> determine where a fault was introduced. This reduces SQE costs and >>>>>>> increases product quality -- something we all have a stake in. >>>>>>> >>>>>> David >>> >>>> Lloyd has pointed up other tooling-related benefits, such as >>>>>>> >>>>>> making it >>> >>>> easier to maintain a git mirror. >>>>>>> >>>>>>> Most of the objections raised so far have been "(I think they will) >>>>>>> make my life harder." Fair enough; people should be their own >>>>>>> advocates. But let's not forget the significant benefits that >>>>>>> >>>>>> accrue >>> >>>> to *everyone* as a result, and keep those in mind when judging the >>>>>>> pros and cons. >>>>>>> >>>>>>> >>>>>>> >>>>>>> > From maurizio.cimadamore at oracle.com Wed Oct 19 10:12:26 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 19 Oct 2016 11:12:26 +0100 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <5806BCD9.1020409@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> <20161017114706.GB28184@ehelin.jrpg.bea.com> <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> <172f636e-1a3d-c22c-be72-b92d3935a097@oracle.com> <5806BCD9.1020409@oracle.com> Message-ID: <797145dc-f885-8630-15f0-7f4dd940faf8@oracle.com> On 19/10/16 01:22, Jonathan Gibbons wrote: > > > On 10/18/2016 06:59 AM, Erik Helin wrote: >>> >> >> You mean that you can work on the langtools repository only? Do you >> only need a boot JDK? How do you build in those cases? I assumed that >> langtools, like all the other repositories, were building from the >> top repository? > > Currently, with the langtools repo, you only need the repo and a > reasonably-recent build of JDK. The langtools repo has its own Ant > script to build the langtools modules, which is easy enough since it's > all Java code. The Ant script is set up to support IDE integration and > debugging: some of us use NetBeans, others use IntelliJ. The > --patch-path option is used to override the langtools modules in the > JDK image with the new locally built versions. > > The technique should be reasonably applicable to anyone just working > on plain old Java code. Pretty much what Jon said - you can work in langtools in isolation, provided you have a pointer to a reasonably recent JDK 9 image (the degree of freshness of such JDK image depends on how much work is going on - if things are stable, 'recent' could well mean 3-4 months old; if things are hot - as now - 'recent' typically means a couple of weeks). Yesterday I did some experiments to compare build times of the local langtools script vs. toplevel make; the table below summarizes the results. I've compared both 'cold build' times (i.e. build from a clean state) and 'incremental build' times. I did the latter by touching a file in a given module, and then relaunching the build command again. *Test type* *Time (make)* *Time (ant)* all 5 langtools modules (cold build) 4m 18s java.compiler (incremental) 28s 3s jdk.compiler (incremental) 25s 3s jdk.javadoc (incremental) 12s 2s jdk.jdeps (incremental) 7s 2s jdk.jshell (incremental) 5s 2s As you can see, the different in the cold case is pretty stark. Now, you should normally not pay the price for this always - however, any change that triggers a 'reconfigure' can potentially spawn a cold build time. If we move on to consider incremental build times, we can see two categories: * java.compiler, jdk.compiler, jdk.javadoc - those tools have an 'interim' stage in the toplevel make build - which make incremental compilation quite slower compared to ant * jdk.jdeps and jdk.jshell are simple leaves - while the ant build is faster, I think the difference is not significant I tend to work on jdk.compiler most of the time, and, for me, the difference in usability between a 30s incremental build and a 3s one is pretty significant, especially when working with an IDE. Which is why, at the moment at least, I'm sticking with the internal ant build. Of course, should things improve for the modules in the first category, then the extra benefits of using a single build would be enough to offset the minor incremental slow down (and the one off 'cold' big slow down). P.S. I've seen other ant builds around (Nashorn IIRC) - I'd be interested to know what other folks in similar situation think about this. Maurizio From erik.helin at oracle.com Wed Oct 19 14:32:03 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 19 Oct 2016 16:32:03 +0200 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: <797145dc-f885-8630-15f0-7f4dd940faf8@oracle.com> References: <4ea8f2e7-7a10-e949-d920-81ae5f610f24@oracle.com> <52c77cb8-0e1c-a4c7-7b51-5216b44cbb79@oracle.com> <20161017114706.GB28184@ehelin.jrpg.bea.com> <6e7c4bad-ef13-0f3a-a4c6-ce7ae6a6c965@oracle.com> <172f636e-1a3d-c22c-be72-b92d3935a097@oracle.com> <5806BCD9.1020409@oracle.com> <797145dc-f885-8630-15f0-7f4dd940faf8@oracle.com> Message-ID: <20161019143203.GC19291@ehelin.jrpg.bea.com> On 2016-10-19, Maurizio Cimadamore wrote: > > > On 19/10/16 01:22, Jonathan Gibbons wrote: > > > > > >On 10/18/2016 06:59 AM, Erik Helin wrote: > >>> > >> > >>You mean that you can work on the langtools repository only? Do you only > >>need a boot JDK? How do you build in those cases? I assumed that > >>langtools, like all the other repositories, were building from the top > >>repository? > > > >Currently, with the langtools repo, you only need the repo and a > >reasonably-recent build of JDK. The langtools repo has its own Ant script > >to build the langtools modules, which is easy enough since it's all Java > >code. The Ant script is set up to support IDE integration and debugging: > >some of us use NetBeans, others use IntelliJ. The --patch-path option is > >used to override the langtools modules in the JDK image with the new > >locally built versions. > > > >The technique should be reasonably applicable to anyone just working on > >plain old Java code. > Pretty much what Jon said - you can work in langtools in isolation, provided > you have a pointer to a reasonably recent JDK 9 image (the degree of > freshness of such JDK image depends on how much work is going on - if things > are stable, 'recent' could well mean 3-4 months old; if things are hot - as > now - 'recent' typically means a couple of weeks). And you will be able to work in langtools in isolation (or rather the langtools modules in isolation). The only difference is that you know will get the entire source tree, you can't just get the langtools directory. However, you can still change directory to the module you are working on and use your ant build files in combination with a reasonably recent build of JDK. Again, the only difference is the number of files of the initial clone (or local clone, or share). Thanks, Erik > Yesterday I did some experiments to compare build times of the local > langtools script vs. toplevel make; the table below summarizes the results. > I've compared both 'cold build' times (i.e. build from a clean state) and > 'incremental build' times. I did the latter by touching a file in a given > module, and then relaunching the build command again. > > > *Test type* > *Time (make)* > *Time (ant)* > all 5 langtools modules (cold build) > 4m > 18s > java.compiler (incremental) > 28s > 3s > jdk.compiler (incremental) > 25s > 3s > jdk.javadoc (incremental) > 12s > 2s > jdk.jdeps (incremental) > 7s > 2s > jdk.jshell (incremental) > 5s > 2s > > > > As you can see, the different in the cold case is pretty stark. Now, you > should normally not pay the price for this always - however, any change that > triggers a 'reconfigure' can potentially spawn a cold build time. > > If we move on to consider incremental build times, we can see two > categories: > > * java.compiler, jdk.compiler, jdk.javadoc - those tools have an 'interim' > stage in the toplevel make build - which make incremental compilation quite > slower compared to ant > * jdk.jdeps and jdk.jshell are simple leaves - while the ant build is > faster, I think the difference is not significant > > I tend to work on jdk.compiler most of the time, and, for me, the difference > in usability between a 30s incremental build and a 3s one is pretty > significant, especially when working with an IDE. Which is why, at the > moment at least, I'm sticking with the internal ant build. > > Of course, should things improve for the modules in the first category, then > the extra benefits of using a single build would be enough to offset the > minor incremental slow down (and the one off 'cold' big slow down). > > P.S. > I've seen other ant builds around (Nashorn IIRC) - I'd be interested to know > what other folks in similar situation think about this. > > Maurizio > From mark.reinhold at oracle.com Wed Oct 19 17:14:49 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 19 Oct 2016 10:14:49 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) Message-ID: <20161019101449.402617700eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 294: Linux/s390x Port http://openjdk.java.net/jeps/294 295: Ahead-of-Time Compilation http://openjdk.java.net/jeps/295 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Wednesday, 26 October, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 9. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/projects/jdk9/ From jonathan.gibbons at oracle.com Wed Oct 19 18:33:38 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 Oct 2016 11:33:38 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> <2d9c263e-c6c1-c2e3-9ac4-12f330bf78ce@oracle.com> Message-ID: <33ae03da-f235-d78e-ddcf-e5f7de9c32da@oracle.com> The other advice I've given NFS users in the past is to copy (rsync) files to or from the local disk before or after the build, so that the build (and test run?) use local files. It does assume you have enough local disk space, of course. -- Jon On 10/18/16 10:20 PM, Thomas St?fe wrote: > Hi Dean, > > On Tue, Oct 18, 2016 at 9:43 PM, wrote: > >> Hi Thomas, >> >> >> >> On 10/18/16 7:39 AM, Thomas St?fe wrote: >> >> Hi all, >>> On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz < >>> goetz.lindenmaier at sap.com> wrote: >>> >>> Hi, >>>> I'm on a 1.6 TB share available to our team visible on all our >>>> servers. The machine is a 48 processor 64GB linux x86_64 server. >>>> The servers only have limited local disc space. Especially with the >>>> new setup I can not have clones on all the machines I need to compile >>>> and test on. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> I'm on Goetz team at SAP. Just wanted to give some additional >>> information: >>> >>> I keep reading "use local repos". This is unfortunately not practical for >>> us. Limited local disk space on build machines is only the smallest of the >>> problems. A bigger problem is our platform breadth. >>> >>> We have a large zoo of machines running a number of cpu/os combinations. >>> When we develop for the OpenJDK, we want to build and test on multiple - >>> preferably all - machines and platforms the OpenJDK is supported on, to >>> make sure we do not introduce regressions. But we have no automatic build >>> system for these platforms, nor do we have access to your jprt. >>> >>> So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc, >>> s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave >>> out platforms I think are safe - in this case 32bit and zero - but at my >>> own risk, because if I introduce a regression because I do not build, I >>> risk the annoyance of other developers. >>> >>> Therefore local repos are not practical - syncing local repos across many >>> machines is a pain and very error prone. So, every developer keeps his >>> repos on a filer (NFS) and so if the NFS client on a certain machine is >>> not >>> good, we wait and suffer. >>> >>> So performance matters for us a lot. >>> >> I'm curious if you are using file caching on the NFS clients. That >> feature should be available on linux and solaris at least, and would >> hopefully improve performance. >> >> > Thanks for the hint! We have not all machines we work under our control, > but we can see what we can do. > > Thomas > > >> dl >> >> >> Kind Regards, Thomas >>> >>> -----Original Message----- >>>>> From: Erik Helin [mailto:erik.helin at oracle.com] >>>>> Sent: Montag, 17. Oktober 2016 13:42 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Anthony Vanelverdinghe ; jdk9- >>>>> dev at openjdk.java.net >>>>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10 >>>>> >>>>> On 2016-10-17, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi Anthony and Joe, >>>>>> >>>>>> such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, >>>>>> and hg >>>>> commit --amend" [7]. >>>>> >>>>>> I understand how these commands replace hg queues. >>>>>> I don't understand how they replace having several >>>>>> clones to do something like this: >>>>>> - Change 1 is compiling (in clone 1) >>>>>> - Debugging change 2 (in clone 2) >>>>>> - I get a review and want to immediately edit change 3 (in clone 3), >>>>>> >>>>> without >>>>> invalidating the sources I stepped in the debugging session and >>>>> without >>>>> canceling the builds. >>>>> I would recommend two similar but slighty different workflows for this: >>>>> - local clones (as previously discussed). One local clone per >>>>> feature/bug/review/debugging-session. >>>>> - shares, using `hg share` and bookmarks. One bookmark in each hg share. >>>>> >>>>> If I use a single clone, I can have these three changes in three >>>>> branches, >>>>> or in several sequential changes (like a mercurial queue) I keep >>>>> reordering >>>>> with >>>>> >>>>>> histedit. But as there is only one source tree I can only work on one >>>>>> >>>>> of >>>>> the changes at a time. >>>>>> Hg share will do this job I assume. >>>>>> >>>>>> I have been looking at the consol-proto: >>>>>> >>>>> The timings seems an order of magnitude off? What kind of machine are >>>>> you using? See inline for my measurements, all done on a 1 year old >>>>> Samsung SSD with an ext4 filesystem and Linux kernel 4.3.3. I'm using hg >>>>> version 3.8.1. >>>>> >>>>> hg clone takes 30 minutes. Before, get_source.sh took 20 mins. >>>>> $ time hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>>> requesting all changes >>>>> adding changesets >>>>> adding manifests >>>>> adding file changes >>>>> added 41157 changesets with 358201 changes to 148305 files >>>>> updating to branch default >>>>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>>>> >>>>> real 17m42.057s >>>>> user 4m37.156s >>>>> sys 0m41.153s >>>>> >>>>> The time for the remote clone will depend mostly on yours (and >>>>> Oracle's) network. The amount of bits that needs to be transferred are >>>>> almost the same (differs on a few MB IIRC) compared to a forest. The >>>>> difference is that the forest downloads the metadata for multiple >>>>> repositories in parallel. >>>>> >>>>> I know you find it cumbersome, but my recommendation here would be to >>>>> not clone that often from the remote servers. Since mercurial is a DVCS, >>>>> you already have most of the bits locally on your machine if you've >>>>> already cloned once. >>>>> >>>>> Hg share takes 5 minutes. Before, hg clone of hotspot took 3 mins. >>>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>>> $ time hg share --bookmarks consol-proto share >>>>> updating working directory >>>>> 53435 files updated, 0 files merged, 0 files removed, 0 files unresolved >>>>> >>>>> real 0m7.528s >>>>> user 0m28.442s >>>>> sys 0m9.791s >>>>> >>>>> I have no idea why it takes 5 (or even 3) minutes on your machine? >>>>> >>>>> Hg diff takes 32 secs!!!, before it took 4 secs on hotspot repo. >>>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>>> $ cd consol-proto/src/hotspot/ >>>>> $ wget http://cr.openjdk.java.net/~goetz/wr16/8166560- >>>>> basic_s390/hotspot.wr04/hotspot.changeset >>>>> $ patch -p2 hotspot.changeset # skip changes to jdk.hotspot.agent >>>>> $ time hg diff >>>>> M src/hotspot/os/linux/vm/os_linux.cpp >>>>> M src/hotspot/share/tools/hsdis/hsdis.c >>>>> M src/hotspot/share/vm/code/codeCache.cpp >>>>> M src/hotspot/share/vm/interpreter/abstractInterpreter.hpp >>>>> M src/hotspot/share/vm/runtime/globals.hpp >>>>> M src/hotspot/share/vm/runtime/vm_version.cpp >>>>> M src/hotspot/share/vm/utilities/macros.hpp >>>>> ? src/hotspot/hotspot.changeset >>>>> ? src/hotspot/share/vm/interpreter/abstractInterpreter.hpp.orig >>>>> ? src/hotspot/share/vm/runtime/globals.hpp.orig >>>>> >>>>> real 0m0.787s >>>>> user 0m0.587s >>>>> sys 0m0.200s >>>>> >>>>> What patch/changes did you apply before running `hg diff`? I have hard >>>>> time getting `hg diff` to take longer than 1 second... >>>>> >>>>> The full repo requires 1.9G. >>>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>>> $ du -ms consol-proto >>>>> 1754 consol-proto/ >>>>> >>>>> I don't know why yours is 191 MB larger than mine. Different filesystem >>>>> and or hg version? >>>>> >>>>> A 'hg share' repo requires 0.6G >>>>> $ mkdir measurements && cd measurements >>>>> $ hg clone http://hg.openjdk.java.net/jdk9/consol-proto >>>>> $ du -ms . >>>>> 1754 . >>>>> >>>>> $ hg share console-proto share >>>>> $ du -ms . >>>>> 2415 . >>>>> >>>>> so 2415 - 1754 = 661 MB for a share, so similar to my measurements. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> A hotspot repo before required 0.2G. >>>>>> I will be able to live with this using modern, slower functionality ;) >>>>>> But it imposes a considerable overhead in hardware, tool runtime >>>>>> and administration on my side. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Can I check out several >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>>> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf >>>>>>> >>>>>> Of >>>>>> Anthony Vanelverdinghe >>>>>>> Sent: Freitag, 14. Oktober 2016 22:11 >>>>>>> To: jdk9-dev at openjdk.java.net >>>>>>> Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK >>>>>>> >>>>>> 10 >>>>> Hi >>>>>>> While I'm not an OpenJDK committer (yet, hope to become so one fine >>>>>>> day), I believe this is a great initiative. Since several people have >>>>>>> raised concerns related to the increased repository size, I just >>>>>>> >>>>>> wanted >>>>> to point out that both Facebook and Mozilla work with Mercurial >>>>>>> repositories which dwarf a typical OpenJDK repository. For example, a >>>>>>> clone of mozilla-central [1] is 2.79 GB, whereas a clone of jdk9-dev >>>>>>> >>>>>> is >>>>> less than 1 GB. >>>>>>> There are also several Mercurial extensions which may prove to be >>>>>>> >>>>>> useful >>>>> for people having to work with large repositories and/or adapt their >>>>>>> workflows. >>>>>>> During their work to scale Mercurial [2], Facebook contributed/made >>>>>>> several extensions, such as fsmonitor as mentioned by Joe [3], and >>>>>>> >>>>>> the >>>>> ones in their BitBucket repository [4], such as remotefilelog [5]. >>>>>>> When working with local clones, the share extension may be helpful >>>>>>> >>>>>> [6]. >>>>> Finally, note that mq is "often considered for deprecation", so this >>>>>> may >>>>> be an opportunity to adopt "modern tools, such as hg rebase, hg >>>>>>> histedit, hg graft, hg strip, hg strip --keep, and hg commit >>>>>>> >>>>>> --amend" [7]. >>>>> Kind regards, >>>>>>> Anthony >>>>>>> >>>>>>> [1] https://hg.mozilla.org/mozilla-central/ >>>>>>> [2] >>>>>>> https://code.facebook.com/posts/218678814984400/scaling-mercurial- >>>>>>> >>>>>> at- >>>>>> facebook/ >>>>>>> [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- >>>>>>> October/004990.html >>>>>>> [4] https://bitbucket.org/facebook/hg-experimental >>>>>>> [5] >>>>>>> https://bitbucket.org/facebook/hg- >>>>>>> >>>>>>> experimental/src/d2c3a2c02eb6c7e5a7331ba0cf15e5bf7c8dc8dc/remotefilel >>>>>> og/?at=default >>>>>>> [6] https://www.mercurial-scm.org/wiki/ShareExtension >>>>>>> [7] https://www.mercurial-scm.org/wiki/MqExtension >>>>>>> >>>>>>> On 14/10/2016 19:03, Brian Goetz wrote: >>>>>>> >>>>>>>> Conversely, I think it is reasonable for engineers making changes >>>>>>>> to >>>>> the JDK to be wiling to offer some flexibility in adjusting >>>>>>>>> established worksflows optimized for the split repositories to >>>>>>>>> accommodate the sort of infrastructure changes being proposed here >>>>>>>>> for a consolidated one. >>>>>>>>> >>>>>>>> Let me amplify this: OpenJDK developers are not the only >>>>>>>> >>>>>>> stakeholders >>>>> here. By aligning more with the way the rest of the world >>>>>>> develops >>>>> -- all code in one linearized, transactionally updated repo -- it >>>>>>>> increases the feasibility / reduces the cost of tools like >>>>>>>> >>>>>>> 'bisect' to >>>>> determine where a fault was introduced. This reduces SQE costs and >>>>>>>> increases product quality -- something we all have a stake in. >>>>>>>> >>>>>>> David >>>>> Lloyd has pointed up other tooling-related benefits, such as >>>>>>> making it >>>>> easier to maintain a git mirror. >>>>>>>> Most of the objections raised so far have been "(I think they will) >>>>>>>> make my life harder." Fair enough; people should be their own >>>>>>>> advocates. But let's not forget the significant benefits that >>>>>>>> >>>>>>> accrue >>>>> to *everyone* as a result, and keep those in mind when judging the >>>>>>>> pros and cons. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From david.lloyd at redhat.com Wed Oct 19 19:39:48 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 19 Oct 2016 14:39:48 -0500 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <20161019101449.402617700eggemoggin.niobe.net> References: <20161019101449.402617700eggemoggin.niobe.net> Message-ID: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> On 10/19/2016 12:14 PM, mark.reinhold at oracle.com wrote: > 295: Ahead-of-Time Compilation > http://openjdk.java.net/jeps/295 I have a question on this one - maybe it's best addressed specifically to John Rose though, and please forgive my relatively shallow understanding of the JIT and this new AOT compiler. Does the AOT compiler depend on knowing all possible entry points into certain methods? Is it possible for things like --add-exports with reflection, which change the set of known entry points into the code, to cause unexpected operation? I saw no mention of these things on the JEP page but it was my understanding that AOT compilation depends on this kind of information. Thanks! -- - DML From lana.steuck at oracle.com Wed Oct 19 20:47:57 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 19 Oct 2016 20:47:57 GMT Subject: jdk9-b141: dev Message-ID: <201610192047.u9JKlvEC007669@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/f64afae7f1a5 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/a46b7d386795 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/296c87505118 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8d752af5f61d http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/b2c18f755228 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/037c095ba0c3 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/160a00bc6ed0 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/b32f998da32b --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8055033 core-libs Shell tests for jrunscript don't pass through VM options JDK-8134373 core-libs use collections convenience factories in the JDK JDK-8160556 core-libs LambdaForm interpretation is not tested regularly JDK-8163482 core-libs java.net.URLPermission.getActions() adds a trailing colon when header- JDK-8166258 core-libs Unexpected code conversion by HKSCS converters JDK-8166460 core-libs jdk/internal/util/jar/TestVersionedStream gets Assertion error JDK-8167166 core-libs Java API docs mention a non-existent method getNanosOfSecond JDK-8167443 core-libs Nashorn static method linking bypasses autoexported linkers JDK-8167524 core-libs Rogue character in Stream javadoc JDK-8167614 core-libs Avoid module dependency from jdk.dynalink to jdk.internal.module of ja JDK-8167957 core-libs Remove FilePermission from default policy for jdk.charsets module JDK-8167992 core-libs Update documentation of java.util.Date class JDK-8167446 hotspot Add back PermSize and MaxPermSize JDK-8167511 hotspot IgnoreModulePropertiesTest.java needs update for JDK-8162401 JDK-8157623 infrastructure Unexpected warning about ignoring value of CCACHE from environment JDK-8158181 infrastructure Stop adding missing newline to manifest files JDK-8167354 infrastructure Missing jtreg output when run using langtools makefiles JDK-8167424 infrastructure Various trivial fixes in build system JDK-8167488 infrastructure Race condition in build with new exploded-image-optimize target JDK-8162723 security-libs Array index overflow in Base64 utility class JDK-8164322 security-libs Test sun/security/pkcs11/PKCS11Test.java shall be updated to run on AR JDK-8165275 security-libs Replace the reflective call to the implUpdate method in HandshakeMessa JDK-8167371 security-libs KeyStoreSpi.engineSetEntry should throw an Exception if password prote JDK-8167459 security-libs Add debug output for indicating if a chosen ciphersuite was legacy JDK-8167472 security-libs Chrome interop regression with JDK-8148516 JDK-8141636 tools Javadoc search should support camelCase search JDK-8145263 tools JShell: Fix the format of SourceCodeAnalysis#documentation JDK-8164689 tools Retrofit jar, jlink, jmod as a ToolProvider JDK-8166890 tools JShell: locks forever when input is piped JDK-8167000 tools Refine handling of multiple maximally specific abstract methods JDK-8167128 tools jshell tool: /drop of statement gives confusing output JDK-8167237 tools Jar tool can not correctly find/process the --release option if it occ JDK-8167320 tools Trying to document only java.base causes a NPE in javac JDK-8167442 tools Langtools ant build not working after addition of -Xlint:exports JDK-8167456 tools Tweak IntelliJ langtools project's jtreg settings JDK-8167630 tools jdeps --generate-module-info forgets to close the resource after check JDK-8167965 tools (jdeprscan) using --release option with 8 or earlier throws exception JDK-8058152 xml JDK accepts XSLT stylesheet having import element erroneously placed JDK-8152530 xml NullPointerException when xmlns="" JDK-8167478 xml javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.secu From vladimir.kozlov at oracle.com Wed Oct 19 22:00:57 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Oct 2016 15:00:57 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> References: <20161019101449.402617700eggemoggin.niobe.net> <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> Message-ID: <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Sorry, David, I don't understand what do you mean under "set of known entry points into the code" and "change the set". AOT compiler is not JIT compiler. It is static compiler (similar to javac) which loads specified classes and compiles their methods *without* executing these methods (in most cases). It does execute class initializer but we may address that in a future to avoid side effects. There are also methods which are executed by Graal. AOT also records fingerprint (checksum) calculated during class loading to make sure that aot methods are used for the same class when application is run. As result if class redefinition or other methods change class corresponding aot methods will be not used anymore. Regards, Vladimir On 10/19/16 12:39 PM, David M. Lloyd wrote: > On 10/19/2016 12:14 PM, mark.reinhold at oracle.com wrote: >> 295: Ahead-of-Time Compilation >> http://openjdk.java.net/jeps/295 > > I have a question on this one - maybe it's best addressed specifically > to John Rose though, and please forgive my relatively shallow > understanding of the JIT and this new AOT compiler. > > Does the AOT compiler depend on knowing all possible entry points into > certain methods? Is it possible for things like --add-exports with > reflection, which change the set of known entry points into the code, to > cause unexpected operation? I saw no mention of these things on the JEP > page but it was my understanding that AOT compilation depends on this > kind of information. > > Thanks! From vitalyd at gmail.com Wed Oct 19 22:11:41 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 19 Oct 2016 18:11:41 -0400 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Message-ID: On Wednesday, October 19, 2016, Vladimir Kozlov wrote: > Sorry, David, I don't understand what do you mean under "set of known > entry points into the code" and "change the set". I think David must be talking about stripping the binary to just the set of methods known to be used - think of internal linkage, like static functions in C which may just get inlined and aren't present in the binary. So in Java AOT, closest parallel would be a private method but of course that's callable at runtime, so I don't see how AOT can just omit it entirely. > > AOT compiler is not JIT compiler. It is static compiler (similar to javac) > which loads specified classes and compiles their methods *without* > executing these methods (in most cases). It does execute class initializer > but we may address that in a future to avoid side effects. There > are also methods which are executed by Graal. > > AOT also records fingerprint (checksum) calculated during class loading to > make sure that aot methods are used for the same class when application is > run. As result if class redefinition or other methods change class > corresponding aot methods will be not used anymore. > > Regards, > Vladimir > > On 10/19/16 12:39 PM, David M. Lloyd wrote: > >> On 10/19/2016 12:14 PM, mark.reinhold at oracle.com wrote: >> >>> 295: Ahead-of-Time Compilation >>> http://openjdk.java.net/jeps/295 >>> >> >> I have a question on this one - maybe it's best addressed specifically >> to John Rose though, and please forgive my relatively shallow >> understanding of the JIT and this new AOT compiler. >> >> Does the AOT compiler depend on knowing all possible entry points into >> certain methods? Is it possible for things like --add-exports with >> reflection, which change the set of known entry points into the code, to >> cause unexpected operation? I saw no mention of these things on the JEP >> page but it was my understanding that AOT compilation depends on this >> kind of information. >> >> Thanks! >> > -- Sent from my phone From john.r.rose at oracle.com Wed Oct 19 22:25:15 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 19 Oct 2016 15:25:15 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Message-ID: On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich wrote: > > I think David must be talking about stripping the binary to just the set of methods known to be used - think of internal linkage, like static functions in C which may just get inlined and aren't present in the binary. So in Java AOT, closest parallel would be a private method but of course that's callable at runtime, so I don't see how AOT can just omit it entirely. AOT supports deoptimization and re-JIT-ing, so it would be easy to omit methods from AOT output, and just use interpreter or JIT to handle the execution. AOT could do stuff like tree shaking (static call graph minimization) or enforcement of strong encapsulation, but it doesn't yet. It's early days for this technology. ? John From vitalyd at gmail.com Wed Oct 19 22:31:47 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 19 Oct 2016 18:31:47 -0400 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Message-ID: On Wednesday, October 19, 2016, John Rose wrote: > On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich > wrote: > > > I think David must be talking about stripping the binary to just the set > of methods known to be used - think of internal linkage, like static > functions in C which may just get inlined and aren't present in the > binary. So in Java AOT, closest parallel would be a private method but of > course that's callable at runtime, so I don't see how AOT can just omit it > entirely. > > > AOT supports deoptimization and re-JIT-ing, so it would be easy to omit > methods from AOT output, and just use interpreter or JIT to handle the > execution. > This would have to be opt-in, I'd imagine, as otherwise it would defeat the purpose of AOT. Or it would have to very limited where it does this. Separately, what optimizations (if any) will be done in AOT? Clearly there's no profiling info, which is where the big gains typically come from, but will anything be done? For example, are loops optimized (unrolled, unswitched, etc)? Are statically known (at AOT time) callees inlined? Or is it basically C1 level of optimization (i.e. very minimal)? > > AOT could do stuff like tree shaking (static call graph minimization) or > enforcement of strong encapsulation, but it doesn't yet. It's early days > for this technology. > > ? John > -- Sent from my phone From vitalyd at gmail.com Wed Oct 19 22:35:06 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 19 Oct 2016 18:35:06 -0400 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Message-ID: Also, do you envision giving users ability to influence AOT decisions? For instance, force inlining, unlikely/likely branch hints, etc - basically similar (but likely a lot narrower) to what you have for C and C++ compilers? On Wednesday, October 19, 2016, Vitaly Davidovich wrote: > > > On Wednesday, October 19, 2016, John Rose > wrote: > >> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich wrote: >> >> >> I think David must be talking about stripping the binary to just the set >> of methods known to be used - think of internal linkage, like static >> functions in C which may just get inlined and aren't present in the >> binary. So in Java AOT, closest parallel would be a private method but of >> course that's callable at runtime, so I don't see how AOT can just omit it >> entirely. >> >> >> AOT supports deoptimization and re-JIT-ing, so it would be easy to omit >> methods from AOT output, and just use interpreter or JIT to handle the >> execution. >> > This would have to be opt-in, I'd imagine, as otherwise it would defeat > the purpose of AOT. Or it would have to very limited where it does this. > > Separately, what optimizations (if any) will be done in AOT? Clearly > there's no profiling info, which is where the big gains typically come > from, but will anything be done? For example, are loops optimized > (unrolled, unswitched, etc)? Are statically known (at AOT time) callees > inlined? Or is it basically C1 level of optimization (i.e. very minimal)? > >> >> AOT could do stuff like tree shaking (static call graph minimization) or >> enforcement of strong encapsulation, but it doesn't yet. It's early days >> for this technology. >> > >> ? John >> > > > -- > Sent from my phone > -- Sent from my phone From vladimir.kozlov at oracle.com Wed Oct 19 22:51:18 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Oct 2016 15:51:18 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> Message-ID: <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> On 10/19/16 3:31 PM, Vitaly Davidovich wrote: > > > On Wednesday, October 19, 2016, John Rose > wrote: > > On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich > wrote: >> >> I think David must be talking about stripping the binary to just >> the set of methods known to be used - think of internal linkage, >> like static functions in C which may just get inlined and aren't >> present in the binary. So in Java AOT, closest parallel would be >> a private method but of course that's callable at runtime, so I >> don't see how AOT can just omit it entirely. > > AOT supports deoptimization and re-JIT-ing, so it would be easy to > omit methods from AOT output, and just use interpreter or JIT to > handle the execution. > > This would have to be opt-in, I'd imagine, as otherwise it would defeat > the purpose of AOT. Or it would have to very limited where it does this. re-JIT-ing (generating profiling code in AOT methods) is triggered by --compile-for-tiered flag. By default is off. But AOT code is following the same deoptimization rules as normal JITed code. For example, class unloading or redefinition. > > Separately, what optimizations (if any) will be done in AOT? Clearly > there's no profiling info, which is where the big gains typically come > from, but will anything be done? For example, are loops optimized > (unrolled, unswitched, etc)? Are statically known (at AOT time) callees > inlined? Or is it basically C1 level of optimization (i.e. very minimal)? Currently it is C1 level only or even less - based on CHA without profiling information. We may add profiling information feedback in a future. No C2 type loop optimizations - Graal-core does some but not all. Also in tiered mode AOT code contains profiling code similar to Tiered level 3 in current Tiered compilation. AOT code is immutable - have to do indirect klass loads and calls. Also klass loading in AOT code is lazy - it has dynamic checks for class loading. In short - do not expect good peak performance from current AOT code. That is why we added --compile-for-tiered to re-JIT to get peak performance. We bet on compiled static initializers and skipping Interpreter for startup improvement. Vladimir > > > AOT could do stuff like tree shaking (static call graph > minimization) or enforcement of strong encapsulation, but it doesn't > yet. It's early days for this technology. > > > ? John > > > > -- > Sent from my phone From vitalyd at gmail.com Wed Oct 19 22:55:41 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 19 Oct 2016 18:55:41 -0400 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> Message-ID: Thanks Vladimir, that's very helpful to know. On Wednesday, October 19, 2016, Vladimir Kozlov wrote: > On 10/19/16 3:31 PM, Vitaly Davidovich wrote: > >> >> >> On Wednesday, October 19, 2016, John Rose > > wrote: >> >> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich > > wrote: >> >>> >>> I think David must be talking about stripping the binary to just >>> the set of methods known to be used - think of internal linkage, >>> like static functions in C which may just get inlined and aren't >>> present in the binary. So in Java AOT, closest parallel would be >>> a private method but of course that's callable at runtime, so I >>> don't see how AOT can just omit it entirely. >>> >> >> AOT supports deoptimization and re-JIT-ing, so it would be easy to >> omit methods from AOT output, and just use interpreter or JIT to >> handle the execution. >> >> This would have to be opt-in, I'd imagine, as otherwise it would defeat >> the purpose of AOT. Or it would have to very limited where it does this. >> > > re-JIT-ing (generating profiling code in AOT methods) is triggered by > --compile-for-tiered flag. By default is off. > But AOT code is following the same deoptimization rules as normal JITed > code. For example, class unloading or redefinition. > > >> Separately, what optimizations (if any) will be done in AOT? Clearly >> there's no profiling info, which is where the big gains typically come >> from, but will anything be done? For example, are loops optimized >> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees >> inlined? Or is it basically C1 level of optimization (i.e. very minimal)? >> > > Currently it is C1 level only or even less - based on CHA without > profiling information. We may add profiling information feedback in a > future. > No C2 type loop optimizations - Graal-core does some but not all. > Also in tiered mode AOT code contains profiling code similar to Tiered > level 3 in current Tiered compilation. > AOT code is immutable - have to do indirect klass loads and calls. > Also klass loading in AOT code is lazy - it has dynamic checks for class > loading. > > In short - do not expect good peak performance from current AOT code. That > is why we added --compile-for-tiered to re-JIT to get peak performance. > > We bet on compiled static initializers and skipping Interpreter for > startup improvement. > > Vladimir > > >> >> AOT could do stuff like tree shaking (static call graph >> minimization) or enforcement of strong encapsulation, but it doesn't >> yet. It's early days for this technology. >> >> >> ? John >> >> >> >> -- >> Sent from my phone >> > -- Sent from my phone From mail2leoj at gmail.com Thu Oct 20 05:59:01 2016 From: mail2leoj at gmail.com (Joel Buckley) Date: Wed, 19 Oct 2016 23:59:01 -0600 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: Message-ID: <747F1E8A-9A78-4856-8919-1A1E09B1A1E9@gmail.com> > On Oct 19, 2016, at 08:32, jdk9-dev-request at openjdk.java.net wrote: > > On 19/10/16 01:22, Jonathan Gibbons wrote: >> >> >> On 10/18/2016 06:59 AM, Erik Helin wrote: >>>> >>> >>> You mean that you can work on the langtools repository only? Do you >>> only need a boot JDK? How do you build in those cases? I assumed that >>> langtools, like all the other repositories, were building from the >>> top repository? >> >> Currently, with the langtools repo, you only need the repo and a >> reasonably-recent build of JDK. The langtools repo has its own Ant >> script to build the langtools modules, which is easy enough since it's >> all Java code. The Any thought/effort put into evaluating gradle (and/or other mechanisms) as make/ant build system replacement? [1,2,3,4,5] Comparison of build files (make Makefile, ant build.xml, gradle build.gradle) sizes and build execution times as shown earlier for make/ant would be suggested. Also, what have others seen as ?best practices? for build systems? Cheers, Joel. [1] http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608 [2] http://grokcode.com/538/ [3] https://technologyconversations.com/2014/06/18/build-tools/ [4] https://gradle.org/maven_vs_gradle/ [5] https://gradle.org/blog/open-source-build-system-evaluation-in-the-age-of-continuous-delivery-part-1/ From rajeev.chamyal at oracle.com Thu Oct 20 08:12:15 2016 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 20 Oct 2016 01:12:15 -0700 (PDT) Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: <0baf429e-5f09-4b80-a461-0f47bdb1a8ac@default> Vote : Yes. -----Original Message----- From: Masayoshi Okutsu Sent: 18 October 2016 15:06 To: jdk9-dev at openjdk.java.net Subject: CFV: New JDK9 Committer: Nishit Jain I hereby nominate Nishit Jain to JDK 9 Committer. Nishit is currently a JDK 9 Author and a member of the Internationalization team at Oracle. He has made 18 contributions to JDK 9 [3]. Votes are due by Oct 31, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Masayoshi [1]http://openjdk.java.net/census [2]http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) From mark.reinhold at oracle.com Thu Oct 20 16:13:44 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 20 Oct 2016 09:13:44 -0700 (PDT) Subject: JEP 296: Consolidate the JDK Forest into a Single Repository Message-ID: <20161020161344.2368AD7B32@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/296 - Mark From cthalinger at twitter.com Thu Oct 20 19:04:50 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 20 Oct 2016 09:04:50 -1000 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> Message-ID: <7079E2C8-2051-4F07-ABB6-997AA255F901@twitter.com> > On Oct 19, 2016, at 12:51 PM, Vladimir Kozlov wrote: > > On 10/19/16 3:31 PM, Vitaly Davidovich wrote: >> >> >> On Wednesday, October 19, 2016, John Rose >> >> wrote: >> >> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich > > wrote: >>> >>> I think David must be talking about stripping the binary to just >>> the set of methods known to be used - think of internal linkage, >>> like static functions in C which may just get inlined and aren't >>> present in the binary. So in Java AOT, closest parallel would be >>> a private method but of course that's callable at runtime, so I >>> don't see how AOT can just omit it entirely. >> >> AOT supports deoptimization and re-JIT-ing, so it would be easy to >> omit methods from AOT output, and just use interpreter or JIT to >> handle the execution. >> >> This would have to be opt-in, I'd imagine, as otherwise it would defeat >> the purpose of AOT. Or it would have to very limited where it does this. > > re-JIT-ing (generating profiling code in AOT methods) is triggered by --compile-for-tiered flag. By default is off. > But AOT code is following the same deoptimization rules as normal JITed code. For example, class unloading or redefinition. > >> >> Separately, what optimizations (if any) will be done in AOT? Clearly >> there's no profiling info, which is where the big gains typically come >> from, but will anything be done? For example, are loops optimized >> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees >> inlined? Or is it basically C1 level of optimization (i.e. very minimal)? > > Currently it is C1 level only or even less - based on CHA without profiling information. We may add profiling information feedback in a future. > No C2 type loop optimizations - Graal-core does some but not all. > Also in tiered mode AOT code contains profiling code similar to Tiered level 3 in current Tiered compilation. I think you mean level 2 (unless something changed since I left). > AOT code is immutable - have to do indirect klass loads and calls. > Also klass loading in AOT code is lazy - it has dynamic checks for class loading. > > In short - do not expect good peak performance from current AOT code. That is why we added --compile-for-tiered to re-JIT to get peak performance. > > We bet on compiled static initializers and skipping Interpreter for startup improvement. > > Vladimir > >> >> >> AOT could do stuff like tree shaking (static call graph >> minimization) or enforcement of strong encapsulation, but it doesn't >> yet. It's early days for this technology. >> >> >> ? John >> >> >> >> -- >> Sent from my phone From vladimir.kozlov at oracle.com Thu Oct 20 22:37:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Oct 2016 15:37:58 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <7079E2C8-2051-4F07-ABB6-997AA255F901@twitter.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> <7079E2C8-2051-4F07-ABB6-997AA255F901@twitter.com> Message-ID: On 10/20/16 12:04 PM, Christian Thalinger wrote: > >> On Oct 19, 2016, at 12:51 PM, Vladimir Kozlov >> > wrote: >> >> On 10/19/16 3:31 PM, Vitaly Davidovich wrote: >>> >>> >>> On Wednesday, October 19, 2016, John Rose >> >>> > wrote: >>> >>> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich >> >>> >> ');>> wrote: >>>> >>>> I think David must be talking about stripping the binary to just >>>> the set of methods known to be used - think of internal linkage, >>>> like static functions in C which may just get inlined and aren't >>>> present in the binary. So in Java AOT, closest parallel would be >>>> a private method but of course that's callable at runtime, so I >>>> don't see how AOT can just omit it entirely. >>> >>> AOT supports deoptimization and re-JIT-ing, so it would be easy to >>> omit methods from AOT output, and just use interpreter or JIT to >>> handle the execution. >>> >>> This would have to be opt-in, I'd imagine, as otherwise it would defeat >>> the purpose of AOT. Or it would have to very limited where it does this. >> >> re-JIT-ing (generating profiling code in AOT methods) is triggered by >> --compile-for-tiered flag. By default is off. >> But AOT code is following the same deoptimization rules as normal >> JITed code. For example, class unloading or redefinition. >> >>> >>> Separately, what optimizations (if any) will be done in AOT? Clearly >>> there's no profiling info, which is where the big gains typically come >>> from, but will anything be done? For example, are loops optimized >>> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees >>> inlined? Or is it basically C1 level of optimization (i.e. very minimal)? >> >> Currently it is C1 level only or even less - based on CHA without >> profiling information. We may add profiling information feedback in a >> future. >> No C2 type loop optimizations - Graal-core does some but not all. >> Also in tiered mode AOT code contains profiling code similar to Tiered >> level 3 in current Tiered compilation. > > I think you mean level 2 (unless something changed since I left). Yes, level 2. My mistake here. Vladimir > >> AOT code is immutable - have to do indirect klass loads and calls. >> Also klass loading in AOT code is lazy - it has dynamic checks for >> class loading. >> >> In short - do not expect good peak performance from current AOT code. >> That is why we added --compile-for-tiered to re-JIT to get peak >> performance. >> >> We bet on compiled static initializers and skipping Interpreter for >> startup improvement. >> >> Vladimir >> >>> >>> >>> AOT could do stuff like tree shaking (static call graph >>> minimization) or enforcement of strong encapsulation, but it doesn't >>> yet. It's early days for this technology. >>> >>> >>> ? John >>> >>> >>> >>> -- >>> Sent from my phone > From jonathan.gibbons at oracle.com Fri Oct 21 00:44:36 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 20 Oct 2016 17:44:36 -0700 Subject: CFV: New JDK 9 Committer: Andrey Nazarov Message-ID: <580964F4.6040106@oracle.com> |I hereby nominate Andrey Nazarov to JDK 9 Committer. Andrey is a member of the SQE team and has contributed a number of patches, mostly to the langtools/ repository, but also some to the jdk/ repository. He has contributed tests for the class file attributes generated by javac, and most recently, he has been contributing tests for Project Jigsaw, which have also been incorporated into JDK 9. See: http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 This query covers contributions to jigsaw/jake/langtools that have now been included in JDK 9 http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 Votes are due by the end of Nov 3, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. -- Jonathan Gibbons [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote| From dmitry.fazunenko at oracle.com Fri Oct 21 06:21:40 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 21 Oct 2016 09:21:40 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <5737f2f8-12a9-c524-8a7c-6da7db42e930@oracle.com> Vote: yes On 21.10.2016 3:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From daniel.fuchs at oracle.com Fri Oct 21 12:55:30 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 21 Oct 2016 13:55:30 +0100 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes On 21/10/16 01:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of patches, > mostly to the langtools/ repository, but also some to the jdk/ repository. > He has contributed tests for the class file attributes generated by javac, > and most recently, he has been contributing tests for Project Jigsaw, which > have also been incorporated into JDK 9. From jan.lahoda at oracle.com Fri Oct 21 13:00:52 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 21 Oct 2016 15:00:52 +0200 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <580A1184.8040808@oracle.com> Vote: yes On 21.10.2016 02:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of patches, > mostly to the langtools/ repository, but also some to the jdk/ repository. > He has contributed tests for the class file attributes generated by javac, > and most recently, he has been contributing tests for Project Jigsaw, which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From yuri.nesterenko at oracle.com Fri Oct 21 13:06:56 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 21 Oct 2016 16:06:56 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes -yan On 10/21/2016 03:44 AM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of patches, > mostly to the langtools/ repository, but also some to the jdk/ repository. > He has contributed tests for the class file attributes generated by javac, > and most recently, he has been contributing tests for Project Jigsaw, which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From aleksej.efimov at oracle.com Fri Oct 21 13:18:31 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 21 Oct 2016 16:18:31 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes On 21/10/16 03:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From vicente.romero at oracle.com Fri Oct 21 13:33:36 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 21 Oct 2016 09:33:36 -0400 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <0e152d9d-2318-03c4-74c9-d54d40ad8fa6@oracle.com> vote: yes Vicente On 10/20/2016 08:44 PM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From tatiana.pivovarova at oracle.com Fri Oct 21 13:40:06 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 21 Oct 2016 16:40:06 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes Tatiana On 10/21/2016 03:44 AM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From felix.yang at oracle.com Fri Oct 21 15:54:36 2016 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 21 Oct 2016 23:54:36 +0800 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: References: <580964F4.6040106@oracle.com> Message-ID: <380ADBB4-7163-427D-A96E-2BB7EDD6B42F@oracle.com> Vote?Yes -Felix > ? 2016?10?21??21:40?Tatiana Pivovarova ??? > > Vote: yes > > Tatiana > > >> On 10/21/2016 03:44 AM, Jonathan Gibbons wrote: >> |I hereby nominate Andrey Nazarov to JDK 9 Committer. >> >> Andrey is a member of the SQE team and has contributed a number of patches, >> mostly to the langtools/ repository, but also some to the jdk/ repository. >> He has contributed tests for the class file attributes generated by javac, >> and most recently, he has been contributing tests for Project Jigsaw, which >> have also been incorporated into JDK 9. >> >> See: >> http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 >> >> This query covers contributions to jigsaw/jake/langtools that have now been >> included in JDK 9 >> http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 >> >> >> Votes are due by the end of Nov 3, 2016. >> >> Only current JDK 9 Committers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> -- Jonathan Gibbons >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote| >> > From Roger.Riggs at Oracle.com Fri Oct 21 17:50:15 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 21 Oct 2016 13:50:15 -0400 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: Yes On 10/20/2016 8:44 PM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. From artem.smotrakov at oracle.com Fri Oct 21 17:55:44 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 21 Oct 2016 10:55:44 -0700 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <98a889ae-cea0-42d4-42c9-1e77077267e6@oracle.com> Vote: yes Artem On 10/20/2016 05:44 PM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From joe.darcy at oracle.com Fri Oct 21 23:50:35 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 21 Oct 2016 16:50:35 -0700 Subject: Looking ahead: proposed Hg forest consolidation for JDK 10 In-Reply-To: References: <9c8334c8-53eb-3070-9219-5232e23fb215@oracle.com> <2131d8f990c14b569c887bcfd4b8288d@DEWDFE13DE50.global.corp.sap> <1239553624.529887.1476288362388.JavaMail.zimbra@redhat.com> <21546930.537048.1476289543165.JavaMail.zimbra@redhat.com> <57FECF70.2090308@oracle.com> <5fb3cedd-8ec6-8bb6-9812-b40dc3ee4cfc@oracle.com> <2edb04e3-c0aa-9078-79f0-4e18b6c2841a@gmail.com> <20161017114140.GU19291@ehelin.jrpg.bea.com> Message-ID: Hi Thomas, On 10/18/2016 7:39 AM, Thomas St?fe wrote: > Hi all, > > On Mon, Oct 17, 2016 at 2:22 PM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > >> Hi, >> >> I'm on a 1.6 TB share available to our team visible on all our >> servers. The machine is a 48 processor 64GB linux x86_64 server. >> The servers only have limited local disc space. Especially with the >> new setup I can not have clones on all the machines I need to compile >> and test on. >> >> Best regards, >> Goetz. >> >> > I'm on Goetz team at SAP. Just wanted to give some additional information: > > I keep reading "use local repos". This is unfortunately not practical for > us. Limited local disk space on build machines is only the smallest of the > problems. A bigger problem is our platform breadth. > > We have a large zoo of machines running a number of cpu/os combinations. > When we develop for the OpenJDK, we want to build and test on multiple - > preferably all - machines and platforms the OpenJDK is supported on, to > make sure we do not introduce regressions. But we have no automatic build > system for these platforms, nor do we have access to your jprt. Independent of what happens with this proposal, I suggest setting up some kind of in-house build and test system to help automate such procedures. Internally at Oracle, we have various Hudson/Jenkins systems in addition to jprt. > So, as an example the fix for JDK-8166944 I did build on Linux (x64, ppc, > s390), Solaris (sparc, x64), AIX, MacOS, and Windows x64. I usually leave > out platforms I think are safe - in this case 32bit and zero - but at my > own risk, because if I introduce a regression because I do not build, I > risk the annoyance of other developers. > > Therefore local repos are not practical - syncing local repos across many > machines is a pain and very error prone. So, every developer keeps his > repos on a filer (NFS) and so if the NFS client on a certain machine is not > good, we wait and suffer. > > So performance matters for us a lot. > > [snip] Using a particular set of Hg source repositories is not a guaranteed interface of the JDK and as a historical note there was some discontent with consequences of using more than one repository when the Hg repos were first published: http://mail.openjdk.java.net/pipermail/discuss/2007-December/000505.html We on the consolidation team are willing to continue exploring options to better accommodate differing workflows and system architectures. I think it is reasonable for some changes to those systems to be included in the space of candidate solutions. Regards, -Joe From vladimir.x.ivanov at oracle.com Mon Oct 24 13:26:17 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Oct 2016 16:26:17 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 10/21/16 3:44 AM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. From vladimir.x.ivanov at oracle.com Mon Oct 24 13:26:38 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Oct 2016 16:26:38 +0300 Subject: CFV: New JDK 9 Reviewer: Artem Smotrakov In-Reply-To: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> References: <9073a055-460d-15a4-b589-94b50e78f6c7@oracle.com> Message-ID: <6816adcb-5393-942c-dea2-6f215b437085@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 10/11/16 9:20 PM, Sean Mullan wrote: > I hereby nominate Artem Smotrakov (asmotrak) to JDK 9 Reviewer. From dmitry.dmitriev at oracle.com Mon Oct 24 13:36:35 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 24 Oct 2016 16:36:35 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <4124e0ad-8c57-5c4f-5473-6311210a69cf@oracle.com> Vote: yes Dmitry On 21.10.2016 3:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From serguei.spitsyn at oracle.com Tue Oct 25 00:32:23 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 24 Oct 2016 17:32:23 -0700 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <99983dfa-4621-4e71-ea5b-466655b3cb4a@oracle.com> Vote: yes From maurizio.cimadamore at oracle.com Tue Oct 25 08:27:59 2016 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 25 Oct 2016 09:27:59 +0100 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: Vote: yes Maurizio On 21/10/16 01:44, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From alejandro.murillo at oracle.com Tue Oct 25 22:06:31 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Tue, 25 Oct 2016 16:06:31 -0600 Subject: jdk9-dev: HotSpot Message-ID: <32a04319-b0ee-1525-7f4d-b40ea5fb2718@oracle.com> jdk9-hs-2016-10-18 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/530dbcad379e http://hg.openjdk.java.net/jdk9/dev/corba/rev/408c9c621938 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/6772dde13bed http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/bdafa0cc34a9 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/59101416d901 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6ba0cc0314d0 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/32444e1ad88a http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/d3f5d7311a1a Component : VM Status : Go for integration Date : 10/25/2016 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-10-20-235504.amurillo.jdk9-hs-2016-10-18-snapshot Testing: 71 new failures, 6632 known failures, 1351796 passed. Issues and Notes: No stoppers have been detected. Go for integration CRs for testing: 8081800: AbstractMethodError when evaluating a private method in an interface via debugger 8134389: Crash in HotSpot with jvm.dll+0x42b48 ciObjectFactory::create_new_metadata 8153134: Infinite loop in handle_wrong_method in jmod 8155729: C2: Skip transformation of LoadConP for heap-based compressed oops 8155948: Add message for CMS deprecation for Oracle builds 8157141: Fix for JDK-8031290 is unnecessarily fragile 8157708: aarch64: StrIndexOfChar intrinsic is not implemented 8158797: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails when GC is specified explicitly 8159799: Tests using jcmd fails intermittently with Could not open PerfMemory on Windows 8160064: StackWalker implementation added logging option without using UL 8164120: The minimal VM should be stripped using --strip-unneeded 8164921: Memory leaked when instrumentation.retransformClasses() is called repeatedly 8165482: java in ldoms, with cpu-arch=generic has problems 8165526: Kitchensink sudden death - error code 0x406d1388 8165600: Convert internal logging tests to GTest 8165621: Convert TestG1BiasedArray_test to GTest 8165673: AArch64: Fix JNI floating point argument handling 8165687: Fix license and copyright headers in jd9 under hotspot/test 8165696: Convert gcTraceTime internal tests to GTest 8165698: Convert LogTagSet related internal tests to GTest 8165700: Convert LogMessage internal tests to GTest 8165702: Convert LogFileOutput internal tests to GTest 8165704: Convert LogStream internal tests to GTest 8165827: Support private interface methods in JNI, JDWP, JDI and JDB 8165949: Serial and ConcMarkSweep do not unload strings when class unloading is disabled 8166129: hitting vmassert during gtest execution doesn't generate core and hs_err files 8166197: assert(RelaxAssert || w != Thread::current()->_MutexEvent) failed: invariant 8166276: Refactor gen_process_roots to allow simpler fix for 8165949 8166364: fatal error: acquiring lock DirtyCardQ_CBL_mon/16 out of order with lock Module_lock/6 -- possible deadlock 8166454: meminfo(2) has been available since Solaris 9 8166461: Deprecate UseAutoGCSelectPolicy 8166462: Convert TestResourcehash_test to Gtest 8166517: [JVMCI] export JVMCI to auto-detected JVMCI compiler 8166562: C2: Suppress relocations in scratch emit. 8166657: Remove exports com.sun.tools.jdi to jdk.hotspot.agent 8166689: PPC64: Race condition between stack bang and non-entrant patching 8166738: Enable concurrency in Hotspot jtreg testing 8166742: SIGFPE in C2 Loop IV elimination 8166781: fix wrong comment in ReceiverTypeData 8166800: [s390] Top-level build changes required for Linux/s390x 8166801: [s390] Add jvm.cfg file for Linux/s390x 8166836: Elimination of clone's ArrayCopyNode may make compilation fail silently 8166869: [JVMCI] record metadata relocations for metadata references 8166925: several native TESTs should be changed to TEST_VM 8166929: [JVMCI] Expose decompile counts in MDO 8166930: minor cleanups 1) remove reference to ZIP_ReadMappedEntry 2) checking of st_mode 8166931: Do not include classes which are unusable during run time in the classlist file 8166970: Adapt mutex padding according to DEFAULT_CACHE_LINE_SIZE 8166972: [JVMCI] reduce size of interpreter when JVMCI is enabled 8167001: [TESTBUG] java/lang/instrument/DaemonThread/TestDaemonThread.java fails when run by jprt 8167034: Re-enable TestDaemonThread.java once JDK-8167001 is fixed 8167180: [JVMCI] Exported elements referring to inaccessible types in jdk.vm.ci 8167190: Remove confusing timestamps from the gc log 8167194: [JVMCI] no reliable mechanism for querying JVMCI system properties 8167200: AArch64: Broken stack pointer adjustment in interpreter 8167333: Invalid source path info might be used when creating ClassFileStream after CFLH transforms a shared classes in some cases 8167353: [JVMCI] JVMCI re-initialization check is in the wrong location 8167494: Deprecate AutoGCSelectPauseMillis 8167595: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt 8168086: 8166869 broke jvmci build on aarch64 -- Alejandro From sean.mullan at oracle.com Wed Oct 26 14:29:18 2016 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Oct 2016 10:29:18 -0400 Subject: Result: New JDK 9 Reviewer: Artem Smotrakov Message-ID: Voting for Artem Smotrakov [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/004991.html From pavel.punegov at oracle.com Wed Oct 26 14:32:06 2016 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 26 Oct 2016 17:32:06 +0300 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <1F9F07B7-6D8B-4FCB-9962-BCE40DABF8B0@oracle.com> Vote: yes > On 21 Oct 2016, at 03:44, Jonathan Gibbons wrote: > > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of patches, > mostly to the langtools/ repository, but also some to the jdk/ repository. > He has contributed tests for the class file attributes generated by javac, > and most recently, he has been contributing tests for Project Jigsaw, which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From vladimir.kozlov at oracle.com Wed Oct 26 17:45:09 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Oct 2016 10:45:09 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> Message-ID: <5810EBA5.3030905@oracle.com> I added some clarification to JEP description to avoid possible misunderstanding. AOT code is NOT linked during AOT libraries load as it happens with normal .so libraries. AOT code entry points are not exposed (not global) in AOT libraries. Only class data has global labels which we look for with dlsym(klass_name). AOT-compiled code in AOT libraries is treated by JVM as *extension* of existing CodeCache. When a java class is loaded JVM looks if corresponding AOT-compiled methods exist in loaded AOT libraries and add links to them from java methods descriptors (we have new field Method::_aot_code). AOT-compiled code follows the same invocation/deoptimization/unloading rules as normal JIT-compiled code. Calls in AOT code use the same methods resolution runtime code as calls in JITed code. The difference is call's destination address is loaded indirectly because we can't patch AOT code - it is immutable (to share between multiple JVM instances). Regards, Vladimir On 10/19/16 3:51 PM, Vladimir Kozlov wrote: > On 10/19/16 3:31 PM, Vitaly Davidovich wrote: >> >> >> On Wednesday, October 19, 2016, John Rose > > wrote: >> >> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich > > wrote: >>> >>> I think David must be talking about stripping the binary to just >>> the set of methods known to be used - think of internal linkage, >>> like static functions in C which may just get inlined and aren't >>> present in the binary. So in Java AOT, closest parallel would be >>> a private method but of course that's callable at runtime, so I >>> don't see how AOT can just omit it entirely. >> >> AOT supports deoptimization and re-JIT-ing, so it would be easy to >> omit methods from AOT output, and just use interpreter or JIT to >> handle the execution. >> >> This would have to be opt-in, I'd imagine, as otherwise it would defeat >> the purpose of AOT. Or it would have to very limited where it does this. > > re-JIT-ing (generating profiling code in AOT methods) is triggered by --compile-for-tiered flag. By default is off. > But AOT code is following the same deoptimization rules as normal JITed code. For example, class unloading or redefinition. > >> >> Separately, what optimizations (if any) will be done in AOT? Clearly >> there's no profiling info, which is where the big gains typically come >> from, but will anything be done? For example, are loops optimized >> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees >> inlined? Or is it basically C1 level of optimization (i.e. very minimal)? > > Currently it is C1 level only or even less - based on CHA without profiling information. We may add profiling information feedback in a future. > No C2 type loop optimizations - Graal-core does some but not all. > Also in tiered mode AOT code contains profiling code similar to Tiered level 3 in current Tiered compilation. > AOT code is immutable - have to do indirect klass loads and calls. > Also klass loading in AOT code is lazy - it has dynamic checks for class loading. > > In short - do not expect good peak performance from current AOT code. That is why we added --compile-for-tiered to re-JIT to get peak performance. > > We bet on compiled static initializers and skipping Interpreter for startup improvement. > > Vladimir > >> >> >> AOT could do stuff like tree shaking (static call graph >> minimization) or enforcement of strong encapsulation, but it doesn't >> yet. It's early days for this technology. >> >> >> ? John >> >> >> >> -- >> Sent from my phone From christian.tornqvist at oracle.com Wed Oct 26 19:37:29 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 26 Oct 2016 15:37:29 -0400 Subject: Result: New JDK 9 Committer: Mikhailo Seledtsov Message-ID: <240a01d22fc0$63d8e1f0$2b8aa5d0$@oracle.com> Voting for Mikhailo Seledtsov [1] is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks, Christian [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005017.html From lana.steuck at oracle.com Wed Oct 26 20:19:24 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 26 Oct 2016 20:19:24 GMT Subject: jdk9-b142: dev Message-ID: <201610262019.u9QKJOaJ020046@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/2b3e5caafe35 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/d3f5d7311a1a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d245e56f4a79 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6ce43dd8e954 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/59101416d901 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/bdafa0cc34a9 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7b48d63dfd6b http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/408c9c621938 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-6378384 core-libs (reflect) subclass can???t access superclass???s protected fields and JDK-8071588 core-libs The spec for javax.script.ScriptEngineFactory.getProgram() should spec JDK-8071678 core-libs javax.script.ScriptContext setAttribute method should clarify behavior JDK-8146257 core-libs sun/net/www/protocol/jar/B4957695.java fails intermittently with java. JDK-8146750 core-libs java.time.Month.getDisplayName() return incorrct narrow names with JRE JDK-8152617 core-libs add missing wildcards to Optional or() and flatMap() JDK-8152926 core-libs PropertyResourceBundle constructor don't understand the System.setProp JDK-8157965 core-libs update httpserver logging to use java.lang.System.Logger JDK-8163330 core-libs HijrahDate aligned day of week incorrect JDK-8164708 core-libs String.prototype.replace replaces empty match twice JDK-8167192 core-libs [Testbug] java/io/Serializable/serialFilter test conditions wrong JDK-8167437 core-libs Fix module dependencies for tests that use internal API JDK-8168073 core-libs Speed up URI creation during module bootstrap JDK-8168096 core-libs markup error in "since" element spec of @Deprecated JDK-8168140 core-libs TypedArrays should implement ES6 iterator protocol JDK-8168146 core-libs Infinite recursion in Uint8ClampedArray.set JDK-8168405 core-libs Pending exceptions in java.base/windows/native/libnet JDK-8168417 core-libs Pending exceptions in java.base/windows/native/libnio JDK-8168471 core-libs Non ANSI C declaration of block local variable in NetworkInterface_win JDK-8165271 deploy Fix use of reflection to gain access to private fields JDK-8163984 hotspot Fix license and copyright headers under /test/lib/sun/hotspot/ for whi JDK-8168409 hotspot Update list of tools run by the jtreg timeouthandler JDK-8167600 infrastructure jib make run-test for langtools and intermittent failures on windows-x JDK-8168302 infrastructure --disable-warnings-as-errors doesn't work for the hotspot build on Sol JDK-8164908 other-libs ReflectionFactory support for IIOP and custom serialization JDK-8168614 other-libs Disable CORBA com.sun.corba.serialization.ObjectStreamTest.echoObjects JDK-8163304 security-libs jarsigner -verbose -verify should print the algorithms used to sign th JDK-8165274 security-libs SHA1 certpath constraint check fails with OCSP certificate JDK-8165463 security-libs Native implementation of sunmscapi should use operator new (nothrow) f JDK-8166530 security-libs sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails interm JDK-8167591 security-libs Add MD5 to signed JAR restrictions JDK-8167647 security-libs Copy-and-paste bug in javax.security.auth.kerberos.KerberosTicket.toSt JDK-8168078 security-libs Remove permission to read all system properties granted to the jdk.cry JDK-8168313 security-libs Tighten permissions granted to jdk.crypto.pkcs11 module JDK-8168374 security-libs TsacertOptionTest.java fails on all platforms JDK-8145471 tools javac changes for enhanced deprecation JDK-8163840 tools jshell tool: provide way to display configuration settings JDK-8166183 tools jshell tool: on return from Ctrl-Z, garbage on screen, dies with Ctrl- JDK-8167383 tools Javadoc does not handle packages correctly when used with module optio JDK-8167461 tools jshell tool: Scanner#next() hangs tool JDK-8167558 tools Add new JMOD section for header files and man pages JDK-8167637 tools jshell tool: /edit should use EDITOR setting JDK-8167640 tools jshell tool: external editor temp file should be *.java JDK-8168091 tools jlink should check security permission early when programmatic access JDK-8168093 tools Need a way for the launcher to query the JRE location using Windows re JDK-8168343 tools 3 javac tests fail when run on an exploded image JDK-8168368 tools Add missing bug id for JDK-8167383 JDK-8168480 tools Speculative attribution of lambda causes NPE in Flow JDK-8168499 tools Workaround intermittent failures of IntersectionTargetTypeTest.java JDK-8167179 xml Make XSL generated namespace prefixes local to transformation process From mark.reinhold at oracle.com Wed Oct 26 23:15:53 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 Oct 2016 16:15:53 -0700 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <20161019101449.402617700eggemoggin.niobe.net> References: <20161019101449.402617700eggemoggin.niobe.net> Message-ID: <20161026161553.996637970eggemoggin.niobe.net> 2016/10/19 10:14:49 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" > state by their owners after discussion and review: > > 294: Linux/s390x Port > http://openjdk.java.net/jeps/294 > > 295: Ahead-of-Time Compilation > http://openjdk.java.net/jeps/295 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 18:00 UTC next > Wednesday, 26 October, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > these JEPs to JDK 9. Hearing no objections, I've targeted these JEPs to JDK 9. - Mark From mark.reinhold at oracle.com Wed Oct 26 23:23:58 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 Oct 2016 16:23:58 -0700 Subject: JDK 9 release schedule In-Reply-To: <20161018075625.243636391eggemoggin.niobe.net> References: <20160913155640.71291CD3B6@eggemoggin.niobe.net> <20161018075625.243636391eggemoggin.niobe.net> Message-ID: <20161026162358.54110665eggemoggin.niobe.net> 2016/10/18 7:56:25 -0700, mark.reinhold at oracle.com: > ... > > Here are the proposed dates for the interim milestones: > > 2016/05/26 Feature Complete > 2016/12/22 Feature Extension Complete > 2017/01/05 Rampdown Start > 2017/02/09 All Tests Run > 2017/02/16 Zero Bug Bounce > 2017/03/16 Rampdown Phase 2 > 2017/07/06 Final Release Candidate > 2017/07/27 General Availability > > The milestone definitions are as before except for "Feature Extension > Complete", which is the date by which JEPs and small enhancements that > have been granted extensions via the existing process [1] must be > integrated into the master forest. > > I didn't include the interim milestones in the initial proposal, so I'll > leave them open for discussion under the same terms until 15:00 UTC next > Tuesday, 25 October. Hearing no objections, I've posted this on the Project page [1] as the new milestone schedule for JDK 9. - Mark [1] http://openjdk.java.net/projects/jdk9/ From vitalyd at gmail.com Wed Oct 26 23:24:01 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 26 Oct 2016 19:24:01 -0400 Subject: JEPs proposed to target JDK 9 (2016/10/19) In-Reply-To: <5810EBA5.3030905@oracle.com> References: <81c92123-f480-d148-139a-26a7576c7cf6@redhat.com> <8053347f-88fd-774d-3c3a-84fb657cf4e5@oracle.com> <17f51b06-8ced-e2f9-6790-9b53c3c7d90f@oracle.com> <5810EBA5.3030905@oracle.com> Message-ID: Thanks Vladimir, those are helpful clarifications. On Wednesday, October 26, 2016, Vladimir Kozlov wrote: > I added some clarification to JEP description to avoid possible > misunderstanding. > > AOT code is NOT linked during AOT libraries load as it happens with normal > .so libraries. AOT code entry points are not exposed (not global) in AOT > libraries. Only class data has global labels which we look for with > dlsym(klass_name). > > AOT-compiled code in AOT libraries is treated by JVM as *extension* of > existing CodeCache. When a java class is loaded JVM looks if corresponding > AOT-compiled methods exist in loaded AOT libraries and add links to them > from java methods descriptors (we have new field Method::_aot_code). > AOT-compiled code follows the same invocation/deoptimization/unloading > rules as normal JIT-compiled code. > > Calls in AOT code use the same methods resolution runtime code as calls in > JITed code. The difference is call's destination address is loaded > indirectly because we can't patch AOT code - it is immutable (to share > between multiple JVM instances). > > Regards, > Vladimir > > On 10/19/16 3:51 PM, Vladimir Kozlov wrote: > >> On 10/19/16 3:31 PM, Vitaly Davidovich wrote: >> >>> >>> >>> On Wednesday, October 19, 2016, John Rose >> > wrote: >>> >>> On Oct 19, 2016, at 3:11 PM, Vitaly Davidovich >> > wrote: >>> >>>> >>>> I think David must be talking about stripping the binary to just >>>> the set of methods known to be used - think of internal linkage, >>>> like static functions in C which may just get inlined and aren't >>>> present in the binary. So in Java AOT, closest parallel would be >>>> a private method but of course that's callable at runtime, so I >>>> don't see how AOT can just omit it entirely. >>>> >>> >>> AOT supports deoptimization and re-JIT-ing, so it would be easy to >>> omit methods from AOT output, and just use interpreter or JIT to >>> handle the execution. >>> >>> This would have to be opt-in, I'd imagine, as otherwise it would defeat >>> the purpose of AOT. Or it would have to very limited where it does this. >>> >> >> re-JIT-ing (generating profiling code in AOT methods) is triggered by >> --compile-for-tiered flag. By default is off. >> But AOT code is following the same deoptimization rules as normal JITed >> code. For example, class unloading or redefinition. >> >> >>> Separately, what optimizations (if any) will be done in AOT? Clearly >>> there's no profiling info, which is where the big gains typically come >>> from, but will anything be done? For example, are loops optimized >>> (unrolled, unswitched, etc)? Are statically known (at AOT time) callees >>> inlined? Or is it basically C1 level of optimization (i.e. very minimal)? >>> >> >> Currently it is C1 level only or even less - based on CHA without >> profiling information. We may add profiling information feedback in a >> future. >> No C2 type loop optimizations - Graal-core does some but not all. >> Also in tiered mode AOT code contains profiling code similar to Tiered >> level 3 in current Tiered compilation. >> AOT code is immutable - have to do indirect klass loads and calls. >> Also klass loading in AOT code is lazy - it has dynamic checks for class >> loading. >> >> In short - do not expect good peak performance from current AOT code. >> That is why we added --compile-for-tiered to re-JIT to get peak performance. >> >> We bet on compiled static initializers and skipping Interpreter for >> startup improvement. >> >> Vladimir >> >> >>> >>> AOT could do stuff like tree shaking (static call graph >>> minimization) or enforcement of strong encapsulation, but it doesn't >>> yet. It's early days for this technology. >>> >>> >>> ? John >>> >>> >>> >>> -- >>> Sent from my phone >>> >> -- Sent from my phone From kumar.x.srinivasan at oracle.com Fri Oct 28 13:43:23 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 28 Oct 2016 06:43:23 -0700 Subject: CFV: New JDK 9 Committer: Andrey Nazarov In-Reply-To: <580964F4.6040106@oracle.com> References: <580964F4.6040106@oracle.com> Message-ID: <581355FB.6010604@oracle.com> Vote: yes On 10/20/2016 5:44 PM, Jonathan Gibbons wrote: > |I hereby nominate Andrey Nazarov to JDK 9 Committer. > > Andrey is a member of the SQE team and has contributed a number of > patches, > mostly to the langtools/ repository, but also some to the jdk/ > repository. > He has contributed tests for the class file attributes generated by > javac, > and most recently, he has been contributing tests for Project Jigsaw, > which > have also been incorporated into JDK 9. > > See: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/log?rev=user%28anazarov%29 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=user%28anazarov%29 > > This query covers contributions to jigsaw/jake/langtools that have now > been > included in JDK 9 > http://hg.openjdk.java.net/jigsaw/jake/langtools/log?rev=user%28anazarov%29+and+date%28%222015-8-1+to++2016-1-1%22%29 > > > > Votes are due by the end of Nov 3, 2016. > > Only current JDK 9 Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- Jonathan Gibbons > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote| > From daniel.stewart at linaro.org Fri Oct 28 14:35:43 2016 From: daniel.stewart at linaro.org (Daniel Stewart) Date: Fri, 28 Oct 2016 10:35:43 -0400 Subject: [New Bug] [aarch64] [hotspot] src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Message-ID: I'm new to OpenJDK and not sure where to send this, so I thought I'd start with this list. There is a bug that occurred 3 days ago in the jdk9/dev branch in src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp. I am doing nightly aarch64 builds of jdk9/dev branch and started seeing it 3 days ago. This bug does not appear in the jdk9/hs branch. The actual changeset that appears to have caused the issue is 12188. I've included a simple fix below, as this is simply a matter of a missing #endif. Thanks and my apologies if this is the wrong mailing list. Daniel Stewart -- diff -r c30b6e2d2ec4 src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Thu Oct 27 21:22:32 2016 +0000 +++ b/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Fri Oct 28 14:33:28 2016 +0000 @@ -476,6 +476,7 @@ } #endif } +#endif // handle exceptions { Label L; From david.holmes at oracle.com Sat Oct 29 15:31:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 30 Oct 2016 01:31:09 +1000 Subject: [New Bug] [aarch64] [hotspot] src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp In-Reply-To: References: Message-ID: Hi Daniel, On 29/10/2016 12:35 AM, Daniel Stewart wrote: > I'm new to OpenJDK and not sure where to send this, so I thought I'd start > with this list. Hotspot issues should go to hotspot-dev (cc'd for reference), or if you know the sub-area to hotspot-runtime-dev, or hotspot-compiler-dev etc. > There is a bug that occurred 3 days ago in the jdk9/dev branch > in src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp. I am doing > nightly aarch64 builds of jdk9/dev branch and started seeing it 3 days ago. > This bug does not appear in the jdk9/hs branch. > > The actual changeset that appears to have caused the issue is 12188. I've > included a simple fix below, as this is simply a matter of a missing > #endif. This is already fixed in the jdk9/hs repo. It is unfortunate that the breakage was allowed to escape. The fix should appear in jdk9/dev early this week. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/95c6654fa2ee Cheers, David > Thanks and my apologies if this is the wrong mailing list. > > Daniel Stewart > > -- > > diff -r c30b6e2d2ec4 > src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp > --- a/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Thu > Oct 27 21:22:32 2016 +0000 > +++ b/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp Fri > Oct 28 14:33:28 2016 +0000 > @@ -476,6 +476,7 @@ > } > #endif > } > +#endif > // handle exceptions > { > Label L; > From aph at redhat.com Sun Oct 30 08:37:51 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 30 Oct 2016 08:37:51 +0000 Subject: [New Bug] [aarch64] [hotspot] src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp In-Reply-To: References: Message-ID: <8a0368c1-dfb7-f800-3174-d82418dd5235@redhat.com> On 28/10/16 15:35, Daniel Stewart wrote: > There is a bug that occurred 3 days ago in the jdk9/dev branch > in src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp. I am doing > nightly aarch64 builds of jdk9/dev branch and started seeing it 3 days ago. > This bug does not appear in the jdk9/hs branch. It'll get merged: you just have to wait. You should test the jdk9/hs branch. Andrew. From masayoshi.okutsu at oracle.com Sun Oct 30 11:20:53 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sun, 30 Oct 2016 20:20:53 +0900 Subject: CFV: New JDK9 Committer: Nishit Jain In-Reply-To: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> References: <304d20e1-d8af-5add-6b2c-62527ed52a9f@oracle.com> Message-ID: Vote: Yes On 10/18/2016 6:35 PM, Masayoshi Okutsu wrote: > I hereby nominate Nishit Jain to JDK 9 Committer. > > Nishit is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. > He has made 18 contributions to JDK 9 [3]. > > Votes are due by Oct 31, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Masayoshi > > [1]http://openjdk.java.net/census > [2]http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22nishit.jain%40oracle.com%22)+or+author(nishjain)) >