From qingfeng.yy at alibaba-inc.com Mon Feb 1 02:36:54 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Mon, 01 Feb 2021 10:36:54 +0800 Subject: =?UTF-8?B?UElORzogUkZSOiA4dSBiYWNrcG9ydCBvZiBKREstODIzNzQ5OSBKRlI6IEluY2x1ZGUgc3Rh?= =?UTF-8?B?Y2sgdHJhY2UgaW4gdGhlIFRocmVhZFN0YXJ0IGV2ZW50?= In-Reply-To: References: Message-ID: Can anyone help review this patch :-O Thanks, Yang Yi ------------------Original Mail ------------------ Sender:Yang Yi Send Date:Fri Jan 22 14:39:20 2021 Recipients:jdk8u-dev at openjdk.java.net Subject:RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Hi, May I have a request backport of JDK-8237499? JBS: https://bugs.openjdk.java.net/browse/JDK-8237499 Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8237499/ testing: jdk/test/jdk/jfr/ It's useful for users to know where their threads start. This patch doesn't apply cleanly but is fairly trivial. The latest jdk8u-dev has no `Thread::current_or_null` function, just adding this function solves the problem. This patch will cause another problem, e.g., the minimized VM fails to build, this problem has been solved by JDK-8239886, so a follow-up backport of JDK-8239886(one-line change) will be sent later. Cheers, Yang Yi From gnu.andrew at redhat.com Tue Feb 2 05:30:30 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 2 Feb 2021 05:30:30 +0000 Subject: OpenJDK 8u292-b01 EA Released Message-ID: <20210202053030.GA119497@rincewind> I've made available an early access source bundle for 8u292, based on the tag jdk8u292-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b01-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b01-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint =3D CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 6596abe470788329298fca06b95394e25b88ae14682b2ac47b5ed57971168cbd openjdk8u292-b01-ea.tar.xz 7d5dbec23b9997ff10120a309023ff3dcbb745d0c26e3bf1cc6ef12c3336e9e7 openjdk8u292-b01-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b01-ea.sha256 Changes in 8u292-b01: - JDK-7009641: Don't fail VM when CodeCache is full - JDK-8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently - JDK-8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error - JDK-8073108: [AArch64] Use x86 and SPARC CPU instructions for GHASH acceleration - JDK-8130309: Need to bailout cleanly if creation of stubs fails when codecache is out of space (AArch64 changes) - JDK-8131779: AARCH64: add Montgomery multiply intrinsic - JDK-8132875: AArch64: Fix error introduced into AArch64 CodeCache by commit for 8130309 - JDK-8135018: AARCH64: Missing memory barriers for CMS collector - JDK-8145320: Create unsafe_arraycopy and generic_arraycopy for AArch64 - JDK-8148328: aarch64: redundant lsr instructions in stub code. - JDK-8148783: aarch64: SEGV running SpecJBB2013 - JDK-8148948: aarch64: generate_copy_longs calls align() incorrectly - JDK-8149080: AArch64: Recognise disjoint array copy in stub code - JDK-8149365: aarch64: memory copy does not prefetch on backwards copy - JDK-8149907: aarch64: use load/store pair instructions in call_stub - JDK-8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero - JDK-8150045: arraycopy causes segfaults in SATB during garbage collection - JDK-8150082: aarch64: optimise small array copy - JDK-8150229: aarch64: pipeline class for several instructions is not set correctly - JDK-8150313: aarch64: optimise array copy using SIMD instructions - JDK-8150394: aarch64: add support for 8.1 LSE CAS instructions - JDK-8150652: Remove unused code in AArch64 back end - JDK-8151340: aarch64: prefetch the destination word for write prior to ldxr/stxr loops. - JDK-8151502: optimize pd_disjoint_words and pd_conjoint_words - JDK-8151775: aarch64: add support for 8.1 LSE atomic operations - JDK-8152537: aarch64: Make use of CBZ and CBNZ when comparing unsigned values with zero. - JDK-8152840: aarch64: improve _unsafe_arraycopy stub routine - JDK-8153172: aarch64: hotspot crashes after the 8.1 LSE patch is merged - JDK-8153713: aarch64: improve short array clearing using store pair - JDK-8153797: aarch64: Add Arrays.fill stub code - JDK-8154413: AArch64: Better byte behaviour - JDK-8154537: AArch64: some integer rotate instructions are never emitted - JDK-8154739: AArch64: TemplateTable::fast_xaccess loads in wrong mode - JDK-8155015: Aarch64: bad assert in spill generation code - JDK-8155100: AArch64: Relax alignment requirement for byte_map_base - JDK-8155612: Aarch64: vector nodes need to support misaligned offset - JDK-8155617: aarch64: ClearArray does not use DC ZVA - JDK-8155627: Enable SA on AArch64 - JDK-8155653: TestVectorUnalignedOffset.java not pushed with 8155612 - JDK-8156731: aarch64: java/util/Arrays/Correct.java fails due to _generic_arraycopy stub routine - JDK-8157841: aarch64: prefetch ignores cache line size - JDK-8157906: aarch64: some more integer rotate instructions are never emitted - JDK-8158913: aarch64: SEGV running Spark terasort - JDK-8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words - JDK-8159063: aarch64: optimise unaligned array copy long - JDK-8160748: [AArch64] Inconsistent types for ideal_reg - JDK-8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure - JDK-8161190: AArch64: Fix overflow in immediate cmp instruction - JDK-8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted - JDK-8164113: AArch64: follow-up the fix for 8161598 - JDK-8165673: AArch64: Fix JNI floating point argument handling - JDK-8167200: AArch64: Broken stack pointer adjustment in interpreter - JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods - JDK-8167421: AArch64: in one core system, fatal error: Illegal threadstate encountered - JDK-8167595: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt - JDK-8168699: Validate special case invocations [AArch64 support] - JDK-8168888: Port 8160591: Improve internal array handling to AArch64. - JDK-8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node - JDK-8170100: AArch64: Crash in C1-compiled code accessing References - JDK-8170188: jtreg test compiler/types/TestMeetIncompatibleInterfaceArrays.java causes JVM crash - JDK-8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation - JDK-8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 - JDK-8172881: AArch64: assertion failure: the int pressure is incorrect - JDK-8173472: AArch64: C1 comparisons with null only use 32-bit instructions - JDK-8176100: [AArch64] [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles - JDK-8177661: Correct ad rule output register types from iRegX to iRegXNoSp - JDK-8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent - JDK-8182581: aarch64: fix for crash caused by earlyret of compiled method - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" - JDK-8186090: java.nio.Bits.unaligned() doesn't handle aarch64 - JDK-8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV - JDK-8187224: aarch64: some inconsistency between aarch64_ad.m4 and aarch64.ad - JDK-8189170: [AArch64] Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM - JDK-8193133: Assertion failure because 0xDEADDEAD can be in-heap - JDK-8195685: AArch64 port of 8174962: Better interface invocations - JDK-8195859: AArch64: vtableStubs gtest fails after 8174962 - JDK-8196136: AArch64: Correct register use in patch for JDK-8194686 - JDK-8196221: AArch64: Mistake in committed patch for JDK-8195859 - JDK-8199712: [AArch64] Flight Recorder - JDK-8202343: Disable TLS 1.0 and 1.1 - JDK-8203481: Incorrect constraint for unextended_sp in frame:safe_for_sender - JDK-8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 - JDK-8205421: AARCH64: StubCodeMark should be placed after alignment - JDK-8206163: AArch64: incorrect code generation for StoreCM - JDK-8207345: Trampoline generation code reads from uninitialized memory - JDK-8207838: AArch64: Float registers incorrectly restored in JNI call - JDK-8209413: AArch64: NPE in clhsdb jstack command - JDK-8209414: [AArch64] method handle invocation does not respect JVMTI interp_only mode - JDK-8209415: Fix JVMTI test failure HS202 - JDK-8209420: Track membars for volatile accesses so they can be properly optimized - JDK-8209835: Aarch64: elide barriers on all volatile operations - JDK-8210425: [AArch64] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization - JDK-8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls - JDK-8211233: MemBarNode::trailing_membar() and MemBarNode::leading_membar() need to handle dying subgraphs better - JDK-8211339: NPE during SSL handshake caused by HostnameChecker - JDK-8213134: AArch64: vector shift failed with MaxVectorSize=8 - JDK-8213419: [AArch64] C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - JDK-8214857: "bad trailing membar" assert failure at memnode.cpp:3220 - JDK-8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 - JDK-8216350: AArch64: monitor unlock fast path not called - JDK-8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy - JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 - JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered - JDK-8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static - JDK-8219011: Implement MacroAssembler::warn method on AArch64 - JDK-8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield - JDK-8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable - JDK-8221658: aarch64: add necessary predicate for ubfx patterns - JDK-8223186: HotSpot compile warnings from GCC 9 - JDK-8224671: AArch64: mauve System.arraycopy test failure - JDK-8224828: aarch64: rflags is not correct after safepoint poll - JDK-8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 - JDK-8224880: AArch64: java/javac error with AllocatePrefetchDistance - JDK-8228400: Remove built-in AArch64 simulator - JDK-8228406: Superfluous change in chaitin.hpp - JDK-8228593: Revert explicit JDK 7 support additions - JDK-8228716: Revert InstanceKlass::print_on debug additions - JDK-8228718: Revert incorrect backport of JDK-8129757 to 8-aarch64 - JDK-8228725: AArch64: Purge method call format support - JDK-8228747: Revert "unused" attribute from test_arraycopy_func - JDK-8228767: Revert ResourceMark additions - JDK-8228770: Revert development hsdis changes - JDK-8229123: Revert build fixes for aarch64/zero - JDK-8229124: Revert disassembler.cpp changes - JDK-8229145: Revert TemplateTable::bytecode() visibility change - JDK-8229284: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage - JDK-8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR - JDK-8233839: aarch64: missing memory barrier in NewObjectArrayStub and NewTypeArrayStub - JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3 - JDK-8234728: Some security tests should support TLSv1.3 - JDK-8235874: The ordering of Cipher Suites is not maintained provided through jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system property. - JDK-8237512: AArch64: aarch64TestHook leaks a BufferBlob - JDK-8238579: HttpsURLConnection drops the timeout and hangs forever in read - JDK-8242141: New System Properties to configure the TLS signature schemes - JDK-8246482: Build failures with +JFR -PCH - JDK-8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg - JDK-8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield - JDK-8251397: NPE on ClassValue.ClassValueMap.cacheArray - JDK-8253368: TLS connection always receives close_notify exception - JDK-8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem - JDK-8257192: Integrate AArch64 JIT port into 8u - JDK-8258079: Eliminate ParNew's use of klass_or_null() - JDK-8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() - JDK-8258933: G1 needs klass_or_null_acquire - JDK-8259312: VerifyCACerts.java fails as soneraclass2ca cert will - JDK-8259384: CUP version wrong in THIRD_PARTY_README after JDK-8233548 - JDK-8259568: PPC64 builds broken after JDK-8221408 8u backport Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Tue Feb 2 06:10:14 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 2 Feb 2021 06:10:14 +0000 Subject: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event In-Reply-To: References: Message-ID: <20210202061014.GA120663@rincewind> On 10:36 Mon 01 Feb , Yang Yi wrote: > Can anyone help review this patch :-O > > Thanks, > Yang Yi > > ------------------Original Mail ------------------ > Sender:Yang Yi > Send Date:Fri Jan 22 14:39:20 2021 > Recipients:jdk8u-dev at openjdk.java.net > Subject:RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event > > Hi, > > May I have a request backport of JDK-8237499? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8237499 > Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8237499/ > testing: jdk/test/jdk/jfr/ > > It's useful for users to know where their threads start. This patch doesn't apply > cleanly but is fairly trivial. The latest jdk8u-dev has no `Thread::current_or_null` > function, just adding this function solves the problem. > > This patch will cause another problem, e.g., the minimized VM fails to build, this > problem has been solved by JDK-8239886, so a follow-up backport of > JDK-8239886(one-line change) will be sent later. > > Cheers, > Yang Yi While we don't want the whole of JDK-8132510 for Thread::current_or_null, I would bring in the changes to thread.hpp so that the three methods - JavaThread::current, Thread::current and the new Thread::current_or_null - are interdependent, rather than duplicating each other. See attached patch. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 -------------- next part -------------- diff --git a/src/share/vm/runtime/thread.hpp b/src/share/vm/runtime/thread.hpp --- a/src/share/vm/runtime/thread.hpp +++ b/src/share/vm/runtime/thread.hpp @@ -678,9 +678,9 @@ "Don't use Thread::current() inside signal handler"); #endif #endif - Thread* thread = ThreadLocalStorage::thread(); - assert(thread != NULL, "just checking"); - return thread; + Thread* current = current_or_null(); + assert(current != NULL, "Thread::current() called on detached thread"); + return current; } // Name support for threads. non-JavaThread subclasses with multiple @@ -1777,8 +1777,8 @@ // Inline implementation of JavaThread::current inline JavaThread* JavaThread::current() { - Thread* thread = ThreadLocalStorage::thread(); - assert(thread != NULL && thread->is_Java_thread(), "just checking"); + Thread* thread = Thread::current(); + assert(thread->is_Java_thread(), "just checking"); return (JavaThread*)thread; } From qingfeng.yy at alibaba-inc.com Tue Feb 2 11:52:59 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Tue, 02 Feb 2021 19:52:59 +0800 Subject: =?UTF-8?B?UmU6IFBJTkc6IFJGUjogOHUgYmFja3BvcnQgb2YgSkRLLTgyMzc0OTkgSkZSOiBJbmNsdWRl?= =?UTF-8?B?IHN0YWNrIHRyYWNlIGluIHRoZSBUaHJlYWRTdGFydCBldmVudA==?= In-Reply-To: <20210202061014.GA120663@rincewind> References: , <20210202061014.GA120663@rincewind> Message-ID: Hi Andrew, Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? Please let me know if I misunderstand your reply. Thanks, Yang Yi ------------------------------------------------------------------ From:Andrew Hughes Send Time:2021 Feb. 2 (Tue.) 14:10 To:"YANG, Yi" Cc:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On 10:36 Mon 01 Feb , Yang Yi wrote: > Can anyone help review this patch :-O > > Thanks, > Yang Yi > > ------------------Original Mail ------------------ > Sender:Yang Yi > Send Date:Fri Jan 22 14:39:20 2021 > Recipients:jdk8u-dev at openjdk.java.net > Subject:RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event > > Hi, > > May I have a request backport of JDK-8237499? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8237499 > Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8237499/ > testing: jdk/test/jdk/jfr/ > > It's useful for users to know where their threads start. This patch doesn't apply > cleanly but is fairly trivial. The latest jdk8u-dev has no `Thread::current_or_null` > function, just adding this function solves the problem. > > This patch will cause another problem, e.g., the minimized VM fails to build, this > problem has been solved by JDK-8239886, so a follow-up backport of > JDK-8239886(one-line change) will be sent later. > > Cheers, > Yang Yi While we don't want the whole of JDK-8132510 for Thread::current_or_null, I would bring in the changes to thread.hpp so that the three methods - JavaThread::current, Thread::current and the new Thread::current_or_null - are interdependent, rather than duplicating each other. See attached patch. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 felix.yang at huawei.com Wed Feb 3 06:31:56 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 3 Feb 2021 06:31:56 +0000 Subject: RFR: 8260930: AARCH64: Invalid value passed to critical JNI function Message-ID: Hi, I see jvm crashes when running test on aarch64 linux: hotspot/test/compiler/criticalnatives/argumentcorruption/Test8167409.sh Original bug: https://bugs.openjdk.java.net/browse/JDK-8191129 Original patch: http://hg.openjdk.java.net/jdk/hs/rev/5fb0f3f24f6b Original RFR thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-November/027658.html I think we should also fix this for 8u aarch64. Webrev for 8u: http://cr.openjdk.java.net/~fyang/8191129-8u/webrev.00/ We need adaptations for changes in files vm_version_aarch64.cpp and Test8167409.sh for 8u. Performed full jtreg test with aarch64 release build. OK to backport? Thanks, Felix From aph at redhat.com Wed Feb 3 09:45:00 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Feb 2021 09:45:00 +0000 Subject: RFR: 8260930: AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: Message-ID: <5e16a4e0-2588-c976-684c-b9dcc1caf764@redhat.com> On 2/3/21 6:31 AM, Yangfei (Felix) wrote: > I think we should also fix this for 8u aarch64. Why? It doesn't affect any user's code. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From honguye at microsoft.com Tue Feb 2 21:46:25 2021 From: honguye at microsoft.com (Nhat Nguyen) Date: Tue, 2 Feb 2021 21:46:25 +0000 Subject: [EXTERNAL] Re: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: <4e6a3167c955d66ef732e46c7fcda51566d19359.camel@redhat.com> References: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> <4e6a3167c955d66ef732e46c7fcda51566d19359.camel@redhat.com> Message-ID: Hi all, Thank you all for the thoughtful responses. As someone who's new to the community, the replies really help me understand the risks involved in such changes; especially it's jdk8 that we're talking about here. I totally agree and acknowledge that, given the risks, changing the initialization order for the sake of performance is not plausible enough. With that said, for completeness sake only, I'm sharing more details on why I thought that changing the order can help trigger the JIT. But first I acknowledge that my understanding in this area of the code is limited, and so there are things that I could have overlooked. JvmtiExport::post_vm_initialized() [1] calls into eventHandlerVMInit() [2] which runs the premain method. At this point, CompileBroker::compilation_init() [3] hasn't been called yet, so the c1 and c2 compiler instances are always null [4]. This in turn makes the JVM deny all compilation requests [5]. The repro that I used to test the behaviour is [6]. The commands I used were: "java -javaagent:target/premain-test-1.0-SNAPSHOT.jar -version" for the premain version "java -jar target/premain-test-1.0-SNAPSHOT.jar" for the regular main version In this repro, the premain version is consistently slow as opposed to the main version which sees significant speedup after the JIT has kicked in. After changing the initialization order, running the premain version with -XX:+PrintCompilation showed that the JIT is in effect and allowed the premain version to run as fast as the main one. As I mention above, I'm sharing the my findings for completeness only. I understand that even if the JIT is indeed in effect in this particular case, there are certain hidden dependencies that make this a very risky change. I'm also cc'ing Trask here, who is more familiar with the javaagent in question, so that he can discuss some potential workarounds that David mentioned. Thank you, Nhat [1]: JvmtiExport::post_vm_initialized() https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/runtime/thread.cpp#L3638 [2]: eventHandlerVMInit() calling premain https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/jdk/src/share/instrument/InvocationAdapter.c#L490 [3]: CompileBroker::compilation_init() https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/runtime/thread.cpp#L3648 [4]: CompileBroker::compilation_init() initializing c1 & c2 instances https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/compiler/compileBroker.cpp#L897 [5]: https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/compiler/compileBroker.cpp#L1350 [6]: https://github.com/trask/premain-test -----Original Message----- From: Severin Gehwolf Sent: Thursday, January 28, 2021 2:05 AM To: David Holmes ; Nhat Nguyen ; hotspot-dev at openjdk.java.net Cc: jdk8u-dev ; Andrew Haley Subject: [EXTERNAL] Re: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase Hi, On Thu, 2021-01-28 at 14:37 +1000, David Holmes wrote: > Hi, > > On 28/01/2021 10:51 am, Nhat Nguyen wrote: > > Hi, > > > > I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, > > where the JavaAgent code is always interpreted during the initialization phase on jdk8. > > Just FYI for changes to 8u you need to raise the issue on > jdk8u-dev at openjdk.java.net. Adding jdk8u-dev to cc. > > > For background, one of our tools is currently making use of a > > JavaAgent whose performance is important. As part of a performance > > investigation, I discovered that the CompilerBroker is not > > initialized by the time the premain method runs, therefore all compilation requests for the JavaAgent are discarded. > > > > Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. > > However, the ticket was closed as "Not an issue" because the > > initialization order is changed with the introduction of the module system. > > > > So I would like to ask the mailing list for opinions on whether a > > fix for this issue can be considered for jdk8u. I have also attached > > a prototype fix [2] and would appreciate any suggestions and comments as well. > > You have to be extremely careful changing the initialization order as > there are many hidden inter-dependencies. Yes, and we've been bitten by this before[i]. There is a significant risk involved changing initialization order in stable jdk8u. The reasons given here don't strike me as a good enough reason to accept such a patch. YMMV. Andrew Haley, thoughts? Thanks, Severin [i] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8249158&data=04%7C01%7Chonguye%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=nXN72pGgJ%2FhFKSPrj4cWfkiblAvhVCug5JcXl1y279I%3D&reserved=0 and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8233197&data=04%7C01%7Chonguye%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=OzvFPmEZYa4k2RPGdVYNYc6Du7BH8mOuiB%2FGV666Yeg%3D&reserved=0 > And as Serguei stated, that change may potentially allow JIT'ing to be > possible, but that doesn't mean it will actually occur. > > Cheers, > David > ----- > > > > > [1]: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > > gs.openjdk.java.net%2Fbrowse%2FJDK-7018422&data=04%7C01%7Chonguy > > e%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f14 > > 1af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZ > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > %3D%7C2000&sdata=ds5f37k%2B4297QtOCNjd%2BrezIqyU2rmcT4URVBPCB8Kg > > %3D&reserved=0 > > [2]: > > > > --- > > ? hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- > > ? 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/hotspot/src/share/vm/runtime/thread.cpp > > b/hotspot/src/share/vm/runtime/thread.cpp > > index 330593acb3..3918f989cc 100644 > > --- a/hotspot/src/share/vm/runtime/thread.cpp > > +++ b/hotspot/src/share/vm/runtime/thread.cpp > > @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ????? create_vm_init_libraries(); > > ??? } > > ? > > -? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > -? JvmtiExport::post_vm_initialized(); > > - > > -? JFR_ONLY(Jfr::on_vm_start();) > > - > > ??? if (CleanChunkPoolAsync) { > > ????? Chunk::start_chunk_pool_cleaner_task(); > > ??? } > > @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ??? CompileBroker::compilation_init(); > > ? #endif > > ? > > +? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > +? JvmtiExport::post_vm_initialized(); > > + > > +? JFR_ONLY(Jfr::on_vm_start();) > > + > > ??? if (EnableInvokeDynamic) { > > ????? // Pre-initialize some JSR292 core classes to avoid deadlock > > during class loading. > > ????? // It is done after compilers are initialized, because > > otherwise compilations of > > -- > > > From sgehwolf at redhat.com Wed Feb 3 13:41:33 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 03 Feb 2021 14:41:33 +0100 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> Message-ID: Hi! Anyone willing to review this? Dependencies are in 8u-dev by now. Thanks, Severin On Mon, 2021-01-11 at 12:35 +0100, Severin Gehwolf wrote: > Hi, > > Please review this 8u backport of JDK-8172404, an enhancement to warn > about insecure and soon-to-be-disabled algorithms in security tools. > This patch introduces a new security property, > jdk.security.legacyAlgorithms, and thus requires a CSR. Since Oracle > backported this patch, we are re-using that CSR. > > The original patch doesn't apply cleanly so I had to adjust hunks > manually. In order for this backport to apply better, it depends on > JDK-8185934[1] and JDK-8233228[2]. Of particular note are the > differences in jarsigner/Main.java method signJar(). For this > backport, > I've moved initialization of a null sigalg a bit earlier in signJar() > by virtue of calling new private static method > getDefaultSignatureAlgorithm(privateKey). This allows one to reason > that sigalg, tSADigestAlg and digestalg will never be null when new > method checkWeakSign() is being called. The former, because of what > I've just explained earlier, the latter two because they are being > set > to default values on object construction in contrast to code in JDK > 11u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172404 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8172404/jdk8/02/webrev/ > CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8238640 > > Testing: keytool/jarsigner tests. Manual testing that warnings are > being printed for weak CA certs in cacerts > > Thoughts? > > Thanks, > Severin From gnu.andrew at redhat.com Wed Feb 3 17:45:03 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Feb 2021 17:45:03 +0000 Subject: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event In-Reply-To: References: <20210202061014.GA120663@rincewind> Message-ID: <20210203174503.GA264757@rincewind> On 19:52 Tue 02 Feb , Yang Yi wrote: > Hi Andrew, > > Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? > > Please let me know if I misunderstand your reply. > > Thanks, > Yang Yi > Yes, that's correct. In other words, please add my patch to what you have and provide an updated webrev :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 3 18:28:28 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Feb 2021 18:28:28 +0000 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> Message-ID: <20210203182828.GB264757@rincewind> On 14:41 Wed 03 Feb , Severin Gehwolf wrote: > Hi! > > Anyone willing to review this? Dependencies are in 8u-dev by now. > > Thanks, > Severin > > On Mon, 2021-01-11 at 12:35 +0100, Severin Gehwolf wrote: > > Hi, > > > > Please review this 8u backport of JDK-8172404, an enhancement to warn > > about insecure and soon-to-be-disabled algorithms in security tools. > > This patch introduces a new security property, > > jdk.security.legacyAlgorithms, and thus requires a CSR. Since Oracle > > backported this patch, we are re-using that CSR. > > > > The original patch doesn't apply cleanly so I had to adjust hunks > > manually. In order for this backport to apply better, it depends on > > JDK-8185934[1] and JDK-8233228[2]. Of particular note are the > > differences in jarsigner/Main.java method signJar(). For this > > backport, > > I've moved initialization of a null sigalg a bit earlier in signJar() > > by virtue of calling new private static method > > getDefaultSignatureAlgorithm(privateKey). This allows one to reason > > that sigalg, tSADigestAlg and digestalg will never be null when new > > method checkWeakSign() is being called. The former, because of what > > I've just explained earlier, the latter two because they are being > > set > > to default values on object construction in contrast to code in JDK > > 11u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172404 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8172404/jdk8/02/webrev/ > > CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8238640 > > > > Testing: keytool/jarsigner tests. Manual testing that warnings are > > being printed for weak CA certs in cacerts > > > > Thoughts? > > > > Thanks, > > Severin > > Code looks good. Just a couple of typographical issues: 1. In jarsigner/Main.java, a newline has gone missing in the changes there: 11u: + checkWeakSign(sigalg, SIG_PRIMITIVE_SET, false); + + checkWeakSign(privateKey); 8u: + checkWeakSign(sigalg, SIG_PRIMITIVE_SET, false); + checkWeakSign(privateKey); 2. The test/sun/security/tools/keytool/WeakAlg.java changes look quite different when comparing the 11u & 8u patches. Can you confirm the patched files are the same (or close enough)? No need for a new webrev just for the correction in #1 if #2 is not an issue. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 3 18:30:10 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Feb 2021 18:30:10 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> Message-ID: <20210203183010.GC264757@rincewind> On 07:58 Fri 27 Nov , Vladimir Kempik wrote: > Hello Andrew > May we hope the backport of jep-391 (macos-aarch64 port) will be allowed at some point into 11/8u too ? > > Thanks, Vladimir. > As far as I'm aware, macos-x86_64 currently doesn't work with 8u, so that would need to be fixed first. I don't see any issue with adding the additional OS port to 8u & 11u, but that's something to discuss with the aarch64 port project. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 mbalao at redhat.com Wed Feb 3 19:04:27 2021 From: mbalao at redhat.com (Martin Balao) Date: Wed, 3 Feb 2021 16:04:27 -0300 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> Message-ID: <7ad18cf3-c943-5b6f-0c41-07905af98624@redhat.com> Hi Severin, Thanks for proposing this backport. On 2/3/21 10:41 AM, Severin Gehwolf wrote: This allows one to reason >> that sigalg, tSADigestAlg and digestalg will never be null when new >> method checkWeakSign() is being called. The former, because of what >> I've just explained earlier, the latter two because they are being >> set >> to default values on object construction in contrast to code in JDK >> 11u. In the case of tSADigestAlg and digestalg, my understanding is that you are assuming that they cannot be null because in 8u they are initialized upon object construction. I.e.: String digestalg = "SHA-256". However, I've seen "if (digestalg != null ..." and "if (tSADigestAlg != null ..." statements in 8u which makes me think that this is not necessarily true, as if the instance variable can eventually turn null after the object is created. Otherwise, those checks would be redundant. I've seen a couple of places where the value is updated. Have you ruled out this possibility? Martin.- From sgehwolf at redhat.com Wed Feb 3 20:15:26 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 03 Feb 2021 21:15:26 +0100 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <7ad18cf3-c943-5b6f-0c41-07905af98624@redhat.com> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <7ad18cf3-c943-5b6f-0c41-07905af98624@redhat.com> Message-ID: <7c5194ee1510738bb1bf5f192ff88fab9bfb7ab9.camel@redhat.com> Hi Martin, On Wed, 2021-02-03 at 16:04 -0300, Martin Balao wrote: > Hi Severin, > > Thanks for proposing this backport. Thanks for the review! > On 2/3/21 10:41 AM, Severin Gehwolf wrote: > ?This allows one to reason > > > that sigalg, tSADigestAlg and digestalg will never be null when new > > > method checkWeakSign() is being called. The former, because of what > > > I've just explained earlier, the latter two because they are being > > > set > > > to default values on object construction in contrast to code in JDK > > > 11u. > > In the case of tSADigestAlg and digestalg, my understanding is that you > are assuming that they cannot be null because in 8u they are initialized > upon object construction. I.e.: String digestalg = "SHA-256". However, > I've seen "if (digestalg != null ..." and "if (tSADigestAlg != null ..." > statements Can you be more specific? If I grep for 'digestalg' in the jdk source tree only usages in jarsigner/Main.java come up and related Resources.java files. Similar for tSADigestAlg. > in 8u which makes me think that this is not necessarily true, > as if the instance variable can eventually turn null after the object is > created. Otherwise, those checks would be redundant. I've seen a couple > of places where the value is updated. Have you ruled out this possibility? I believe I have. The only place where 'digestalg' is assigned a value is on line 437 in jarsigner/Main.java: } else if (collator.compare(flags, "-digestalg") ==0) { if (++n == args.length) usageNoArg(); digestalg = args[n]; where the value comes from the arguments string passed in via jarsigner CLI args which cannot be null. The argument for tSADigestAlg is similar. Line 400 of jarsigner/Main.java reads: } else if (collator.compare(flags, "-tsadigestalg") ==0) { if (++n == args.length) usageNoArg(); tSADigestAlg = args[n]; I might have missed some spots, but I think this needs to be viewed in the context of being used as a CLI tool: jarsigner. Thanks, Severin From mbalao at redhat.com Wed Feb 3 21:14:05 2021 From: mbalao at redhat.com (Martin Balao) Date: Wed, 3 Feb 2021 18:14:05 -0300 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <7c5194ee1510738bb1bf5f192ff88fab9bfb7ab9.camel@redhat.com> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <7ad18cf3-c943-5b6f-0c41-07905af98624@redhat.com> <7c5194ee1510738bb1bf5f192ff88fab9bfb7ab9.camel@redhat.com> Message-ID: On 2/3/21 5:15 PM, Severin Gehwolf wrote: >> In the case of tSADigestAlg and digestalg, my understanding is that you >> are assuming that they cannot be null because in 8u they are initialized >> upon object construction. I.e.: String digestalg = "SHA-256". However, >> I've seen "if (digestalg != null ..." and "if (tSADigestAlg != null ..." >> statements > > Can you be more specific? If I grep for 'digestalg' in the jdk source > tree only usages in jarsigner/Main.java come up and related > Resources.java files. Similar for tSADigestAlg. > Sure. What I've seen is that the use of 'digestalg' and 'tSADigestAlg' required a non-null check here [1] and here [2] respectively. These checks made me think that these variables can eventually be null inside the signJar method. Otherwise, the checks wouldn't have been necessary. >> in 8u which makes me think that this is not necessarily true, >> as if the instance variable can eventually turn null after the object is >> created. Otherwise, those checks would be redundant. I've seen a couple >> of places where the value is updated. Have you ruled out this possibility? > > I believe I have. The only place where 'digestalg' is assigned a value > is on line 437 in jarsigner/Main.java: > > } else if (collator.compare(flags, "-digestalg") ==0) { > if (++n == args.length) usageNoArg(); > digestalg = args[n]; > > where the value comes from the arguments string passed in via jarsigner > CLI args which cannot be null. Yes, seems right. If no value is set after -digestalg/-tsadigestalg, the args length check aborts execution. Otherwise, there has to be something -assuming a call from CLI-. The argument for tSADigestAlg is > similar. Line 400 of jarsigner/Main.java reads: > > } else if (collator.compare(flags, "-tsadigestalg") ==0) { > if (++n == args.length) usageNoArg(); > tSADigestAlg = args[n]; > > I might have missed some spots, but I think this needs to be viewed in > the context of being used as a CLI tool: jarsigner. > Yes, I've seen those usages as well and no others. Yeah, it well be the case that the check in [1] and [2] were not necessary -or became unnecessary at some point-. Thanks for checking this. One more think regarding 'getDefaultSignatureAlgorithm'. I've seen that there is a similar method in 8u's keytool/Main.java file. In 11u, it goes to AlgorithmId::getDefaultSigAlgForKey. AlgorithmId is an internal class (sun.. package). I'd keep a single implementation of this method in the AlgorithmId class (if backporting the patch that introduces the method is non-trivial). Up to you. Looks good to me. Martin.- From qingfeng.yy at alibaba-inc.com Thu Feb 4 03:08:39 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Thu, 04 Feb 2021 11:08:39 +0800 Subject: =?UTF-8?B?UmU6IFBJTkc6IFJGUjogOHUgYmFja3BvcnQgb2YgSkRLLTgyMzc0OTkgSkZSOiBJbmNsdWRl?= =?UTF-8?B?IHN0YWNrIHRyYWNlIGluIHRoZSBUaHJlYWRTdGFydCBldmVudA==?= In-Reply-To: <20210203174503.GA264757@rincewind> References: <20210202061014.GA120663@rincewind> , <20210203174503.GA264757@rincewind> Message-ID: <4c526e1a-293b-4216-8576-135871a0d999.qingfeng.yy@alibaba-inc.com> Hi Andrew, Thanks to your explanation, it makes sense, I have updated my patch according to your change. Webrev: HotSpot Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/hotspot-webrev.01/ JDK Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/jdk-webrev/ Cheers, Yang Yi ------------------------------------------------------------------ From:Andrew Hughes Send Time:2021 Feb. 4 (Thu.) 01:45 To:"YANG, Yi" Cc:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On 19:52 Tue 02 Feb , Yang Yi wrote: > Hi Andrew, > > Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? > > Please let me know if I misunderstand your reply. > > Thanks, > Yang Yi > Yes, that's correct. In other words, please add my patch to what you have and provide an updated webrev :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 felix.yang at huawei.com Thu Feb 4 03:30:51 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 4 Feb 2021 03:30:51 +0000 Subject: RFR: 8260930: AARCH64: Invalid value passed to critical JNI function In-Reply-To: <5e16a4e0-2588-c976-684c-b9dcc1caf764@redhat.com> References: <5e16a4e0-2588-c976-684c-b9dcc1caf764@redhat.com> Message-ID: Hi, Thanks for the reply. > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Wednesday, February 3, 2021 5:45 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8260930: AARCH64: Invalid value passed to critical JNI > function > > On 2/3/21 6:31 AM, Yangfei (Felix) wrote: > > I think we should also fix this for 8u aarch64. > > Why? It doesn't affect any user's code. Well, I was assuming this is a "significant" bug according to the following guideline on [1]: " All fixes that significantly improve stability, security or performance and do not change behavioural compatibility [1]will be considered for jdk8u. To use the language of the JDK 6 project, by default such fixes are assumed to be applicable to jdk8u, especially if having "soaked" in later JDK releases for a time without incident. By "significant" I mean any bug that affects runtime behaviour in a way that either produces incorrect results, poor performance, or crashes the VM, especially TCK failures. Failures that are due solely to bizarre or unreasonable combinations of -XX: command-line parameters probably don't reach the bar of significance, and fixing them will carry a non-zero risk of breaking something, so we should err on the size of caution. For now it's mostly "bug fixes only"." Here, the aarch64 VM crashes when executing an existing regression test. And backporting the fix should be low in risk given that that this feature is rarely used so far. I am also worried that people with 8u may create new code or modify existing code making use of the critical JNI feature for performance reasons. Instead of crashing and possibly giving people the impression that the aarch64 VM is not quite stable, I think it will be better to tell them explicitly that this feature is not supported on this platform. I will let you 8u maintainers to decide. [1] https://wiki.openjdk.java.net/display/jdk8u/Guidelines+for+working+on+jdk8u Thanks, Felix From mbalao at redhat.com Thu Feb 4 16:23:29 2021 From: mbalao at redhat.com (Martin Balao) Date: Thu, 4 Feb 2021 13:23:29 -0300 Subject: [8u] RFR 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: <47d919b2-6b6d-614d-a69b-914109cdc09c@redhat.com> References: <47d919b2-6b6d-614d-a69b-914109cdc09c@redhat.com> Message-ID: Any chances on this one? Should be fairly easy.. Thanks! On Wed, Jan 27, 2021 at 4:38 PM Martin Balao wrote: > > Hi, > > I'd like to propose an 8u backport of JDK-8258833 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8258833/8258833.webrev.8u.jdk.00 > > The 11u patch does not apply cleanly because of the following conflicts: > > * src/share/classes/sun/security/pkcs11/P11Signature.java > * JDK-8149802 was not backported to 8u, so the context for one of the > hunks is different. In particular, "pe" was expected to be the > PKCS11Exception exception variable name -in 8u the name is "e"-, and a > catch "SignatureException | ProviderException e" line was expected > after. None of this affects the 8u backport of 8258833; which, in the > aforementioned hunk, adds documentation only. Backporting 8149802 to 8u > would require further analysis; as the fix is quite old now and many > changes have been applied on top of it. For example, the most-updated > jdk/jdk code just re-throws the SignatureException and ProviderException > exceptions. In other words, the cancelOperation call introduced by > 8149802 was removed and it's a no-operation now. Please notice that both > jdk/jdk and 8u do a cancel call from the 'finally' block (which did not > exist by the time 8149802 was developed). As a result, my suggestion > here would be not to block the 8u backport of 8258833 enforcing a > dependency on 8149802. The conflict has been trivially fixed rebasing > the hunk context to 8u. > > * test/sun/security/pkcs11/Cipher/CancelMultipart.java > * '@modules jdk.crypto.cryptoki/sun.security.pkcs11:open' does not > apply to 8u > * '/test/lib' library path replaced with '/lib/security' > > * File paths converted to the pre-modules scheme. > > Testing: no regressions observed in the sun/security/pkcs11 category. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8258833 From sgehwolf at redhat.com Thu Feb 4 19:18:47 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 04 Feb 2021 20:18:47 +0100 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <20210203182828.GB264757@rincewind> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <20210203182828.GB264757@rincewind> Message-ID: <3407430c39a8b323cb845c5ae039c05b1debea75.camel@redhat.com> Hi Andrew, Thanks for the review! On Wed, 2021-02-03 at 18:28 +0000, Andrew Hughes wrote: > Code looks good. Just a couple of typographical issues: > > 1. In jarsigner/Main.java, a newline has gone missing in the changes > there: > > 11u: > > +??????? checkWeakSign(sigalg, SIG_PRIMITIVE_SET, false); > + > +??????? checkWeakSign(privateKey); > > 8u: > > +??????? checkWeakSign(sigalg, SIG_PRIMITIVE_SET, false); > +??????? checkWeakSign(privateKey); Thanks. Fixed locally. > 2. The test/sun/security/tools/keytool/WeakAlg.java changes > look quite different when comparing the 11u & 8u patches. Can > you confirm the patched files are the same (or close enough)? Yes, this is what I've used to arrive at the result. Looking at the JDK 11 code. Here is a diff (seems close enough to me): https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8172404/jdk8/02/WeakAlg.java.jdk8-jdk11.diff > No need for a new webrev just for the correction in #1 if #2 is not an > issue. It doesn't seem to be. Thanks, Severin From hohensee at amazon.com Thu Feb 4 22:22:25 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 4 Feb 2021 22:22:25 +0000 Subject: [8u] RFR 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Message-ID: <2384CB8C-4088-46A3-8E87-821E72D29959@amazon.com> Looks good. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Martin Balao Date: Thursday, February 4, 2021 at 8:24 AM To: "jdk8u-dev at openjdk.java.net" , Severin Gehwolf Subject: RE: [8u] RFR 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Any chances on this one? Should be fairly easy.. Thanks! On Wed, Jan 27, 2021 at 4:38 PM Martin Balao wrote: > > Hi, > > I'd like to propose an 8u backport of JDK-8258833 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8258833/8258833.webrev.8u.jdk.00 > > The 11u patch does not apply cleanly because of the following conflicts: > > * src/share/classes/sun/security/pkcs11/P11Signature.java > * JDK-8149802 was not backported to 8u, so the context for one of the > hunks is different. In particular, "pe" was expected to be the > PKCS11Exception exception variable name -in 8u the name is "e"-, and a > catch "SignatureException | ProviderException e" line was expected > after. None of this affects the 8u backport of 8258833; which, in the > aforementioned hunk, adds documentation only. Backporting 8149802 to 8u > would require further analysis; as the fix is quite old now and many > changes have been applied on top of it. For example, the most-updated > jdk/jdk code just re-throws the SignatureException and ProviderException > exceptions. In other words, the cancelOperation call introduced by > 8149802 was removed and it's a no-operation now. Please notice that both > jdk/jdk and 8u do a cancel call from the 'finally' block (which did not > exist by the time 8149802 was developed). As a result, my suggestion > here would be not to block the 8u backport of 8258833 enforcing a > dependency on 8149802. The conflict has been trivially fixed rebasing > the hunk context to 8u. > > * test/sun/security/pkcs11/Cipher/CancelMultipart.java > * '@modules jdk.crypto.cryptoki/sun.security.pkcs11:open' does not > apply to 8u > * '/test/lib' library path replaced with '/lib/security' > > * File paths converted to the pre-modules scheme. > > Testing: no regressions observed in the sun/security/pkcs11 category. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8258833 From hedongbo at huawei.com Fri Feb 5 02:26:47 2021 From: hedongbo at huawei.com (hedongbo) Date: Fri, 5 Feb 2021 02:26:47 +0000 Subject: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream Message-ID: <8FC616E5EC1A774287430B1CC2696FE30471858A@dggeml513-mbx.china.huawei.com> Hi, Please help review this changes. webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-6878250 related bug: https://bugs.openjdk.java.net/browse/JDK-8260875 related thread: https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008123.html Thanks, dongbohe From gnu.andrew at redhat.com Mon Feb 8 05:39:57 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 8 Feb 2021 05:39:57 +0000 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <3407430c39a8b323cb845c5ae039c05b1debea75.camel@redhat.com> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <20210203182828.GB264757@rincewind> <3407430c39a8b323cb845c5ae039c05b1debea75.camel@redhat.com> Message-ID: <20210208053957.GA111128@rincewind> On 20:18 Thu 04 Feb , Severin Gehwolf wrote: > snip... > > 2. The test/sun/security/tools/keytool/WeakAlg.java changes > > look quite different when comparing the 11u & 8u patches. Can > > you confirm the patched files are the same (or close enough)? > > Yes, this is what I've used to arrive at the result. Looking at the JDK > 11 code. Here is a diff (seems close enough to me): > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8172404/jdk8/02/WeakAlg.java.jdk8-jdk11.diff > I agree, just expected 11u differences. If Martin is happy, feel free to flag this for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Mon Feb 8 05:45:06 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 8 Feb 2021 05:45:06 +0000 Subject: [8u] RFR 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures In-Reply-To: <47d919b2-6b6d-614d-a69b-914109cdc09c@redhat.com> References: <47d919b2-6b6d-614d-a69b-914109cdc09c@redhat.com> Message-ID: <20210208054506.GB111128@rincewind> On 16:38 Wed 27 Jan , Martin Balao wrote: > Hi, > > I'd like to propose an 8u backport of JDK-8258833 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8258833/8258833.webrev.8u.jdk.00 > > The 11u patch does not apply cleanly because of the following conflicts: > > * src/share/classes/sun/security/pkcs11/P11Signature.java > * JDK-8149802 was not backported to 8u, so the context for one of the > hunks is different. In particular, "pe" was expected to be the > PKCS11Exception exception variable name -in 8u the name is "e"-, and a > catch "SignatureException | ProviderException e" line was expected > after. None of this affects the 8u backport of 8258833; which, in the > aforementioned hunk, adds documentation only. Backporting 8149802 to 8u > would require further analysis; as the fix is quite old now and many > changes have been applied on top of it. For example, the most-updated > jdk/jdk code just re-throws the SignatureException and ProviderException > exceptions. In other words, the cancelOperation call introduced by > 8149802 was removed and it's a no-operation now. Please notice that both > jdk/jdk and 8u do a cancel call from the 'finally' block (which did not > exist by the time 8149802 was developed). As a result, my suggestion > here would be not to block the 8u backport of 8258833 enforcing a > dependency on 8149802. The conflict has been trivially fixed rebasing > the hunk context to 8u. > > * test/sun/security/pkcs11/Cipher/CancelMultipart.java > * '@modules jdk.crypto.cryptoki/sun.security.pkcs11:open' does not > apply to 8u > * '/test/lib' library path replaced with '/lib/security' > > * File paths converted to the pre-modules scheme. > > Testing: no regressions observed in the sun/security/pkcs11 category. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8258833 > Looks good to me. Approved. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 qingfeng.yy at alibaba-inc.com Mon Feb 8 06:58:01 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Mon, 08 Feb 2021 14:58:01 +0800 Subject: =?UTF-8?B?UmU6IFJlOiBQSU5HOiBSRlI6IDh1IGJhY2twb3J0IG9mIEpESy04MjM3NDk5IEpGUjogSW5j?= =?UTF-8?B?bHVkZSBzdGFjayB0cmFjZSBpbiB0aGUgVGhyZWFkU3RhcnQgZXZlbnQ=?= In-Reply-To: <4c526e1a-293b-4216-8576-135871a0d999.qingfeng.yy@alibaba-inc.com> References: <20210202061014.GA120663@rincewind> , <20210203174503.GA264757@rincewind>, <4c526e1a-293b-4216-8576-135871a0d999.qingfeng.yy@alibaba-inc.com> Message-ID: Gentle Ping :-) ------------------Original Mail ------------------ Sender:Yang Yi Send Date:Thu Feb 4 11:08:39 2021 Recipients:Andrew Hughes CC:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Hi Andrew, Thanks to your explanation, it makes sense, I have updated my patch according to your change. Webrev: HotSpot Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/hotspot-webrev.01/ JDK Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/jdk-webrev/ Cheers, Yang Yi ------------------------------------------------------------------ From:Andrew Hughes Send Time:2021 Feb. 4 (Thu.) 01:45 To:"YANG, Yi" Cc:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On 19:52 Tue 02 Feb , Yang Yi wrote: > Hi Andrew, > > Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? > > Please let me know if I misunderstand your reply. > > Thanks, > Yang Yi > Yes, that's correct. In other words, please add my patch to what you have and provide an updated webrev :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 mbalao at redhat.com Mon Feb 8 13:30:30 2021 From: mbalao at redhat.com (Martin Balao) Date: Mon, 8 Feb 2021 10:30:30 -0300 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <20210208053957.GA111128@rincewind> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <20210203182828.GB264757@rincewind> <3407430c39a8b323cb845c5ae039c05b1debea75.camel@redhat.com> <20210208053957.GA111128@rincewind> Message-ID: <92fd3fa0-ee7b-a980-da2c-8c54ca1cb6b6@redhat.com> On 2/8/21 2:39 AM, Andrew Hughes wrote: > > I agree, just expected 11u differences. If Martin is happy, feel free to flag this for approval. > Yes, looks good to me. My previous comment (a method being duplicated) is optional. From sgehwolf at redhat.com Mon Feb 8 15:26:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 08 Feb 2021 16:26:00 +0100 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them In-Reply-To: <92fd3fa0-ee7b-a980-da2c-8c54ca1cb6b6@redhat.com> References: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> <20210203182828.GB264757@rincewind> <3407430c39a8b323cb845c5ae039c05b1debea75.camel@redhat.com> <20210208053957.GA111128@rincewind> <92fd3fa0-ee7b-a980-da2c-8c54ca1cb6b6@redhat.com> Message-ID: <01b1c62a75dbbee99142fc27ba50d98fa6c2edd8.camel@redhat.com> On Mon, 2021-02-08 at 10:30 -0300, Martin Balao wrote: > On 2/8/21 2:39 AM, Andrew Hughes wrote: > > > > I agree, just expected 11u differences. If Martin is happy, feel > > free to flag this for approval. > > > > Yes, looks good to me. My previous comment (a method being duplicated) > is optional. OK. Flagged for approval. Thanks, Severin From aph at redhat.com Mon Feb 8 18:45:24 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Feb 2021 18:45:24 +0000 Subject: RFR: 8260930: AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: <5e16a4e0-2588-c976-684c-b9dcc1caf764@redhat.com> Message-ID: On 2/4/21 3:30 AM, Yangfei (Felix) wrote: > Here, the aarch64 VM crashes when executing an existing regression test. > And backporting the fix should be low in risk given that that this feature is rarely used so far. > I am also worried that people with 8u may create new code or modify existing code making use of the critical JNI feature for performance reasons. I guess that's possible. > Instead of crashing and possibly giving people the impression that the aarch64 VM is not quite stable, I think it will be better to tell them explicitly that this feature is not supported on this platform. > I will let you 8u maintainers to decide. > > [1] https://wiki.openjdk.java.net/display/jdk8u/Guidelines+for+working+on+jdk8u OK, if you like, but bear in mind that it's significant fixes only. 8u is supposed to be the long-term-stable release. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Tue Feb 9 02:20:30 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 9 Feb 2021 02:20:30 +0000 Subject: RFR: 8260930: AARCH64: Invalid value passed to critical JNI function In-Reply-To: References: <5e16a4e0-2588-c976-684c-b9dcc1caf764@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, February 9, 2021 2:45 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8260930: AARCH64: Invalid value passed to critical JNI > function > > On 2/4/21 3:30 AM, Yangfei (Felix) wrote: > > Here, the aarch64 VM crashes when executing an existing regression test. > > > And backporting the fix should be low in risk given that that this feature is > rarely used so far. > > I am also worried that people with 8u may create new code or modify > existing code making use of the critical JNI feature for performance reasons. > > I guess that's possible. > > > Instead of crashing and possibly giving people the impression that the > aarch64 VM is not quite stable, I think it will be better to tell them explicitly > that this feature is not supported on this platform. > > I will let you 8u maintainers to decide. > > > > [1] > > https://wiki.openjdk.java.net/display/jdk8u/Guidelines+for+working+on+ > > jdk8u > > OK, if you like, but bear in mind that it's significant fixes only. 8u is supposed > to be the long-term-stable release. Yes, sure. I think I can post it here for judgment when I got a bug which is questionable for backporting. I've flagged the backport bug for approval: https://bugs.openjdk.java.net/browse/JDK-8260930 Thanks, Felix From andreas at ahlenstorf.ch Tue Feb 9 11:17:20 2021 From: andreas at ahlenstorf.ch (Andreas Ahlenstorf) Date: Tue, 09 Feb 2021 12:17:20 +0100 Subject: =?UTF-8?Q?RFR:_8u_backport_of_JDK-8211301_[macos]_support_full_window_co?= =?UTF-8?Q?ntent_options?= Message-ID: Hi! The backport adds support for the two properties apple.awt.fullWindowContent apple.awt.transparentTitleBar that make the content view extend into the window's title bar on macOS. The 11u patch didn't apply cleanly to 8u, so I copied it over manually. I didn't have to make any material changes. Original CSR: https://bugs.openjdk.java.net/browse/JDK-8242566 Backport bug: https://bugs.openjdk.java.net/browse/JDK-8211301 Webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/aahlenstorf/JDK-8211301/01/webrev/ Thanks, Andreas From gnu.andrew at redhat.com Wed Feb 10 03:47:02 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 10 Feb 2021 03:47:02 +0000 Subject: OpenJDK 8u292-b02 EA Released Message-ID: <20210210034702.GA231450@rincewind> I've made available an early access source bundle for 8u292, based on the tag jdk8u292-b02: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b02-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b02-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint: CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 82c6a6275c06bf55d841b97c9c2536fd3c64e9ac7166e14ac245f14eb6ae1640 openjdk8u292-b02-ea.tar.xz 2d0d7fd4ffc8aa15fe1a3a0d75a98536534879a0ac8163722fa4fb1cf3640ca3 openjdk8u292-b02-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b02-ea.sha256 Changes in 8u292-b02: - JDK-8078614: WindowsClassicLookAndFeel MetalComboBoxUI.getbaseLine fails with IllegalArgumentException - JDK-8198334: java/awt/FileDialog/8003399/bug8003399.java fails in headless mode - JDK-8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel - JDK-8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets - JDK-8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 alexey at azul.com Wed Feb 10 10:00:23 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 10 Feb 2021 10:00:23 +0000 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete Message-ID: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> Hi, Please review the backport of JDK-8256682 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8256682 Original change: https://github.com/openjdk/jdk/commit/b9db002f 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/ Original fix does not apply cleanly because of NullHostnameCheck.java test was not updated as part of JDK-8202343 8u backport [1]. This patch includes missed parts of the original fix for JDK-8202343 [2]. [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f2f0ceec19fb [2] https://github.com/openjdk/jdk/commit/3a4b90f0 Regards Alexey From sgehwolf at redhat.com Wed Feb 10 10:26:23 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Feb 2021 11:26:23 +0100 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> Message-ID: <2c884c377bbdb9b15827b170028442136ee98120.camel@redhat.com> Hi Alexey, On Wed, 2021-02-10 at 10:00 +0000, Alexey Bakhtin wrote: > Hi, > Please review the backport of JDK-8256682 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256682 > Original change: https://github.com/openjdk/jdk/commit/b9db002f > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/ This looks fine. Thanks! Cheers, Severin From gnu.andrew at redhat.com Thu Feb 11 05:05:33 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 11 Feb 2021 05:05:33 +0000 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> Message-ID: <20210211050533.GA293608@rincewind> On 10:00 Wed 10 Feb , Alexey Bakhtin wrote: > Hi, > Please review the backport of JDK-8256682 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256682 > Original change: https://github.com/openjdk/jdk/commit/b9db002f > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/ > There seems to be an issue with this webrev. https://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/jdk.changeset just has a header and no body. > Original fix does not apply cleanly because of NullHostnameCheck.java test was not updated as part of JDK-8202343 8u backport [1]. This patch includes missed parts of the original fix for JDK-8202343 [2]. > This appears to have been deliberate: " * test/sun/security/util/HostnameMatcher/NullHostnameCheck.java * JDK-8228967 is not in 8u so there is a context conflict while adding the import. JDK-8228967 also causes a context conflict when adding the line that re-enables TLS 1.0 and 1.1. However, these changes are not needed in 8u as the test works for TLS 1.2 only (so there is no need to re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u, this test will fail until TLS 1.0 and 1.1 are enabled." [0] I must admit it doesn't make sense to me why it would be TLS 1.2 only, but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it. Are you seeing test failures due to the lack of this block? It would be good to know why we need to revisit the original decision on including this block. > [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f2f0ceec19fb > [2] https://github.com/openjdk/jdk/commit/3a4b90f0 > > Regards > Alexey > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013341.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 alexey at azul.com Thu Feb 11 09:15:27 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 11 Feb 2021 09:15:27 +0000 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <20210211050533.GA293608@rincewind> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> <20210211050533.GA293608@rincewind> Message-ID: <122DA440-D2C5-4489-B5DC-4C6A6308E234@azul.com> Hi Andrew, Original test fails with : ?javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)? It happens for TLSv protocol version (as defined in the @run section). So, the test is not limited to TLS 1.2 protocol only The test passed with suggested fix. I have reuploaded the jdk.changeset to the same place. Not sure, Why it was truncated before. Regards Alexey > On 11 Feb 2021, at 08:05, Andrew Hughes wrote: > > On 10:00 Wed 10 Feb , Alexey Bakhtin wrote: >> Hi, >> Please review the backport of JDK-8256682 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8256682 >> Original change: https://github.com/openjdk/jdk/commit/b9db002f >> 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/ >> > > There seems to be an issue with this webrev. > > https://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/jdk.changeset just has a header and no body. > >> Original fix does not apply cleanly because of NullHostnameCheck.java test was not updated as part of JDK-8202343 8u backport [1]. This patch includes missed parts of the original fix for JDK-8202343 [2]. >> > > This appears to have been deliberate: > > " * test/sun/security/util/HostnameMatcher/NullHostnameCheck.java > * JDK-8228967 is not in 8u so there is a context conflict while adding > the import. JDK-8228967 also causes a context conflict when adding the > line that re-enables TLS 1.0 and 1.1. However, these changes are not > needed in 8u as the test works for TLS 1.2 only (so there is no need to > re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u, > this test will fail until TLS 1.0 and 1.1 are enabled." [0] > > I must admit it doesn't make sense to me why it would be TLS 1.2 only, > but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it. > > Are you seeing test failures due to the lack of this block? It would > be good to know why we need to revisit the original decision on including > this block. > >> [1] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f2f0ceec19fb >> [2] https://github.com/openjdk/jdk/commit/3a4b90f0 >> >> Regards >> Alexey >> > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013341.html > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 sgehwolf at redhat.com Thu Feb 11 09:39:33 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Feb 2021 10:39:33 +0100 Subject: RFR: 8u backport of JDK-8211301 [macos] support full window content options In-Reply-To: References: Message-ID: Hi Andreas, On Tue, 2021-02-09 at 12:17 +0100, Andreas Ahlenstorf wrote: > Hi! > > The backport adds support for the two properties > > apple.awt.fullWindowContent > apple.awt.transparentTitleBar > > that make the content view extend into the window's title bar on > macOS. The 11u patch didn't apply cleanly to 8u, so I copied it over > manually. I didn't have to make any material changes. > > Original CSR: https://bugs.openjdk.java.net/browse/JDK-8242566 > Backport bug: https://bugs.openjdk.java.net/browse/JDK-8211301 > Webrev:? > https://cr.openjdk.java.net/~sgehwolf/webrevs/aahlenstorf/JDK-8211301/01/webrev/? Only some minor things: src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java 1 /* 2 * Copyright (c) 2011, 2021, Oracle and/or its affiliates. All rights reserved. 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. The JDK 11 patch set the updated year to 2018, not 2021. Please keep 2018. The reason for this is to keep code bases in sync as much as possible. test/java/awt/Window/FullWindowContentTest/FullWindowContentTest.java 2 * Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved. Same with copyrights. JDK 11 patch had 2018 only. Not 2018, 2021. I don't need to see another webrev for these. What kind of testing have you done? Thanks, Severin From aph at redhat.com Thu Feb 11 13:46:53 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Feb 2021 13:46:53 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: Message-ID: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> [Add: jdk8u-dev] On 10/02/2021 16:39, Langer, Christoph wrote: > This is why we think the project should move to git: I have no objection to this, but it's important to reach consensus, which ISO defines as General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments Consensus need not imply unanimity. It's also important not to consider 11 in isolation: while we do not need to move 8 and 11 simultaneously, I very much do not want to see them use different workflows for a long period. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andreas at ahlenstorf.ch Thu Feb 11 15:55:09 2021 From: andreas at ahlenstorf.ch (Andreas Ahlenstorf) Date: Thu, 11 Feb 2021 16:55:09 +0100 Subject: =?UTF-8?Q?Re:_RFR:_8u_backport_of_JDK-8211301_[macos]_support_full_windo?= =?UTF-8?Q?w_content_options?= In-Reply-To: References: Message-ID: <6450b696-c7e6-4929-b071-4ff4658e45c5@www.fastmail.com> Hi Severin, On Thu, Feb 11, 2021, at 10:39, Severin Gehwolf wrote: > The JDK 11 patch set the updated year to 2018, not 2021. Please keep > 2018. The reason for this is to keep code bases in sync as much as > possible. Thanks. Will fix. > What kind of testing have you done? jtreg on jdk/test/java/awt/Window. Best, Andreas From adinn at redhat.com Thu Feb 11 16:46:51 2021 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 11 Feb 2021 16:46:51 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: On 11/02/2021 13:46, Andrew Haley wrote: > It's also important not to consider 11 in isolation: while we do not > need to move 8 and 11 simultaneously, I very much do not want to see > them use different workflows for a long period. I'm also ok with switching jdk11u. I'm not sure jdk8u will be quite so easy to switch as it is made up of multiple hg repos. We can just clone these hg repos into their own separate github repos. However, I'm not sure if the Skara tooling will 'just work' when we try to relate multiple change sets committed to these independent repos to common JIRAs. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Feb 11 17:20:19 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Feb 2021 17:20:19 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> On 11/02/2021 16:46, Andrew Dinn wrote: > On 11/02/2021 13:46, Andrew Haley wrote: > >> It's also important not to consider 11 in isolation: while we do not >> need to move 8 and 11 simultaneously, I very much do not want to see >> them use different workflows for a long period. > I'm also ok with switching jdk11u. > > I'm not sure jdk8u will be quite so easy to switch as it is made up of > multiple hg repos. We can just clone these hg repos into their own > separate github repos. However, I'm not sure if the Skara tooling will > 'just work' when we try to relate multiple change sets committed to > these independent repos to common JIRAs. We can take input from the Skara folk about that. As I understand it, there are already people who have built a monorepo from JDK 8. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Feb 11 17:21:10 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Feb 2021 18:21:10 +0100 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <20210211050533.GA293608@rincewind> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> <20210211050533.GA293608@rincewind> Message-ID: Hi Andrew, On Thu, 2021-02-11 at 05:05 +0000, Andrew Hughes wrote: > On 10:00 Wed 10 Feb???? , Alexey Bakhtin wrote: > > Hi, > > Please review the backport of JDK-8256682 to 8u: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256682 > > Original change: https://github.com/openjdk/jdk/commit/b9db002f > > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/ > > > Original fix does not apply cleanly because of > > NullHostnameCheck.java test was not updated as part of JDK-8202343 > > 8u backport [1]. This patch includes missed parts of the original > > fix for JDK-8202343 [2]. > > > > This appears to have been deliberate: > > " * test/sun/security/util/HostnameMatcher/NullHostnameCheck.java > ? * JDK-8228967 is not in 8u so there is a context conflict while adding > the import. JDK-8228967 also causes a context conflict when adding the > line that re-enables TLS 1.0 and 1.1. However, these changes are not > needed in 8u as the test works for TLS 1.2 only (so there is no need to > re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u, > this test will fail until TLS 1.0 and 1.1 are enabled." [0] Coming back to this, I'm not 100% sure what Martin meant with this. Status quo in 8u-dev is that NullHostnameCheck.java fails for runs with 'TLSv1' and 'TLSv1.1', passes with 'TLSv1.2' and 'TLSv1.3'. I believe it's because this reasoning was *before* JDK-8234728 got backported. With that backported it now also runs for TLSv1, TLSv1.1 and TLSv1.3. > I must admit it doesn't make sense to me why it would be TLS 1.2 only, > but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it. See above. > Are you seeing test failures due to the lack of this block? It would > be good to know why we need to revisit the original decision on > including this block. I can confirm the proposed patch fixes the test. As to the reason, the referenced mailing list thread's argument was prior Martin's decision to backport JDK-8234728[i]. That backport was done rendering this (original) argument wrong. Martin, please correct me if I'm wrong here. This seems good to go. Thanks, Severin [i] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013353.html > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f2f0ceec19fb > [2] https://github.com/openjdk/jdk/commit/3a4b90f0 > > Regards > Alexey > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013341.html Thanks, From sgehwolf at redhat.com Thu Feb 11 18:02:33 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Feb 2021 19:02:33 +0100 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> Message-ID: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> On Thu, 2021-02-11 at 17:20 +0000, Andrew Haley wrote: > On 11/02/2021 16:46, Andrew Dinn wrote: > > On 11/02/2021 13:46, Andrew Haley wrote: > > > > > It's also important not to consider 11 in isolation: while we do not > > > need to move 8 and 11 simultaneously, I very much do not want to see > > > them use different workflows for a long period. > > I'm also ok with switching jdk11u. > > > > I'm not sure jdk8u will be quite so easy to switch as it is made up of > > multiple hg repos. We can just clone these hg repos into their own > > separate github repos. However, I'm not sure if the Skara tooling will > > 'just work' when we try to relate multiple change sets committed to > > these independent repos to common JIRAs. > > We can take input from the Skara folk about that. As I understand > it, there are already people who have built a monorepo from JDK 8. Does Skara help for getting a forest into mono-repo shape? For mainline JDK it was JEP 296 which did it[0]. My understanding is that having a mono-repo is a requirement for a move to git (using skara tooling). If that's true, we'd have to be doing something similar for JDK 8u first. Failing that, we'd have to do a different approach for moving JDK 8u. Also, do we know how well other efforts of getting the mercurial forest into a single git tree fares in terms of preserving history? So while moving JDK 11u over seems doable (already a mono-repo; there is already a git mirror under the openjdk Github namespace[1]), getting JDK 8u done seems significanly different and more risky. With that in mind, should a potential move of 11u to git be (time) dependent on a move of jdk8u to git? I'm not sure... Thanks, Severin [0] https://openjdk.java.net/jeps/296 [1] https://github.com/openjdk/jdk11u https://github.com/openjdk/jdk11u-dev From sgehwolf at redhat.com Thu Feb 11 18:08:45 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 11 Feb 2021 19:08:45 +0100 Subject: RFR: 8u backport of JDK-8211301 [macos] support full window content options In-Reply-To: <6450b696-c7e6-4929-b071-4ff4658e45c5@www.fastmail.com> References: <6450b696-c7e6-4929-b071-4ff4658e45c5@www.fastmail.com> Message-ID: Hi, On Thu, 2021-02-11 at 16:55 +0100, Andreas Ahlenstorf wrote: > Hi Severin, > > On Thu, Feb 11, 2021, at 10:39, Severin Gehwolf wrote: > > > The JDK 11 patch set the updated year to 2018, not 2021. Please keep > > 2018. The reason for this is to keep code bases in sync as much as > > possible. > > Thanks. Will fix. > ? > > What kind of testing have you done? > > jtreg on jdk/test/java/awt/Window. OK thanks, I can sponsor this for you. Cheers, Severin From goetz.lindenmaier at sap.com Thu Feb 11 20:47:33 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 11 Feb 2021 20:47:33 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> Message-ID: Hi, > So while moving JDK 11u over seems doable (already a mono-repo; there > is already a git mirror under the openjdk Github namespace[1]), getting > JDK 8u done seems significanly different and more risky. > > With that in mind, should a potential move of 11u to git be (time) > dependent on a move of jdk8u to git? I'm not sure... I think so too. I don't see strong arguments to tie the two together. Especially I see no argument that holds for tying 8 to 11 that does not hold as well to tie 11 to {17, 15, 13}. As 13 and 15 already are on git, 11 should follow. And 17u will be started in the time frame where we would transition 11u to git (probably in July). Best regards, Goetz. > > Thanks, > Severin > > [0] https://openjdk.java.net/jeps/296 > [1] https://github.com/openjdk/jdk11u > https://github.com/openjdk/jdk11u-dev From hohensee at amazon.com Thu Feb 11 21:49:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Feb 2021 21:49:53 +0000 Subject: hg-updater behavior Message-ID: I just pushed a set of 3 backports to jdk8u-dev/jdk on behalf of David Alvarez. Strangely, even though David created backport JBS issues according to the wiki, hg-updater created new backport issues rather than resolving the existing ones. https://bugs.openjdk.java.net/browse/JDK-8209333 https://bugs.openjdk.java.net/browse/JDK-8240827 https://bugs.openjdk.java.net/browse/JDK-8219991 Anyone else seen this? Thanks, Paul From hohensee at amazon.com Thu Feb 11 21:57:58 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Feb 2021 21:57:58 +0000 Subject: hg-updater behavior In-Reply-To: References: Message-ID: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> Hmm, I think I know what happened. The wiki says "14. Wait for an 8u maintainer to add jdk8u-fix-yes to the bug and set the appropriate Fix Version." The maintainer added jdk8u-fix-yes, but looks to have not set Fix Version to 8u292. And I didn't notice. ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, February 11, 2021 at 1:50 PM To: "jdk8u-dev at openjdk.java.net" Subject: hg-updater behavior I just pushed a set of 3 backports to jdk8u-dev/jdk on behalf of David Alvarez. Strangely, even though David created backport JBS issues according to the wiki, hg-updater created new backport issues rather than resolving the existing ones. https://bugs.openjdk.java.net/browse/JDK-8209333 https://bugs.openjdk.java.net/browse/JDK-8240827 https://bugs.openjdk.java.net/browse/JDK-8219991 Anyone else seen this? Thanks, Paul From hohensee at amazon.com Thu Feb 11 22:23:21 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Feb 2021 22:23:21 +0000 Subject: hg-updater behavior In-Reply-To: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> References: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> Message-ID: <79A498C8-9E2E-42D0-9211-61234C86D27A@amazon.com> Re-resolved hg-updater backport issues as dups of David's, added hg-updater comments to David's, resolved David's with openjdk8u292 as Affected and Fixed Versions. Apologies for the confusion. Paul ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, February 11, 2021 at 1:58 PM To: "jdk8u-dev at openjdk.java.net" Subject: Re: hg-updater behavior Hmm, I think I know what happened. The wiki says "14. Wait for an 8u maintainer to add jdk8u-fix-yes to the bug and set the appropriate Fix Version." The maintainer added jdk8u-fix-yes, but looks to have not set Fix Version to 8u292. And I didn't notice. -----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, February 11, 2021 at 1:50 PM To: "jdk8u-dev at openjdk.java.net" Subject: hg-updater behavior I just pushed a set of 3 backports to jdk8u-dev/jdk on behalf of David Alvarez. Strangely, even though David created backport JBS issues according to the wiki, hg-updater created new backport issues rather than resolving the existing ones. https://bugs.openjdk.java.net/browse/JDK-8209333 https://bugs.openjdk.java.net/browse/JDK-8240827 https://bugs.openjdk.java.net/browse/JDK-8219991 Anyone else seen this? Thanks, Paul From gnu.andrew at redhat.com Fri Feb 12 07:03:30 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 12 Feb 2021 07:03:30 +0000 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <122DA440-D2C5-4489-B5DC-4C6A6308E234@azul.com> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> <20210211050533.GA293608@rincewind> <122DA440-D2C5-4489-B5DC-4C6A6308E234@azul.com> Message-ID: <20210212070330.GA340416@rincewind> On 09:15 Thu 11 Feb , Alexey Bakhtin wrote: > Hi Andrew, > > Original test fails with : > ?javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)? > It happens for TLSv protocol version (as defined in the @run section). So, the test is not limited to TLS 1.2 protocol only > > The test passed with suggested fix. > > I have reuploaded the jdk.changeset to the same place. Not sure, Why it was truncated before. > > Regards > Alexey > Thanks for the clarification. The original reason for excluding that block doesn't make sense to me, so happy to see it go in now. Reuploaded patch looks good. The patch is approved, so feel free to push to 8u-dev. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Fri Feb 12 07:09:48 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 12 Feb 2021 07:09:48 +0000 Subject: hg-updater behavior In-Reply-To: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> References: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> Message-ID: <20210212070948.GB340416@rincewind> On 21:57 Thu 11 Feb , Hohensee, Paul wrote: > Hmm, I think I know what happened. The wiki says > > "14. Wait for an 8u maintainer to add jdk8u-fix-yes to the bug and set the appropriate Fix Version." > > The maintainer added jdk8u-fix-yes, but looks to have not set Fix Version to 8u292. And I didn't notice. > Yes. I was confused when I first looked at the bugs just now, because they did say openjdk8u292. But it seems that was changed afterwards. Severin, please keep an eye on things like this when approving bugs. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Fri Feb 12 07:15:59 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 12 Feb 2021 07:15:59 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: <20210212071559.GC340416@rincewind> On 13:46 Thu 11 Feb , Andrew Haley wrote: > [Add: jdk8u-dev] > > On 10/02/2021 16:39, Langer, Christoph wrote: > > This is why we think the project should move to git: > > I have no objection to this, but it's important to reach consensus, > which ISO defines as > > General agreement, characterized by the absence of sustained opposition > to substantial issues by any important part of the concerned interests > and by a process that involves seeking to take into account the views > of all parties concerned and to reconcile any conflicting arguments > Consensus need not imply unanimity. > > It's also important not to consider 11 in isolation: while we do not > need to move 8 and 11 simultaneously, I very much do not want to see > them use different workflows for a long period. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > I have still not seen any answer to my question of how a bulk update is pushed for the CPU. My own attempts to backport to jdk13u suggest the tooling still needs work on this, or at least better documentation. [0] OpenJDK 16, the first release to use git during development, has not even been released yet. Why the rush? I don't see any reason at all to start altering 8u at such a late stage in its development. All risk and no gain. [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241 -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 christoph.langer at sap.com Fri Feb 12 08:38:01 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Feb 2021 08:38:01 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <20210212071559.GC340416@rincewind> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> Message-ID: Hi Andrew, you have valid concerns which I hope we can get sorted out until the proposed 11u switch. Let me answer in detail: > I have still not seen any answer to my question of how a bulk update is > pushed for the CPU. I think generally this is kind of answered. For the 11u <-> 11u-dev merges we can use a facility called "Merge PR", something like people used to merge jdk16 back into jdk [0]. Although I've not yet done it myself and will need to talk to Skara folks to get it explained better, I think this is what we can use. For working on the CPU I hope to be able to use "git bundle" to distribute the state of work on vuln-dev (Similar to what we do with hg bundle now) and eventually push the release via a Merge PR. I will explore this in detail in the next weeks and see if it's bound to work. In case I don't see it working, I'd consider it a showstopper. So I'll update you on this soon, in time before the advised github switch. > My own attempts to backport to jdk13u suggest the tooling still needs > work on this, or at least better documentation. [0] I think you have a point here. As far as I know the "git backport" command does not exist yet and also the process to backport a change by commenting "/backport" on the original change in the jdk repository is not activated yet. I've brought this up to the skara team and they said that they hope to be able to enable it soon [1]. At the moment a backport would work like documented in the manual steps of this link [2] - which is not too convenient. I'll approach Skara folks again about that. > OpenJDK 16, the first release to use git during development, has not > even been released yet. Why the rush? Well, I would not consider it to be in a rush, given the proposal of switching in about 4 months from now. But overall, to align processes, to me it seems favorable to go to git with 11u and we should not overly delay it. At that time JDK16 and its first update release 16.0.1 will have been delivered out of git (as well as a few jdk13u update releases). > I don't see any reason at all to start altering 8u at such a late > stage in its development. All risk and no gain. That's a different discussion which I won't take part in as I'm not involved so much in 8u. The only point I have on that is that there's no reason to couple the decisions for 8 and 11, as was stated by Severin and Goetz already. Best regards Christoph [0] https://github.com/openjdk/jdk/pull/2392 [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-January/004051.html [2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI From aph at redhat.com Fri Feb 12 09:45:24 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2021 09:45:24 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> Message-ID: On 11/02/2021 18:02, Severin Gehwolf wrote: > On Thu, 2021-02-11 at 17:20 +0000, Andrew Haley wrote: >> On 11/02/2021 16:46, Andrew Dinn wrote: >>> On 11/02/2021 13:46, Andrew Haley wrote: >>> >>>> It's also important not to consider 11 in isolation: while we do not >>>> need to move 8 and 11 simultaneously, I very much do not want to see >>>> them use different workflows for a long period. >>> I'm also ok with switching jdk11u. >>> >>> I'm not sure jdk8u will be quite so easy to switch as it is made up of >>> multiple hg repos. We can just clone these hg repos into their own >>> separate github repos. However, I'm not sure if the Skara tool: ing will >>> 'just work' when we try to relate multiple change sets committed to >>> these independent repos to common JIRAs. >> >> We can take input from the Skara folk about that. As I understand >> it, there are already people who have built a monorepo from JDK 8. > > Does Skara help for getting a forest into mono-repo shape? For mainline > JDK it was JEP 296 which did it[0]. My understanding is that having a > mono-repo is a requirement for a move to git (using skara tooling). If > that's true, we'd have to be doing something similar for JDK 8u first. > Failing that, we'd have to do a different approach for moving JDK 8u. What problems do you forsee? Nothing would be moved or altered, except perhaps to delete get_source.sh, but even that isn't essential. Have a look at https://github.com/AdoptOpenJDK/openjdk-jdk8u. > Also, do we know how well other efforts of getting the mercurial forest > into a single git tree fares in terms of preserving history? IMO that one isn't a show stopper, given that the old Hg stuff still exists. > So while moving JDK 11u over seems doable (already a mono-repo; there > is already a git mirror under the openjdk Github namespace[1]), getting > JDK 8u done seems significanly different and more risky. > > With that in mind, should a potential move of 11u to git be (time) > dependent on a move of jdk8u to git? I'm not sure... Certainly not. I do not propose to make 11 wait for 8; but neither do I want 8 to languish in a dusty corner. Mind you, there would be one advantage: the more difficult it is to contribute to 8u, the less churn there would be. Hmm, (half joking) maybe we should leave 8 on Hg to stop people from changing it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri Feb 12 10:07:40 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Feb 2021 11:07:40 +0100 Subject: hg-updater behavior In-Reply-To: <20210212070948.GB340416@rincewind> References: <2E26B4C9-BB04-4CFD-9370-BD73CA8ACFC2@amazon.com> <20210212070948.GB340416@rincewind> Message-ID: <6634e0d52a942cf1328971d75ddfa4f1f7954b59.camel@redhat.com> On Fri, 2021-02-12 at 07:09 +0000, Andrew Hughes wrote: > On 21:57 Thu 11 Feb???? , Hohensee, Paul wrote: > > Hmm, I think I know what happened. The wiki says > > > > "14. Wait for an 8u maintainer to add jdk8u-fix-yes to the bug and > > set the appropriate Fix Version." > > > > The maintainer added jdk8u-fix-yes, but looks to have not set Fix > > Version to 8u292. And I didn't notice. > > > > Yes. I was confused when I first looked at the bugs just now, because > they did say openjdk8u292. > But it seems that was changed afterwards. > > Severin, please keep an eye on things like this when approving bugs. Yes, sorry my bad. I usually do, but forgot in these instances :-/ Thanks, Severin From hohensee at amazon.com Fri Feb 12 14:54:10 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Feb 2021 14:54:10 +0000 Subject: hg-updater behavior Message-ID: <87077082-D2CA-49E3-9034-BA2DB5D1D2BD@amazon.com> Np. All fixed. :) ?-----Original Message----- From: Severin Gehwolf Date: Friday, February 12, 2021 at 2:08 AM To: Andrew Hughes , "Hohensee, Paul" Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: hg-updater behavior On Fri, 2021-02-12 at 07:09 +0000, Andrew Hughes wrote: > On 21:57 Thu 11 Feb , Hohensee, Paul wrote: > > Hmm, I think I know what happened. The wiki says > > > > "14. Wait for an 8u maintainer to add jdk8u-fix-yes to the bug and > > set the appropriate Fix Version." > > > > The maintainer added jdk8u-fix-yes, but looks to have not set Fix > > Version to 8u292. And I didn't notice. > > > > Yes. I was confused when I first looked at the bugs just now, because > they did say openjdk8u292. > But it seems that was changed afterwards. > > Severin, please keep an eye on things like this when approving bugs. Yes, sorry my bad. I usually do, but forgot in these instances :-/ Thanks, Severin From sgehwolf at redhat.com Fri Feb 12 16:37:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Feb 2021 17:37:49 +0100 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> Message-ID: On Fri, 2021-02-12 at 09:45 +0000, Andrew Haley wrote: > On 11/02/2021 18:02, Severin Gehwolf wrote: > > Does Skara help for getting a forest into mono-repo shape? For mainline > > JDK it was JEP 296 which did it[0]. My understanding is that having a > > mono-repo is a requirement for a move to git (using skara tooling). If > > that's true, we'd have to be doing something similar for JDK 8u first. > > Failing that, we'd have to do a different approach for moving JDK 8u. > > What problems do you forsee? Nothing would be moved or altered, except > perhaps to delete get_source.sh, but even that isn't essential. > > Have a look at https://github.com/AdoptOpenJDK/openjdk-jdk8u. Good question. My worry is that we get some detail wrong and discover it after the switch, when it's too late to change. Some food for thought: - Timestamps should match (they don't seem to match the original commits in the above repo) - What are the requirements to get a verified tree up in the openjdk namespace? Does it need to pass jcheck for every commit? Do we need to relax jcheck/verification for the initial population of the repository? - No extra tags (there seem to be some extra tags in the repo above). - Is there proper tag-for-tag alignment? Checking out jdk8u282-b08 from HG should produce the same sources than checking out jdk8u282-b08 from monorepo/git. - What updates would be required for JBS integration? Is that taken care of by Skara? Most of these things seem to be solved with the JEP 296 scripts. The rest would be solved by skara tooling once there is a monorepo (I think). At least that's my understanding. > > Also, do we know how well other efforts of getting the mercurial forest > > into a single git tree fares in terms of preserving history? > > IMO that one isn't a show stopper, given that the old Hg stuff still > exists. Well, to clarify, there is no way we are going to be able to preserve commit hashes in this conversion. But we at least need accurate enough history which matches the HG forest history with expected differences (like cross repo changes for the same bug having multiple commits). The requirement for me would be that the history goes all the way back to its inception and would be self-sufficient (no extra HG clone needed). > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some more thought than 11u. My preference would be to do it in steps: 1.) HG forest -> monorepo conversion (using JEP 296 scripts) 2.) HG -> git conversion using Skara tooling (should take care of proper metadata, etc.) Thanks, Severin From adinn at redhat.com Fri Feb 12 17:39:39 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 12 Feb 2021 17:39:39 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> Message-ID: <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> On 12/02/2021 16:37, Severin Gehwolf wrote: > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > more thought than 11u. That's what I was thinking. > My preference would be to do it in steps: > 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > 2.) HG -> git conversion using Skara tooling (should take care of > proper metadata, etc.) Yes, I think this is the right way to go about it. If nothing else because the tools for the second step assumed that the first one had happened. The really tricky differences I see happen at step 1 (although they might have a knock-on effect at step 2) JEP 296 had to relocate all the java code into modules JEP 296 did not have to retain (and therefore relocate) all of the java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) I don't suppose these differences would be impossible to sort out but I think they would require some effort. regards, Andrew Dinn ----------- From mbalao at redhat.com Fri Feb 12 18:32:00 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 12 Feb 2021 15:32:00 -0300 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> <20210211050533.GA293608@rincewind> Message-ID: <09d41c9e-4d2d-ca3e-bf2f-154267ad67a9@redhat.com> On 2/11/21 2:21 PM, Severin Gehwolf wrote: > > Coming back to this, I'm not 100% sure what Martin meant with this. > Status quo in 8u-dev is that NullHostnameCheck.java fails for runs with > 'TLSv1' and 'TLSv1.1', passes with 'TLSv1.2' and 'TLSv1.3'. > > I believe it's because this reasoning was *before* JDK-8234728 got > backported. With that backported it now also runs for TLSv1, TLSv1.1 > and TLSv1.3. > Yes, that's the reason: the comment was previous to decide backporting JDK-8234728 to 8u. >> I must admit it doesn't make sense to me why it would be TLS 1.2 only, >> but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it. > > See above. > >> Are you seeing test failures due to the lack of this block? It would >> be good to know why we need to revisit the original decision on >> including this block. > > I can confirm the proposed patch fixes the test. As to the reason, the > referenced mailing list thread's argument was prior Martin's decision > to backport JDK-8234728[i]. That backport was done rendering this > (original) argument wrong. Martin, please correct me if I'm wrong here. > You are right. The proposed backport looks good to me. Thanks, Martin.- From aph at redhat.com Fri Feb 12 18:52:06 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Feb 2021 18:52:06 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <20210212071559.GC340416@rincewind> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> Message-ID: <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com> On 12/02/2021 07:15, Andrew Hughes wrote: > even been released yet. Why the rush? > > I don't see any reason at all to start altering 8u at such a late > stage in its development. All risk and no gain. > > [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241 We've always been a bit short of boots on the ground, and being stuck on an obsolete VCS will only isolate 8u even more. Maybe this is an optimist-versus-pessimist thing, but 8u may be about halfway through its lifetime! -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alexey at azul.com Fri Feb 12 19:01:47 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 12 Feb 2021 19:01:47 +0000 Subject: [8u] RFR: 8256682: JDK-8202343 is incomplete In-Reply-To: <09d41c9e-4d2d-ca3e-bf2f-154267ad67a9@redhat.com> References: <4FA20D44-9D61-4FEE-B74A-A328864B3183@azul.com> <20210211050533.GA293608@rincewind> <09d41c9e-4d2d-ca3e-bf2f-154267ad67a9@redhat.com> Message-ID: Andrew, Severin, Martin, Thank you for review. Alexey > On 12 Feb 2021, at 21:32, Martin Balao wrote: > > On 2/11/21 2:21 PM, Severin Gehwolf wrote: >> >> Coming back to this, I'm not 100% sure what Martin meant with this. >> Status quo in 8u-dev is that NullHostnameCheck.java fails for runs with >> 'TLSv1' and 'TLSv1.1', passes with 'TLSv1.2' and 'TLSv1.3'. >> >> I believe it's because this reasoning was *before* JDK-8234728 got >> backported. With that backported it now also runs for TLSv1, TLSv1.1 >> and TLSv1.3. >> > > Yes, that's the reason: the comment was previous to decide backporting > JDK-8234728 to 8u. > >>> I must admit it doesn't make sense to me why it would be TLS 1.2 only, >>> but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it. >> >> See above. >> >>> Are you seeing test failures due to the lack of this block? It would >>> be good to know why we need to revisit the original decision on >>> including this block. >> >> I can confirm the proposed patch fixes the test. As to the reason, the >> referenced mailing list thread's argument was prior Martin's decision >> to backport JDK-8234728[i]. That backport was done rendering this >> (original) argument wrong. Martin, please correct me if I'm wrong here. >> > > You are right. > > The proposed backport looks good to me. > > Thanks, > Martin.- From volker.simonis at gmail.com Fri Feb 12 21:33:47 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Feb 2021 22:33:47 +0100 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> Message-ID: On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: > > On 12/02/2021 16:37, Severin Gehwolf wrote: > > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > > more thought than 11u. > > That's what I was thinking. > > > My preference would be to do it in steps: > > 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > > 2.) HG -> git conversion using Skara tooling (should take care of > > proper metadata, etc.) > Yes, I think this is the right way to go about it. If nothing else > because the tools for the second step assumed that the first one had > happened. > > The really tricky differences I see happen at step 1 (although they > might have a knock-on effect at step 2) > I think converting 8u to a Git mono-repo might not be as complicated and risky as it seems. We have to remember that most of the work has already been done by JEP 296 in jdk10. That process already converted all the old history and as nobody seems to have been complaining about it in jdk10 and later, that conversion must have been fine. I.e. The jdk 10 repository naturally contains the sources of jdk8 from which is was initially forked (I think at jdk8-b120). So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 This will give us a mono-repo at the stage of jdk8-b120. Afterwards, we only have to use the JEP 296 scripts or something equivalent (I hope that the Oracle build group can assist or at least give some good advice here :) >From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created with the above command, it looks like the "JEP 296" script worked as follows: - let's assume were at a changeset which merges all the subrepos at a specific build tag "jdk8-bXX" (builds were usually tagged weekly, so every jdk8-bXX tag corresponds to a weekly version). - sequentially transplant all the changes from a single subrepo up until the next tag "jdk8-bXX+1" into the new repo - do this sequentially for all the other sub-repositories - create a merge change in the new mono-repo which merges all the newly transplanted changes and tag it with "jdk8-bXX+1" - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are bit-wise equal to the sources of the jdk8u forest when every single repo is synced to the same tag. - repeat the procedure for all the other jdk8-bXX tags We can probably take the above jdk11u-dev-jdk8-b120 repo and follow the described procedure for all the additional changes between jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. Needless to say that the Corretto team is fully supporting the transition of jdk8u from a Mercurial forest to a Git mono-repo and will be happy to get involved into the process :) Best regards, Volker > JEP 296 had to relocate all the java code into modules > JEP 296 did not have to retain (and therefore relocate) all of the > java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) > > I don't suppose these differences would be impossible to sort out but I > think they would require some effort. > > regards, > > > Andrew Dinn > ----------- > From gnu.andrew at redhat.com Mon Feb 15 07:21:40 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Feb 2021 07:21:40 +0000 Subject: RFR: 8159690: [TESTBUG] Mark headful tests with @key headful. In-Reply-To: <4EF1301E-BE0E-4D02-A4F2-4C12FC33E29B@amazon.com> References: <4EF1301E-BE0E-4D02-A4F2-4C12FC33E29B@amazon.com> Message-ID: <20210215072140.GC494770@rincewind> On 20:43 Thu 12 Nov , Hohensee, Paul wrote: > Please review this backport, which is part of the patch tail for https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3077. > > This is a replacement patch for the one for which a review was requested in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/012922.html. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8159690 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/980da45565c8 > 3077 patch: http://icedtea.classpath.org//hg/icedtea8-forest/jdk?cmd=changeset;node=dcd850780adc > Webrev: http://cr.openjdk.java.net/~phh/8159690/webrev.8u.jdk.00/ > > As noted in a comment on the JBS issue, there are 45 tests that were in the original patch that are not in the 3077 patch because they are not present in 8u. Three more are also not in 8u but are in the 3077 patch. Other than those 3, the webrev patch is identical to the 3077 patch. > > The patch is not clean with respect to both the original and 3077 patches because the 48 tests are omitted, and because of various context and copyright date differences. The only substantive change is the addition of @headful, which doesn?t affect running any of the tests. > > Thanks, > Paul > > Looking at the omitted tests: * test/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java Introduced by JDK-8136858, "Examine the usage of ThreadGroup.stop() in sun.awt.AppContext". This is due to another change, JDK-7067728, which changed the security policy so omission seems correct. * test/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html Introduced by JDK-7112454, "TEST_BUG: java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html failed". This is just a test case addition so not sure why it is omitted? Could be a quick clean backport. * test/java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.html Introduced by JDK-8014725: "closed/java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.html failed intermittently" Bug inaccessible and changes AWT code so I agree with omitting this. * test/java/awt/Cursor/GetSystemCustomCursor/GetSystemCustomCursor.java >From JDK-8039269: images/cursors should not be in ${java.home}/lib, which changes cursor handling so agree with omission. * test/java/awt/Debug/DumpOnKey/DumpOnKey.java >From JDK-4379403: "Need to disable the "magic AWT dump key" (CTRL+SHIFT+F1)" which changes AWT code. Agree with the omission. * test/java/awt/EventDispatchThread/PropertyPermissionOnEDT/PropertyPermissionOnEDT.java >From JDK-8080405: "Exception in thread "AWT-EventQueue-1" java.security.AccessControlException" which makes major threading changes. Agree with omission. * test/java/awt/FileDialog/ModalFocus/FileDialogModalFocusTest.java >From JDK-8025815: "Child FileDialog of modal dialog does not get focus on Gnome" which fixes an obscure corner case, altering AWT code. Agree with omission. * test/java/awt/Focus/Cause/FocusCauseTest.java >From JDK-8080395: "consider making sun.awt.CausedFocusEvent functionality public", a major AWT change which shouldn't be backported. Agree with omission. * test/java/awt/Focus/FocusTraversalPolicy/ContainerOrderFTPTest.java >From JDK-8025001: "setFocusTraversalPolicy() to ContainerOrderFocusTraversalPolicy results in an infinite loop". This could be a potential backport, but seems a bit risky at this late stage. Agree with omission. * java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java This file is present in 8u. Seems to have been missed. It was introduced in 8u along with JDK-8167110. * test/java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java Introduced for a MacOS X bug, JDK-8065739: "Frame warps to lower left of screen when displayed". As 8u doesn't currently build on Mac OS, seems risky to be introducing changes to its AWT code. Ok with omission. * test/java/awt/Frame/NonEDT_GUI_DeadlockTest/NonEDT_GUI_Deadlock.html Ok, this is a fun one. It comes in with the change JDK-8130125: "[TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update" though it has nothing to do with the module addition, because three closed tests were opened up and piggybacked onto that change [0]. I have a backport of this change without the module additions and will propose it as a pre-requisite for this patch. * test/java/awt/FullScreen/NonExistentDisplayModeTest/NonExistentDisplayModeTest.java This is from JDK-7185221: "[macosx] Regtest should not throw exception if a suitable display mode found" which opens up that test. Should be backported first. * test/java/awt/Graphics/CopyScaledArea/CopyScaledAreaTest.java This is from JDK-8069348: "SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D". Platform-specific changes which seem risky to backport. Agree with omission. * test/java/awt/List/ActionEventTest/ActionEventTest.java This is from JDK-6191390: "Action Event triggered by list does not reflect the modifiers properly on win32". Windows-specific issue which changes AWT behaviour. Agree with omission. * test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html This is from JDK-8136592: "[TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw" which opens up the test. I think this could be included. * test/java/awt/List/ItemEventTest/ItemEventTest.java This is from JDK-8033936: "java.awt.List events are not sent properly to handleEvent or ItemListener", which is a one-line Windows fix with test. I think this could be included. * test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java This is from JDK-8143054: "[macosx] KeyEvent modifiers do not contain information about mouse buttons", a MacOS behavioural fix. Ok with omission. * test/java/awt/Mouse/MouseWheelAbsXY/MouseWheelAbsXY.java This is from JDK-6778087: "getLocationOnScreen() always returns (0, 0) for mouse wheel events" which is a fairly simple fix to retrieve the missing values rather than hardcoding 0, 0. I think this could be included. * test/java/awt/MouseInfo/GetPointerInfoTest.java This file is present in 8u. Seems to have been missed. It was introduced in JDK-8035568. * test/java/awt/MouseInfo/MultiscreenPointerInfo.java Also in 8u as part of JDK-8035568. * test/java/awt/MouseInfo/PointerInfoCrashTest.java This is from JDK-8143316: "Crash Trend in 1.9.0-ea-b93 (sun.awt.DefaultMouseInfoPeer.fillPointWithCoords)" Windows-specific change with a private bug. Ok to omit. * test/java/awt/Paint/ComponentIsNotDrawnAfterRemoveAddTest/ComponentIsNotDrawnAfterRemoveAddTest.java Present in 8u from JDK-8139581: "AWT components are not drawn after removal and addition to a container" (8u102) so should be added. * test/java/awt/Robot/RobotWheelTest/RobotWheelTest.java Test opened up in JDK-8079255: "[TEST_BUG] [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only" with no code changes so could be included. * test/java/awt/TextArea/TextAreaScrolling/TextAreaScrolling.java >From JDK-6180449: "PIT: Text in TextArea scrolls to its left one char when selecting the text from the end". Removes part of a Windows code fix with no clear explanation of why. Test is then problematic on other platforms (JDK-8160764) Ok to omit. * test/java/awt/TextField/EOLTest/EOLTest.java >From JDK-8055197: "TextField deletes multiline strings". Significant behavioural change so ok to omit. * test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java >From JDK-8144074: "[PIT] Crash calling Toolkit.getScreenSize() on Windows". Windows fix which avoids a crash. Cause of crash seems to be JDK-8073320 which is not in 8u, but seems a worthwhile defensive addition. * test/java/awt/Window/FindOwner/FindOwnerTest.html >From JDK-8139227: "Text fields in JPopupMenu structure do not receive focus in hosted Applets". Behaviour change for applets on Windows. Ok to omit. * test/java/awt/Window/MultiWindowApp/MultiWindowAppTest.java >From JDK-8022334: "After calling frame.toBack() dialog goes to the back on Ubuntu 12.04" Changes result of WMClass() for XWindow. Seems safest to omit. * test/java/awt/Window/ScreenLocation/ScreenLocationTest.java >From JDK-8011616: "JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity" Behavioural change so seems safest to omit. * test/java/awt/applet/Applet/AppletFlipBuffer.java >From JDK-8130390: "Applet fails to launch on virtual desktop" Behavioural change so seems safest to omit. * test/java/awt/datatransfer/ConstructFlavoredObjectTest/ConstructFlavoredObjectTest.java >From JDK-8142968: "Module System implementation" so fine to omit. * test/java/awt/datatransfer/CustomClassLoaderTransferTest/CustomClassLoaderTransferTest.java >From JDK-8041464: "[TEST_BUG] CustomClassLoaderTransferTest does not support OS X" which actually seems to open up this test so could be included. * test/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java Also from JDK-8142968, so fine to omit. * test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html Should now be included as you backported JDK-8046221 :-) * test/java/awt/dnd/Button2DragTest/Button2DragTest.java Backporting the test cleanup JDK-7124381: "DragSourceListener.dragDropEnd() never been called on completion of dnd operation" might be worthwhile. * test/java/awt/font/Underline/UnderlineTest.java See comment above about JDK-8130125; it strikes again. * test/java/awt/hidpi/properties/HiDPIPropertiesUnixTest.java >From JDK-8150844: "[hidpi] [macosx] -Dsun.java2d.uiScale should be taken into account for OS X". Relies on HiDPI changes which aren't generally in 8u so ok to omit. * test/java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java Seems to be missing a copyright header update. * test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java Present in 8u (JDK-8029253) but seems to have been missed. * test/java/awt/image/DrawImage/ScaledImageAlphaTest.java >From JDK-8139183: "drawImage misses background's alpha channel". Behaviour change that seems a little risky to backport. * test/java/awt/image/VolatileImage/BitmaskVolatileImage.java Major change in JDK-7188942: "Remove support of pbuffers in OGL Java2d pipeline", a closed bug. Ok to omit. * test/java/awt/image/VolatileImage/VolatileImageBug.java Now present in 8u thanks to JDK-8159495: "Fix index offsets" * test/java/awt/image/multiresolution/MultiresolutionIconTest.java >From JDK-8150724: "[TEST] HiDPI: create a test for multiresolution icons", can be included. * test/java/awt/print/PageFormat/NullPaper.java Now present in 8u as of 8u292-b01 and JDK-8038723. * test/java/awt/print/PageFormat/ReverseLandscapeTest.java Likewise introduced by JDK-8038723. * test/java/awt/security/WarningWindowDisposeTest/WarningWindowDisposeCrashTest.java Introduced by JDK-8041490: "PIT: [macosx] Crash in system tray functionality check test" which fixes a crash. Seems like a good check to backport. * test/javax/swing/SwingUtilities/8049533/bug8049533.java >From JDK-8049533: "SwingUtilities.convertMouseEvent misses MouseWheelEvent.preciseWheelRotation" Behaviour change it is safest to omit. * test/sun/java2d/OpenGL/CopyAreaOOB.java JDK-7131835: "[TEST_BUG] Test does not consider that the rounded edges of the window in Mac OS 10.7" opens up this test which can be included. * test/sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java JDK-6345095: "regression test EmptyClipRenderingTest fails" opens up this test which could be included. * test/sun/java2d/SunGraphics2D/SurfaceDestination/SurfaceDestination.java >From JDK-8134603: "Incorrect destination is used in CGLLayer surface", Mac OS X behaviour change probably safest to omit. Summary: * JDK-7112454, JDK-7185221, JDK-8136592, JDK-8079255, JDK-8041464, JDK-8150724, JDK-7131835, JDK-6345095 All introduce missing tests in isolation and could be easily backported (possibly clean, may need removal of @modules lines) * JDK-8033936, JDK-6778087, JDK-8073320 & JDK-8041490 are trivial backports it would be good to fix The first two add missing information. The second two protect against crashes. * I'll propose my existing backport of JDK-8130125 tomorrow, which adds a couple of missing tests. * Optional: JDK-7124381. * Update patch with: - test/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html (JDK-7112454) - java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java (missed) - test/java/awt/Frame/NonEDT_GUI_DeadlockTest/NonEDT_GUI_Deadlock.html (JDK-8130125) - test/java/awt/FullScreen/NonExistentDisplayModeTest/NonExistentDisplayModeTest.java (JDK-7185221) - test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html (JDK-8136592) - test/java/awt/List/ItemEventTest/ItemEventTest.java (JDK-8033936) - test/java/awt/Mouse/MouseWheelAbsXY/MouseWheelAbsXY.java (JDK-6778087) - test/java/awt/MouseInfo/GetPointerInfoTest.java (missed) - test/java/awt/MouseInfo/MultiscreenPointerInfo.java (missed) - test/java/awt/Paint/ComponentIsNotDrawnAfterRemoveAddTest/ComponentIsNotDrawnAfterRemoveAddTest.java (missed) - test/java/awt/Robot/RobotWheelTest/RobotWheelTest.java (JDK-8079255) - test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java (JDK-8073320) - test/java/awt/datatransfer/CustomClassLoaderTransferTest/CustomClassLoaderTransferTest.java (JDK-8041464) - test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html (missed) - test/java/awt/font/Underline/UnderlineTest.java (JDK-8130125) - test/java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java (missing copyright header update) - test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java (missed) - test/java/awt/image/VolatileImage/VolatileImageBug.java (missed) - test/java/awt/image/multiresolution/MultiresolutionIconTest.java (JDK-8150724) - test/java/awt/print/PageFormat/NullPaper.java (recently introduced) - test/java/awt/print/PageFormat/ReverseLandscapeTest.java (recently introduced) - test/java/awt/security/WarningWindowDisposeTest/WarningWindowDisposeCrashTest.java (JDK-8041490) - test/sun/java2d/OpenGL/CopyAreaOOB.java (JDK-7131835) - test/sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java (JDK-6345095) [0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 serge.chernyshev at bell-sw.com Mon Feb 15 11:07:18 2021 From: serge.chernyshev at bell-sw.com (Sergey Chernyshev) Date: Mon, 15 Feb 2021 14:07:18 +0300 Subject: [8u] RFR 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS Message-ID: Hello, I'd like to propose an 8u backport of JDK-8260349. Original bug: https://bugs.openjdk.java.net/browse/JDK-8260349 Original patch: https://git.openjdk.java.net/jdk/commit/b6a73673 8u webrev: http://cr.openjdk.java.net/~alexsch/sercher/8260349.8u/webrev.00/ The patch doesn't apply cleanly. The following changes were made - updated copyright text in memoryPool.cpp. - source paths unshuffled In the newly added test source (MaxMetaspaceSizeEnvVarTest.java), compared to 11u backported version [1]: - updated imported package names of ProcessTools, OutputAnalyzer - removed JDK_JAVA_OPTIONS env variable which is @since 9 - .orElseThrow() is @since 10, replaced with .orElseThrow(exceptionSupplier) - added import java.util.NoSuchElementException as required by .orElseThrow() The test passes with the patch and fails otherwise. Run :hotspot tests, no regressions observed. Thanks, Sergey [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/5c8adc05d277 -- Best regards, Sergey Chernyshev Bellsoft LLC From sgehwolf at redhat.com Mon Feb 15 16:48:44 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 15 Feb 2021 17:48:44 +0100 Subject: [8u] RFR 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS In-Reply-To: References: Message-ID: <7e3144e37e5a4a8d051f64cc53c5a83b0547eacc.camel@redhat.com> On Mon, 2021-02-15 at 14:07 +0300, Sergey Chernyshev wrote: > 8u webrev: > http://cr.openjdk.java.net/~alexsch/sercher/8260349.8u/webrev.00/ This looks fine to me. Thanks, Severin From hohensee at amazon.com Mon Feb 15 17:08:04 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Feb 2021 17:08:04 +0000 Subject: RFR: 8159690: [TESTBUG] Mark headful tests with @key headful. Message-ID: <770D279F-477A-4DB5-81EA-765FC3364E03@amazon.com> Will do. Thanks for the thorough review! Paul ?-----Original Message----- From: Andrew Hughes Date: Sunday, February 14, 2021 at 11:22 PM To: "Hohensee, Paul" Cc: jdk8u-dev Subject: RE: RFR: 8159690: [TESTBUG] Mark headful tests with @key headful. On 20:43 Thu 12 Nov , Hohensee, Paul wrote: > Please review this backport, which is part of the patch tail for https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3077. > > This is a replacement patch for the one for which a review was requested in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/012922.html. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8159690 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/980da45565c8 > 3077 patch: http://icedtea.classpath.org//hg/icedtea8-forest/jdk?cmd=changeset;node=dcd850780adc > Webrev: http://cr.openjdk.java.net/~phh/8159690/webrev.8u.jdk.00/ > > As noted in a comment on the JBS issue, there are 45 tests that were in the original patch that are not in the 3077 patch because they are not present in 8u. Three more are also not in 8u but are in the 3077 patch. Other than those 3, the webrev patch is identical to the 3077 patch. > > The patch is not clean with respect to both the original and 3077 patches because the 48 tests are omitted, and because of various context and copyright date differences. The only substantive change is the addition of @headful, which doesn?t affect running any of the tests. > > Thanks, > Paul > > Looking at the omitted tests: * test/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java Introduced by JDK-8136858, "Examine the usage of ThreadGroup.stop() in sun.awt.AppContext". This is due to another change, JDK-7067728, which changed the security policy so omission seems correct. * test/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html Introduced by JDK-7112454, "TEST_BUG: java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html failed". This is just a test case addition so not sure why it is omitted? Could be a quick clean backport. * test/java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.html Introduced by JDK-8014725: "closed/java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.html failed intermittently" Bug inaccessible and changes AWT code so I agree with omitting this. * test/java/awt/Cursor/GetSystemCustomCursor/GetSystemCustomCursor.java From JDK-8039269: images/cursors should not be in ${java.home}/lib, which changes cursor handling so agree with omission. * test/java/awt/Debug/DumpOnKey/DumpOnKey.java From JDK-4379403: "Need to disable the "magic AWT dump key" (CTRL+SHIFT+F1)" which changes AWT code. Agree with the omission. * test/java/awt/EventDispatchThread/PropertyPermissionOnEDT/PropertyPermissionOnEDT.java From JDK-8080405: "Exception in thread "AWT-EventQueue-1" java.security.AccessControlException" which makes major threading changes. Agree with omission. * test/java/awt/FileDialog/ModalFocus/FileDialogModalFocusTest.java From JDK-8025815: "Child FileDialog of modal dialog does not get focus on Gnome" which fixes an obscure corner case, altering AWT code. Agree with omission. * test/java/awt/Focus/Cause/FocusCauseTest.java From JDK-8080395: "consider making sun.awt.CausedFocusEvent functionality public", a major AWT change which shouldn't be backported. Agree with omission. * test/java/awt/Focus/FocusTraversalPolicy/ContainerOrderFTPTest.java From JDK-8025001: "setFocusTraversalPolicy() to ContainerOrderFocusTraversalPolicy results in an infinite loop". This could be a potential backport, but seems a bit risky at this late stage. Agree with omission. * java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java This file is present in 8u. Seems to have been missed. It was introduced in 8u along with JDK-8167110. * test/java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java Introduced for a MacOS X bug, JDK-8065739: "Frame warps to lower left of screen when displayed". As 8u doesn't currently build on Mac OS, seems risky to be introducing changes to its AWT code. Ok with omission. * test/java/awt/Frame/NonEDT_GUI_DeadlockTest/NonEDT_GUI_Deadlock.html Ok, this is a fun one. It comes in with the change JDK-8130125: "[TEST_BUG] add @modules to the several client tests unaffected by the automated bulk update" though it has nothing to do with the module addition, because three closed tests were opened up and piggybacked onto that change [0]. I have a backport of this change without the module additions and will propose it as a pre-requisite for this patch. * test/java/awt/FullScreen/NonExistentDisplayModeTest/NonExistentDisplayModeTest.java This is from JDK-7185221: "[macosx] Regtest should not throw exception if a suitable display mode found" which opens up that test. Should be backported first. * test/java/awt/Graphics/CopyScaledArea/CopyScaledAreaTest.java This is from JDK-8069348: "SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D". Platform-specific changes which seem risky to backport. Agree with omission. * test/java/awt/List/ActionEventTest/ActionEventTest.java This is from JDK-6191390: "Action Event triggered by list does not reflect the modifiers properly on win32". Windows-specific issue which changes AWT behaviour. Agree with omission. * test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html This is from JDK-8136592: "[TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw" which opens up the test. I think this could be included. * test/java/awt/List/ItemEventTest/ItemEventTest.java This is from JDK-8033936: "java.awt.List events are not sent properly to handleEvent or ItemListener", which is a one-line Windows fix with test. I think this could be included. * test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersInKeyEvent.java This is from JDK-8143054: "[macosx] KeyEvent modifiers do not contain information about mouse buttons", a MacOS behavioural fix. Ok with omission. * test/java/awt/Mouse/MouseWheelAbsXY/MouseWheelAbsXY.java This is from JDK-6778087: "getLocationOnScreen() always returns (0, 0) for mouse wheel events" which is a fairly simple fix to retrieve the missing values rather than hardcoding 0, 0. I think this could be included. * test/java/awt/MouseInfo/GetPointerInfoTest.java This file is present in 8u. Seems to have been missed. It was introduced in JDK-8035568. * test/java/awt/MouseInfo/MultiscreenPointerInfo.java Also in 8u as part of JDK-8035568. * test/java/awt/MouseInfo/PointerInfoCrashTest.java This is from JDK-8143316: "Crash Trend in 1.9.0-ea-b93 (sun.awt.DefaultMouseInfoPeer.fillPointWithCoords)" Windows-specific change with a private bug. Ok to omit. * test/java/awt/Paint/ComponentIsNotDrawnAfterRemoveAddTest/ComponentIsNotDrawnAfterRemoveAddTest.java Present in 8u from JDK-8139581: "AWT components are not drawn after removal and addition to a container" (8u102) so should be added. * test/java/awt/Robot/RobotWheelTest/RobotWheelTest.java Test opened up in JDK-8079255: "[TEST_BUG] [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only" with no code changes so could be included. * test/java/awt/TextArea/TextAreaScrolling/TextAreaScrolling.java From JDK-6180449: "PIT: Text in TextArea scrolls to its left one char when selecting the text from the end". Removes part of a Windows code fix with no clear explanation of why. Test is then problematic on other platforms (JDK-8160764) Ok to omit. * test/java/awt/TextField/EOLTest/EOLTest.java From JDK-8055197: "TextField deletes multiline strings". Significant behavioural change so ok to omit. * test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java From JDK-8144074: "[PIT] Crash calling Toolkit.getScreenSize() on Windows". Windows fix which avoids a crash. Cause of crash seems to be JDK-8073320 which is not in 8u, but seems a worthwhile defensive addition. * test/java/awt/Window/FindOwner/FindOwnerTest.html From JDK-8139227: "Text fields in JPopupMenu structure do not receive focus in hosted Applets". Behaviour change for applets on Windows. Ok to omit. * test/java/awt/Window/MultiWindowApp/MultiWindowAppTest.java From JDK-8022334: "After calling frame.toBack() dialog goes to the back on Ubuntu 12.04" Changes result of WMClass() for XWindow. Seems safest to omit. * test/java/awt/Window/ScreenLocation/ScreenLocationTest.java From JDK-8011616: "JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity" Behavioural change so seems safest to omit. * test/java/awt/applet/Applet/AppletFlipBuffer.java From JDK-8130390: "Applet fails to launch on virtual desktop" Behavioural change so seems safest to omit. * test/java/awt/datatransfer/ConstructFlavoredObjectTest/ConstructFlavoredObjectTest.java From JDK-8142968: "Module System implementation" so fine to omit. * test/java/awt/datatransfer/CustomClassLoaderTransferTest/CustomClassLoaderTransferTest.java From JDK-8041464: "[TEST_BUG] CustomClassLoaderTransferTest does not support OS X" which actually seems to open up this test so could be included. * test/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java Also from JDK-8142968, so fine to omit. * test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html Should now be included as you backported JDK-8046221 :-) * test/java/awt/dnd/Button2DragTest/Button2DragTest.java Backporting the test cleanup JDK-7124381: "DragSourceListener.dragDropEnd() never been called on completion of dnd operation" might be worthwhile. * test/java/awt/font/Underline/UnderlineTest.java See comment above about JDK-8130125; it strikes again. * test/java/awt/hidpi/properties/HiDPIPropertiesUnixTest.java From JDK-8150844: "[hidpi] [macosx] -Dsun.java2d.uiScale should be taken into account for OS X". Relies on HiDPI changes which aren't generally in 8u so ok to omit. * test/java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java Seems to be missing a copyright header update. * test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java Present in 8u (JDK-8029253) but seems to have been missed. * test/java/awt/image/DrawImage/ScaledImageAlphaTest.java From JDK-8139183: "drawImage misses background's alpha channel". Behaviour change that seems a little risky to backport. * test/java/awt/image/VolatileImage/BitmaskVolatileImage.java Major change in JDK-7188942: "Remove support of pbuffers in OGL Java2d pipeline", a closed bug. Ok to omit. * test/java/awt/image/VolatileImage/VolatileImageBug.java Now present in 8u thanks to JDK-8159495: "Fix index offsets" * test/java/awt/image/multiresolution/MultiresolutionIconTest.java From JDK-8150724: "[TEST] HiDPI: create a test for multiresolution icons", can be included. * test/java/awt/print/PageFormat/NullPaper.java Now present in 8u as of 8u292-b01 and JDK-8038723. * test/java/awt/print/PageFormat/ReverseLandscapeTest.java Likewise introduced by JDK-8038723. * test/java/awt/security/WarningWindowDisposeTest/WarningWindowDisposeCrashTest.java Introduced by JDK-8041490: "PIT: [macosx] Crash in system tray functionality check test" which fixes a crash. Seems like a good check to backport. * test/javax/swing/SwingUtilities/8049533/bug8049533.java From JDK-8049533: "SwingUtilities.convertMouseEvent misses MouseWheelEvent.preciseWheelRotation" Behaviour change it is safest to omit. * test/sun/java2d/OpenGL/CopyAreaOOB.java JDK-7131835: "[TEST_BUG] Test does not consider that the rounded edges of the window in Mac OS 10.7" opens up this test which can be included. * test/sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java JDK-6345095: "regression test EmptyClipRenderingTest fails" opens up this test which could be included. * test/sun/java2d/SunGraphics2D/SurfaceDestination/SurfaceDestination.java From JDK-8134603: "Incorrect destination is used in CGLLayer surface", Mac OS X behaviour change probably safest to omit. Summary: * JDK-7112454, JDK-7185221, JDK-8136592, JDK-8079255, JDK-8041464, JDK-8150724, JDK-7131835, JDK-6345095 All introduce missing tests in isolation and could be easily backported (possibly clean, may need removal of @modules lines) * JDK-8033936, JDK-6778087, JDK-8073320 & JDK-8041490 are trivial backports it would be good to fix The first two add missing information. The second two protect against crashes. * I'll propose my existing backport of JDK-8130125 tomorrow, which adds a couple of missing tests. * Optional: JDK-7124381. * Update patch with: - test/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html (JDK-7112454) - java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java (missed) - test/java/awt/Frame/NonEDT_GUI_DeadlockTest/NonEDT_GUI_Deadlock.html (JDK-8130125) - test/java/awt/FullScreen/NonExistentDisplayModeTest/NonExistentDisplayModeTest.java (JDK-7185221) - test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html (JDK-8136592) - test/java/awt/List/ItemEventTest/ItemEventTest.java (JDK-8033936) - test/java/awt/Mouse/MouseWheelAbsXY/MouseWheelAbsXY.java (JDK-6778087) - test/java/awt/MouseInfo/GetPointerInfoTest.java (missed) - test/java/awt/MouseInfo/MultiscreenPointerInfo.java (missed) - test/java/awt/Paint/ComponentIsNotDrawnAfterRemoveAddTest/ComponentIsNotDrawnAfterRemoveAddTest.java (missed) - test/java/awt/Robot/RobotWheelTest/RobotWheelTest.java (JDK-8079255) - test/java/awt/Toolkit/GetSizeTest/GetScreenSizeTest.java (JDK-8073320) - test/java/awt/datatransfer/CustomClassLoaderTransferTest/CustomClassLoaderTransferTest.java (JDK-8041464) - test/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html (missed) - test/java/awt/font/Underline/UnderlineTest.java (JDK-8130125) - test/java/awt/image/DrawImage/IncorrectClipXorModeSW2Surface.java (missing copyright header update) - test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java (missed) - test/java/awt/image/VolatileImage/VolatileImageBug.java (missed) - test/java/awt/image/multiresolution/MultiresolutionIconTest.java (JDK-8150724) - test/java/awt/print/PageFormat/NullPaper.java (recently introduced) - test/java/awt/print/PageFormat/ReverseLandscapeTest.java (recently introduced) - test/java/awt/security/WarningWindowDisposeTest/WarningWindowDisposeCrashTest.java (JDK-8041490) - test/sun/java2d/OpenGL/CopyAreaOOB.java (JDK-7131835) - test/sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java (JDK-6345095) [0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 dcherepanov at azul.com Mon Feb 15 17:54:27 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Mon, 15 Feb 2021 20:54:27 +0300 Subject: [8u] RFR: 8261766: [8u] hotspot needs to recognise cl.exe 19.16 to build with VS2017 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8261766 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261766/webrev.v0/ The patch updates the build scripts for 8u to recognise values for MSC_VER "1914", "1915" and "1916". This fixes building 8u with VS 2017 version 15.9 (cl.exe 19.16). Alternatively, this could be resolved by backport for https://bugs.openjdk.java.net/browse/JDK-8043492 (that removes COMPILER_NAME and its usage). The benefit of the proposed patch is that it's minimal/low-risk and is in line with how similar issues were resolved in 8u (https://bugs.openjdk.java.net/browse/JDK-8209359). Thanks, Dmitry From serge.chernyshev at bell-sw.com Mon Feb 15 21:14:12 2021 From: serge.chernyshev at bell-sw.com (Sergey Chernyshev) Date: Tue, 16 Feb 2021 00:14:12 +0300 Subject: [8u] RFR 8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS In-Reply-To: <7e3144e37e5a4a8d051f64cc53c5a83b0547eacc.camel@redhat.com> References: <7e3144e37e5a4a8d051f64cc53c5a83b0547eacc.camel@redhat.com> Message-ID: <5004591a-a8dd-2865-498b-d369e2d5b16c@bell-sw.com> Hi Severin, Thank you for review. On 15.02.2021 19:48, Severin Gehwolf wrote: > On Mon, 2021-02-15 at 14:07 +0300, Sergey Chernyshev wrote: >> 8u webrev: >> http://cr.openjdk.java.net/~alexsch/sercher/8260349.8u/webrev.00/ > This looks fine to me. > > Thanks, > Severin > -- Best regards, Sergey Chernyshev Bellsoft LLC From gnu.andrew at redhat.com Tue Feb 16 02:54:41 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 16 Feb 2021 02:54:41 +0000 Subject: [8u] RFR: 8261766: [8u] hotspot needs to recognise cl.exe 19.16 to build with VS2017 In-Reply-To: References: Message-ID: <20210216025441.GB525580@rincewind> On 20:54 Mon 15 Feb , Dmitry Cherepanov wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8261766 > 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261766/webrev.v0/ > > The patch updates the build scripts for 8u to recognise values for MSC_VER "1914", "1915" and "1916". This fixes building 8u with VS 2017 version 15.9 (cl.exe 19.16). > > Alternatively, this could be resolved by backport for https://bugs.openjdk.java.net/browse/JDK-8043492 (that removes COMPILER_NAME and its usage). The benefit of the proposed patch is that it's minimal/low-risk and is in line with how similar issues were resolved in 8u (https://bugs.openjdk.java.net/browse/JDK-8209359). > > Thanks, > > Dmitry > I agree that this patch is preferable. JDK-8043492 changes a lot of the build logic which I think is unnecessarily risky for the change required. Patch looks good to me. Please flag this for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 alvdavi at amazon.com Tue Feb 16 05:57:13 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Mon, 15 Feb 2021 21:57:13 -0800 Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException Message-ID: <12291d48-a1db-66dc-5a14-cfa75ef16cfe@amazon.com> Hi, I would like to request a review for JDK-8239798 Original bug: https://bugs.openjdk.java.net/browse/JDK-8239798 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8239798/webrev.8u.jdk.00/ The backport is mostly clean, except for some changes in SSLSocketInputRecord.java to account for DTLS removal in 8u [1] This is one of a set of multiple patches TLS1.3 patches that were added to 11u after 11.0.7 that did not make it into 8u. All jdk tier1 test pass. Thanks, David -- [1] https://bugs.openjdk.java.net/browse/JDK-8245469 From dcherepanov at azul.com Tue Feb 16 10:49:35 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 16 Feb 2021 13:49:35 +0300 Subject: [8u] RFR: 8261766: [8u] hotspot needs to recognise cl.exe 19.16 to build with VS2017 In-Reply-To: <20210216025441.GB525580@rincewind> References: <20210216025441.GB525580@rincewind> Message-ID: <9f24a9f0-3c0a-3872-5d12-11030ca1f299@azul.com> Thanks for the review. I've flagged the bug for approval. Dmitry On 16.02.2021 05:54, Andrew Hughes wrote: > On 20:54 Mon 15 Feb , Dmitry Cherepanov wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8261766 >> 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261766/webrev.v0/ >> >> The patch updates the build scripts for 8u to recognise values for MSC_VER "1914", "1915" and "1916". This fixes building 8u with VS 2017 version 15.9 (cl.exe 19.16). >> >> Alternatively, this could be resolved by backport for https://bugs.openjdk.java.net/browse/JDK-8043492 (that removes COMPILER_NAME and its usage). The benefit of the proposed patch is that it's minimal/low-risk and is in line with how similar issues were resolved in 8u (https://bugs.openjdk.java.net/browse/JDK-8209359). >> >> Thanks, >> >> Dmitry >> > I agree that this patch is preferable. JDK-8043492 changes a lot of > the build logic which I think is unnecessarily risky for the change > required. > > Patch looks good to me. Please flag this for approval. > > Thanks, From sgehwolf at redhat.com Tue Feb 16 10:54:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Feb 2021 11:54:49 +0100 Subject: [8u] RFR: 8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14 Message-ID: Hi, Please review this change to update the language subtags in OpenJDK 8u. A similar change has been done to Oracle JDK a few releases back. The JDK 11 patch applies cleanly, but the test fails to compile due to use of List.of(). I've changed it to use Collections.unmodifiableList(Arrays.asList(...)) instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8225435 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8225435/02/webrev/ Testing: modified regression test (fails before; passes after). tier1 (no changes). Thoughts? Thanks, Severin From sgehwolf at redhat.com Tue Feb 16 16:04:38 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 16 Feb 2021 17:04:38 +0100 Subject: [8u] RFR: 8061777: (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS Message-ID: <5228d4fb05b86363c9d6f1d4ef5939e66c31f8ec.camel@redhat.com> Hi, Please review this zip fs fix. It's a fix Oracle did to their JDK 8 too. The JDK 11u patch didn't apply cleanly and required some manual work. Mostly because: a) The implementation of ZipFileSystem.getPath() is slightly different in 8u. It uses a local String variable 'path' over JDK 11's short return approach if more.length == 0. Either way, changes shoudl be equivalent. b) ZFSTests.java doesn't have JDK-8153248 changes which is not in OpenJDK 8u. Also context was different enough for hunks to not apply cleanly. I've ported them over manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8061777 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8061777/01/webrev/ Testing: Added regression test (fails prior; passes after). zipfs/java.util.zip tests. Thoughts? Thanks, Severin * From dcherepanov at azul.com Tue Feb 16 18:03:06 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Tue, 16 Feb 2021 21:03:06 +0300 Subject: [8u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory Message-ID: <67107b8a-e855-5f0b-f559-34a36d28c351@azul.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8236500/webrev.v0/ 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21c3971673cf Applies cleanly after adjusting path. Sending this review request as I needed to update generated-configure.sh. Testing: I encountered this issue when building 8u ("configure: error: Could not find any dlls in /cygdrive/c/progra~2/wi3cf2~1/10/Redist/ucrt/DLLs/x64") and this patch fixed this issue. Thanks, Dmitry From gnu.andrew at redhat.com Wed Feb 17 03:40:41 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Feb 2021 03:40:41 +0000 Subject: [8u] RFR: 8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14 In-Reply-To: References: Message-ID: <20210217034041.GA641764@rincewind> On 11:54 Tue 16 Feb , Severin Gehwolf wrote: > Hi, > > Please review this change to update the language subtags in OpenJDK 8u. > A similar change has been done to Oracle JDK a few releases back. > > The JDK 11 patch applies cleanly, but the test fails to compile due to > use of List.of(). I've changed it to use > Collections.unmodifiableList(Arrays.asList(...)) instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225435 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8225435/02/webrev/ > > Testing: modified regression test (fails before; passes after). tier1 (no changes). > > Thoughts? > > Thanks, > Severin > > Looks good. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 17 04:00:12 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Feb 2021 04:00:12 +0000 Subject: [8u] RFR: 8061777: (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: <5228d4fb05b86363c9d6f1d4ef5939e66c31f8ec.camel@redhat.com> References: <5228d4fb05b86363c9d6f1d4ef5939e66c31f8ec.camel@redhat.com> Message-ID: <20210217040012.GB641764@rincewind> On 17:04 Tue 16 Feb , Severin Gehwolf wrote: > Hi, > > Please review this zip fs fix. It's a fix Oracle did to their JDK 8 > too. The JDK 11u patch didn't apply cleanly and required some manual > work. Mostly because: > > a) The implementation of ZipFileSystem.getPath() is slightly > different in 8u. It uses a local String variable 'path' over > JDK 11's short return approach if more.length == 0. Either way, > changes shoudl be equivalent. I assume you mean JDK 9's, as that is where the patch is from. The code was changed by JDK-8150496 as an optimisation: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9ed1a4feefb#l3.82 8u version looks ok, as the fix is to perform normalisation correctly in the ZipPath constructor, which requires the original String object, not the result of getBytes (which is now called in ZipPath's normalize methods) > b) ZFSTests.java doesn't have JDK-8153248 changes which is not > in OpenJDK 8u. Also context was different enough for hunks to > not apply cleanly. I've ported them over manually. > Looks fine. > Bug: https://bugs.openjdk.java.net/browse/JDK-8061777 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8061777/01/webrev/ > > Testing: Added regression test (fails prior; passes after). > zipfs/java.util.zip tests. > > Thoughts? > > Thanks, > Severin > > * > Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 17 04:02:48 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Feb 2021 04:02:48 +0000 Subject: [8u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory In-Reply-To: <67107b8a-e855-5f0b-f559-34a36d28c351@azul.com> References: <67107b8a-e855-5f0b-f559-34a36d28c351@azul.com> Message-ID: <20210217040248.GC641764@rincewind> On 21:03 Tue 16 Feb , Dmitry Cherepanov wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 > 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8236500/webrev.v0/ > 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21c3971673cf > > Applies cleanly after adjusting path. Sending this review request as I needed to update generated-configure.sh. > > Testing: I encountered this issue when building 8u ("configure: error: Could not find any dlls in /cygdrive/c/progra~2/wi3cf2~1/10/Redist/ucrt/DLLs/x64") and this patch fixed this issue. > > Thanks, > > Dmitry > Looks good to me. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 17 05:55:23 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Feb 2021 05:55:23 +0000 Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 Message-ID: <20210217055523.GD641764@rincewind> Bugs: https://bugs.openjdk.java.net/browse/JDK-8261867 https://bugs.openjdk.java.net/browse/JDK-8130125 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8261867/webrev.01/ The main focus of JDK-8130125 is irrelevant to 8u, as it concerns the introduction of the module system. However, the change was also used to introduce a number of other test changes and open up three tests [0]. Backporting these tests will increase test coverage in 8u and ease the backport of JDK-8159690.. The webrev above includes a subset of the changes from JDK-8130125, suitable for 8u. [0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Feb 17 06:04:56 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Feb 2021 06:04:56 +0000 Subject: OpenJDK 8u292-b01 EA Released Message-ID: <20210217060456.GA649502@rincewind> I've made available an early access source bundle for 8u282, based on the tag jdk8u292-b03: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b03-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b03-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint: CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 4d8cd2787e4a4b0ed342df86a8ddb7b55172759ea51e9c7f992232b5a904b46b openjdk8u292-b03-ea.tar.xz 3cbbac6939289e40ddc776d6d2f6acd796d225f09ddf6b354995452083ea40ab openjdk8u292-b03-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u292-b03-ea.sha256 Changes in 8u292-b03: - JDK-8145051: Wrong parameter name in synthetic lambda method leads to verifier error - JDK-8172404: Tools should warn if weak algorithms are used before restricting them - JDK-8209333: Socket reset issue for TLS 1.3 socket close - JDK-8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl - JDK-8239091: Reversed arguments in call to strstr in freetype "debug" code. - JDK-8240827: Downport SSLSocketImpl.java from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE" - JDK-8255880: UI of Swing components is not redrawn after their internal state changed - JDK-8256682: JDK-8202343 is incomplete - JDK-8260930: AARCH64: Invalid value passed to critical JNI function Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 dcherepanov at azul.com Wed Feb 17 09:36:42 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Wed, 17 Feb 2021 12:36:42 +0300 Subject: [8u] RFR: 8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory In-Reply-To: <20210217040248.GC641764@rincewind> References: <67107b8a-e855-5f0b-f559-34a36d28c351@azul.com> <20210217040248.GC641764@rincewind> Message-ID: <6b08bfd0-15a3-ae01-0f7a-b0213afadcef@azul.com> Thanks for the review. I've flagged this bug for approval. Dmitry On 17.02.2021 07:02, Andrew Hughes wrote: > On 21:03 Tue 16 Feb , Dmitry Cherepanov wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8236500 >> 8u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8236500/webrev.v0/ >> 11u patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/21c3971673cf >> >> Applies cleanly after adjusting path. Sending this review request as I needed to update generated-configure.sh. >> >> Testing: I encountered this issue when building 8u ("configure: error: Could not find any dlls in /cygdrive/c/progra~2/wi3cf2~1/10/Redist/ucrt/DLLs/x64") and this patch fixed this issue. >> >> Thanks, >> >> Dmitry >> > Looks good to me. Please flag for approval. > > Thanks, From volker.simonis at gmail.com Wed Feb 17 13:54:07 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Feb 2021 14:54:07 +0100 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> Message-ID: Hi Erik^2 :) thank you so much for the detailed description. I'm especially excited that you've already published fully consolidated mono-repos for jdk 6 to 9. That's really very much appreciated! Now that the heavy lifting has been done, I hope we can seriously consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what blockers are you still seeing? Is there anything the community can help with to speedup the migration? Thank you and best regards, Volker On Tue, Feb 16, 2021 at 8:31 PM wrote: > > Hello, > > As you may have seen, Erik Duveblad just posted about our prototype > conversions on skara-dev [1]. These are based on the same kind of > forest->mono repo conversion, followed by hg->git conversion that > mainline went through. > > I have been working for a while now on adapting the scripts from JEP 296 > to work for the old update releases. This has required more work than I > first anticipated as the problem now requires a more generalized > solution, but I believe I now have something that works reasonably well. > If you are curious on the details, please continue reading. > > Volker's description of the processes is pretty accurate on a high > level. The main difference in 8u compared to a main release is that the > tags are not sequential in history. This means that we can't transplant > (or splice as it's called in Mercurial terms) changes as freely on top > of each tagged change. In the original JDK 10 consolidation, we had a > handful of changes that weren't linear (around the transition between > JDK 9 and 10), and I handled them differently (basically just merging > them together to recreate the point in history, but not splicing > anything on top afterwards). Since they were only a handful, I could > just list them out explicitly in the script. For 8u, a majority of the > tags are non linear, so a big problem was creating an algorithm that > would automatically figure out a reasonable line of tags in sequence > that I could use to splice changes on top of. > > Another big problem is that there are often tags merged together in > different order in different repos. When this happens, the script needs > to figure out the best order to do the conversion. I have tried to > automate this process as much as possible. The ordering is sensitive > when some of the tags are used to splice changes on top of them. There > are also cases of tags missing completely. > > In the end, the state of the mono repo at each tag is verified to be > exactly the same as the forest of repos at each tag. The state of > changes between tags is however less predictable in 8u compared to > mainline due to the large amount of non linear tags. > > For the extra curious, here is what the current algorithm for choosing > the "splice tags" looks like: > > 1. Start with the first tag > > 2. Continue with each consecutive build for current release until a gap > in build numbers is detected (we typically have update release builds > >b30 that probably aren't that interesting) > > 3. Find the next release in order and then find the first tag in that > release that is also a descendant of the previous splice tag in every repo. > > 4. Repeat from 2 until all tags have been considered. > > /Erik > > [1] > https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html > > On 2021-02-12 13:33, Volker Simonis wrote: > > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: > >> On 12/02/2021 16:37, Severin Gehwolf wrote: > >>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > >>> more thought than 11u. > >> That's what I was thinking. > >> > >>> My preference would be to do it in steps: > >>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > >>> 2.) HG -> git conversion using Skara tooling (should take care of > >>> proper metadata, etc.) > >> Yes, I think this is the right way to go about it. If nothing else > >> because the tools for the second step assumed that the first one had > >> happened. > >> > >> The really tricky differences I see happen at step 1 (although they > >> might have a knock-on effect at step 2) > >> > > I think converting 8u to a Git mono-repo might not be as complicated > > and risky as it seems. We have to remember that most of the work has > > already been done by JEP 296 in jdk10. That process already converted > > all the old history and as nobody seems to have been complaining about > > it in jdk10 and later, that conversion must have been fine. I.e. The > > jdk 10 repository naturally contains the sources of jdk8 from which is > > was initially forked (I think at jdk8-b120). > > > > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: > > > > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 > > > > This will give us a mono-repo at the stage of jdk8-b120. Afterwards, > > we only have to use the JEP 296 scripts or something equivalent (I > > hope that the Oracle build group can assist or at least give some good > > advice here :) > > > > From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created > > with the above command, it looks like the "JEP 296" script worked as > > follows: > > - let's assume were at a changeset which merges all the subrepos at a > > specific build tag "jdk8-bXX" (builds were usually tagged weekly, so > > every jdk8-bXX tag corresponds to a weekly version). > > - sequentially transplant all the changes from a single subrepo up > > until the next tag "jdk8-bXX+1" into the new repo > > - do this sequentially for all the other sub-repositories > > - create a merge change in the new mono-repo which merges all the > > newly transplanted changes and tag it with "jdk8-bXX+1" > > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are > > bit-wise equal to the sources of the jdk8u forest when every single > > repo is synced to the same tag. > > - repeat the procedure for all the other jdk8-bXX tags > > > > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow > > the described procedure for all the additional changes between > > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. > > Needless to say that the Corretto team is fully supporting the > > transition of jdk8u from a Mercurial forest to a Git mono-repo and > > will be happy to get involved into the process :) > > > > Best regards, > > Volker > > > >> JEP 296 had to relocate all the java code into modules > >> JEP 296 did not have to retain (and therefore relocate) all of the > >> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) > >> > >> I don't suppose these differences would be impossible to sort out but I > >> think they would require some effort. > >> > >> regards, > >> > >> > >> Andrew Dinn > >> ----------- > >> From goetz.lindenmaier at sap.com Wed Feb 17 15:19:12 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 17 Feb 2021 15:19:12 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> Message-ID: Hi, I think it is about time to start a thread of its own to discuss this for 8. What do you think? Best regards, Goetz. > -----Original Message----- > From: jdk8u-dev On Behalf Of Volker > Simonis > Sent: Wednesday, February 17, 2021 2:54 PM > To: Erik Joelsson ; Erik Helin > > Cc: jdk-updates-dev ; jdk8u-dev dev at openjdk.java.net> > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > 11.0.13 cycle > > Hi Erik^2 :) > > thank you so much for the detailed description. I'm especially excited > that you've already published fully consolidated mono-repos for jdk 6 > to 9. That's really very much appreciated! > > Now that the heavy lifting has been done, I hope we can seriously > consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what > blockers are you still seeing? Is there anything the community can > help with to speedup the migration? > > Thank you and best regards, > Volker > > On Tue, Feb 16, 2021 at 8:31 PM wrote: > > > > Hello, > > > > As you may have seen, Erik Duveblad just posted about our prototype > > conversions on skara-dev [1]. These are based on the same kind of > > forest->mono repo conversion, followed by hg->git conversion that > > mainline went through. > > > > I have been working for a while now on adapting the scripts from JEP 296 > > to work for the old update releases. This has required more work than I > > first anticipated as the problem now requires a more generalized > > solution, but I believe I now have something that works reasonably well. > > If you are curious on the details, please continue reading. > > > > Volker's description of the processes is pretty accurate on a high > > level. The main difference in 8u compared to a main release is that the > > tags are not sequential in history. This means that we can't transplant > > (or splice as it's called in Mercurial terms) changes as freely on top > > of each tagged change. In the original JDK 10 consolidation, we had a > > handful of changes that weren't linear (around the transition between > > JDK 9 and 10), and I handled them differently (basically just merging > > them together to recreate the point in history, but not splicing > > anything on top afterwards). Since they were only a handful, I could > > just list them out explicitly in the script. For 8u, a majority of the > > tags are non linear, so a big problem was creating an algorithm that > > would automatically figure out a reasonable line of tags in sequence > > that I could use to splice changes on top of. > > > > Another big problem is that there are often tags merged together in > > different order in different repos. When this happens, the script needs > > to figure out the best order to do the conversion. I have tried to > > automate this process as much as possible. The ordering is sensitive > > when some of the tags are used to splice changes on top of them. There > > are also cases of tags missing completely. > > > > In the end, the state of the mono repo at each tag is verified to be > > exactly the same as the forest of repos at each tag. The state of > > changes between tags is however less predictable in 8u compared to > > mainline due to the large amount of non linear tags. > > > > For the extra curious, here is what the current algorithm for choosing > > the "splice tags" looks like: > > > > 1. Start with the first tag > > > > 2. Continue with each consecutive build for current release until a gap > > in build numbers is detected (we typically have update release builds > > >b30 that probably aren't that interesting) > > > > 3. Find the next release in order and then find the first tag in that > > release that is also a descendant of the previous splice tag in every repo. > > > > 4. Repeat from 2 until all tags have been considered. > > > > /Erik > > > > [1] > > https://mail.openjdk.java.net/pipermail/skara-dev/2021- > February/004228.html > > > > On 2021-02-12 13:33, Volker Simonis wrote: > > > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: > > >> On 12/02/2021 16:37, Severin Gehwolf wrote: > > >>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > > >>> more thought than 11u. > > >> That's what I was thinking. > > >> > > >>> My preference would be to do it in steps: > > >>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > > >>> 2.) HG -> git conversion using Skara tooling (should take care of > > >>> proper metadata, etc.) > > >> Yes, I think this is the right way to go about it. If nothing else > > >> because the tools for the second step assumed that the first one had > > >> happened. > > >> > > >> The really tricky differences I see happen at step 1 (although they > > >> might have a knock-on effect at step 2) > > >> > > > I think converting 8u to a Git mono-repo might not be as complicated > > > and risky as it seems. We have to remember that most of the work has > > > already been done by JEP 296 in jdk10. That process already converted > > > all the old history and as nobody seems to have been complaining about > > > it in jdk10 and later, that conversion must have been fine. I.e. The > > > jdk 10 repository naturally contains the sources of jdk8 from which is > > > was initially forked (I think at jdk8-b120). > > > > > > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: > > > > > > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 > > > > > > This will give us a mono-repo at the stage of jdk8-b120. Afterwards, > > > we only have to use the JEP 296 scripts or something equivalent (I > > > hope that the Oracle build group can assist or at least give some good > > > advice here :) > > > > > > From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created > > > with the above command, it looks like the "JEP 296" script worked as > > > follows: > > > - let's assume were at a changeset which merges all the subrepos at a > > > specific build tag "jdk8-bXX" (builds were usually tagged weekly, so > > > every jdk8-bXX tag corresponds to a weekly version). > > > - sequentially transplant all the changes from a single subrepo up > > > until the next tag "jdk8-bXX+1" into the new repo > > > - do this sequentially for all the other sub-repositories > > > - create a merge change in the new mono-repo which merges all the > > > newly transplanted changes and tag it with "jdk8-bXX+1" > > > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are > > > bit-wise equal to the sources of the jdk8u forest when every single > > > repo is synced to the same tag. > > > - repeat the procedure for all the other jdk8-bXX tags > > > > > > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow > > > the described procedure for all the additional changes between > > > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. > > > Needless to say that the Corretto team is fully supporting the > > > transition of jdk8u from a Mercurial forest to a Git mono-repo and > > > will be happy to get involved into the process :) > > > > > > Best regards, > > > Volker > > > > > >> JEP 296 had to relocate all the java code into modules > > >> JEP 296 did not have to retain (and therefore relocate) all of the > > >> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) > > >> > > >> I don't suppose these differences would be impossible to sort out but I > > >> think they would require some effort. > > >> > > >> regards, > > >> > > >> > > >> Andrew Dinn > > >> ----------- > > >> From vkempik at azul.com Wed Feb 17 16:18:49 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 17 Feb 2021 16:18:49 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> Message-ID: <15fb175913bd4861a788ce1586111fa5@azul.com> Hello We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace. Regards, Vladimir. Volker Simonis 17 ??????? 2021 ?. 16:54:46 ???????: Hi Erik^2 :) thank you so much for the detailed description. I'm especially excited that you've already published fully consolidated mono-repos for jdk 6 to 9. That's really very much appreciated! Now that the heavy lifting has been done, I hope we can seriously consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what blockers are you still seeing? Is there anything the community can help with to speedup the migration? Thank you and best regards, Volker On Tue, Feb 16, 2021 at 8:31 PM wrote: Hello, As you may have seen, Erik Duveblad just posted about our prototype conversions on skara-dev [1]. These are based on the same kind of forest->mono repo conversion, followed by hg->git conversion that mainline went through. I have been working for a while now on adapting the scripts from JEP 296 to work for the old update releases. This has required more work than I first anticipated as the problem now requires a more generalized solution, but I believe I now have something that works reasonably well. If you are curious on the details, please continue reading. Volker's description of the processes is pretty accurate on a high level. The main difference in 8u compared to a main release is that the tags are not sequential in history. This means that we can't transplant (or splice as it's called in Mercurial terms) changes as freely on top of each tagged change. In the original JDK 10 consolidation, we had a handful of changes that weren't linear (around the transition between JDK 9 and 10), and I handled them differently (basically just merging them together to recreate the point in history, but not splicing anything on top afterwards). Since they were only a handful, I could just list them out explicitly in the script. For 8u, a majority of the tags are non linear, so a big problem was creating an algorithm that would automatically figure out a reasonable line of tags in sequence that I could use to splice changes on top of. Another big problem is that there are often tags merged together in different order in different repos. When this happens, the script needs to figure out the best order to do the conversion. I have tried to automate this process as much as possible. The ordering is sensitive when some of the tags are used to splice changes on top of them. There are also cases of tags missing completely. In the end, the state of the mono repo at each tag is verified to be exactly the same as the forest of repos at each tag. The state of changes between tags is however less predictable in 8u compared to mainline due to the large amount of non linear tags. For the extra curious, here is what the current algorithm for choosing the "splice tags" looks like: 1. Start with the first tag 2. Continue with each consecutive build for current release until a gap in build numbers is detected (we typically have update release builds b30 that probably aren't that interesting) 3. Find the next release in order and then find the first tag in that release that is also a descendant of the previous splice tag in every repo. 4. Repeat from 2 until all tags have been considered. /Erik [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html On 2021-02-12 13:33, Volker Simonis wrote: On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: On 12/02/2021 16:37, Severin Gehwolf wrote: Don't get me wrong, moving JDK 8u to git is doable, but it'll need some more thought than 11u. That's what I was thinking. My preference would be to do it in steps: 1.) HG forest -> monorepo conversion (using JEP 296 scripts) 2.) HG -> git conversion using Skara tooling (should take care of proper metadata, etc.) Yes, I think this is the right way to go about it. If nothing else because the tools for the second step assumed that the first one had happened. The really tricky differences I see happen at step 1 (although they might have a knock-on effect at step 2) I think converting 8u to a Git mono-repo might not be as complicated and risky as it seems. We have to remember that most of the work has already been done by JEP 296 in jdk10. That process already converted all the old history and as nobody seems to have been complaining about it in jdk10 and later, that conversion must have been fine. I.e. The jdk 10 repository naturally contains the sources of jdk8 from which is was initially forked (I think at jdk8-b120). So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 This will give us a mono-repo at the stage of jdk8-b120. Afterwards, we only have to use the JEP 296 scripts or something equivalent (I hope that the Oracle build group can assist or at least give some good advice here :) >From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created with the above command, it looks like the "JEP 296" script worked as follows: - let's assume were at a changeset which merges all the subrepos at a specific build tag "jdk8-bXX" (builds were usually tagged weekly, so every jdk8-bXX tag corresponds to a weekly version). - sequentially transplant all the changes from a single subrepo up until the next tag "jdk8-bXX+1" into the new repo - do this sequentially for all the other sub-repositories - create a merge change in the new mono-repo which merges all the newly transplanted changes and tag it with "jdk8-bXX+1" - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are bit-wise equal to the sources of the jdk8u forest when every single repo is synced to the same tag. - repeat the procedure for all the other jdk8-bXX tags We can probably take the above jdk11u-dev-jdk8-b120 repo and follow the described procedure for all the additional changes between jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. Needless to say that the Corretto team is fully supporting the transition of jdk8u from a Mercurial forest to a Git mono-repo and will be happy to get involved into the process :) Best regards, Volker JEP 296 had to relocate all the java code into modules JEP 296 did not have to retain (and therefore relocate) all of the java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) I don't suppose these differences would be impossible to sort out but I think they would require some effort. regards, Andrew Dinn ----------- From alvdavi at amazon.com Wed Feb 17 17:07:41 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 17 Feb 2021 17:07:41 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <15fb175913bd4861a788ce1586111fa5@azul.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> , <15fb175913bd4861a788ce1586111fa5@azul.com> Message-ID: <290418C3-C152-4678-A02D-B2965D573887@amazon.com> Hi, I?m intrigued about the clean back port issue. Would you mind providing more detail on why is that so? Thanks, David > On Feb 17, 2021, at 08:19, Vladimir Kempik wrote: > > ?CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hello > > We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace. > > Regards, Vladimir. > > Volker Simonis 17 ??????? 2021 ?. 16:54:46 ???????: > > Hi Erik^2 :) > > thank you so much for the detailed description. I'm especially excited > that you've already published fully consolidated mono-repos for jdk 6 > to 9. That's really very much appreciated! > > Now that the heavy lifting has been done, I hope we can seriously > consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what > blockers are you still seeing? Is there anything the community can > help with to speedup the migration? > > Thank you and best regards, > Volker > > On Tue, Feb 16, 2021 at 8:31 PM wrote: > > Hello, > > As you may have seen, Erik Duveblad just posted about our prototype > conversions on skara-dev [1]. These are based on the same kind of > forest->mono repo conversion, followed by hg->git conversion that > mainline went through. > > I have been working for a while now on adapting the scripts from JEP 296 > to work for the old update releases. This has required more work than I > first anticipated as the problem now requires a more generalized > solution, but I believe I now have something that works reasonably well. > If you are curious on the details, please continue reading. > > Volker's description of the processes is pretty accurate on a high > level. The main difference in 8u compared to a main release is that the > tags are not sequential in history. This means that we can't transplant > (or splice as it's called in Mercurial terms) changes as freely on top > of each tagged change. In the original JDK 10 consolidation, we had a > handful of changes that weren't linear (around the transition between > JDK 9 and 10), and I handled them differently (basically just merging > them together to recreate the point in history, but not splicing > anything on top afterwards). Since they were only a handful, I could > just list them out explicitly in the script. For 8u, a majority of the > tags are non linear, so a big problem was creating an algorithm that > would automatically figure out a reasonable line of tags in sequence > that I could use to splice changes on top of. > > Another big problem is that there are often tags merged together in > different order in different repos. When this happens, the script needs > to figure out the best order to do the conversion. I have tried to > automate this process as much as possible. The ordering is sensitive > when some of the tags are used to splice changes on top of them. There > are also cases of tags missing completely. > > In the end, the state of the mono repo at each tag is verified to be > exactly the same as the forest of repos at each tag. The state of > changes between tags is however less predictable in 8u compared to > mainline due to the large amount of non linear tags. > > For the extra curious, here is what the current algorithm for choosing > the "splice tags" looks like: > > 1. Start with the first tag > > 2. Continue with each consecutive build for current release until a gap > in build numbers is detected (we typically have update release builds > b30 that probably aren't that interesting) > > 3. Find the next release in order and then find the first tag in that > release that is also a descendant of the previous splice tag in every repo. > > 4. Repeat from 2 until all tags have been considered. > > /Erik > > [1] > https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html > > On 2021-02-12 13:33, Volker Simonis wrote: > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: > On 12/02/2021 16:37, Severin Gehwolf wrote: > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > more thought than 11u. > That's what I was thinking. > > My preference would be to do it in steps: > 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > 2.) HG -> git conversion using Skara tooling (should take care of > proper metadata, etc.) > Yes, I think this is the right way to go about it. If nothing else > because the tools for the second step assumed that the first one had > happened. > > The really tricky differences I see happen at step 1 (although they > might have a knock-on effect at step 2) > > I think converting 8u to a Git mono-repo might not be as complicated > and risky as it seems. We have to remember that most of the work has > already been done by JEP 296 in jdk10. That process already converted > all the old history and as nobody seems to have been complaining about > it in jdk10 and later, that conversion must have been fine. I.e. The > jdk 10 repository naturally contains the sources of jdk8 from which is > was initially forked (I think at jdk8-b120). > > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: > > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 > > This will give us a mono-repo at the stage of jdk8-b120. Afterwards, > we only have to use the JEP 296 scripts or something equivalent (I > hope that the Oracle build group can assist or at least give some good > advice here :) > > From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created > with the above command, it looks like the "JEP 296" script worked as > follows: > - let's assume were at a changeset which merges all the subrepos at a > specific build tag "jdk8-bXX" (builds were usually tagged weekly, so > every jdk8-bXX tag corresponds to a weekly version). > - sequentially transplant all the changes from a single subrepo up > until the next tag "jdk8-bXX+1" into the new repo > - do this sequentially for all the other sub-repositories > - create a merge change in the new mono-repo which merges all the > newly transplanted changes and tag it with "jdk8-bXX+1" > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are > bit-wise equal to the sources of the jdk8u forest when every single > repo is synced to the same tag. > - repeat the procedure for all the other jdk8-bXX tags > > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow > the described procedure for all the additional changes between > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. > Needless to say that the Corretto team is fully supporting the > transition of jdk8u from a Mercurial forest to a Git mono-repo and > will be happy to get involved into the process :) > > Best regards, > Volker > > JEP 296 had to relocate all the java code into modules > JEP 296 did not have to retain (and therefore relocate) all of the > java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) > > I don't suppose these differences would be impossible to sort out but I > think they would require some effort. > > regards, > > > Andrew Dinn > ----------- > > From vkempik at azul.com Wed Feb 17 17:32:05 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 17 Feb 2021 17:32:05 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <15fb175913bd4861a788ce1586111fa5@azul.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> <15fb175913bd4861a788ce1586111fa5@azul.com> Message-ID: Hello so the old process, with hg: if backport applies cleanly - do request to backport via jbs, once approved - push it to the repo, preserving original patch metadata (author, etc) new process with skara: if backport appliess cleanly - create pull request, if bot decides its clean - can be integrated without review, then get approval via jbs, then integrate if backport does not apply cleanly - create pull request, wait for it to be reviewed, then get approval via jbs, then integrate issue1: it?s bot who decides if this a clean backport or not, almost clean == not clean issue2 ( small one): clean backport is pushed under the name of backporter, not original author when we only started with skara on jdk13u-dev, clean backports mechanics wasn?t existing yet, so every backport had to be reviewed, slowing us, now it?s a bit easier. Skara is generally good for backports now. You may want to try to backport something into jdk13u-dev to test it yourself before you switch jdk11u-dev to git. Regards, Vladimir. > 17 ????. 2021 ?., ? 19:18, Vladimir Kempik ???????(?): > > Hello > > We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace. > > Regards, Vladimir. > > Volker Simonis 17 ??????? 2021 ?. 16:54:46 ???????: > > Hi Erik^2 :) > > thank you so much for the detailed description. I'm especially excited > that you've already published fully consolidated mono-repos for jdk 6 > to 9. That's really very much appreciated! > > Now that the heavy lifting has been done, I hope we can seriously > consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what > blockers are you still seeing? Is there anything the community can > help with to speedup the migration? > > Thank you and best regards, > Volker > > On Tue, Feb 16, 2021 at 8:31 PM wrote: > > Hello, > > As you may have seen, Erik Duveblad just posted about our prototype > conversions on skara-dev [1]. These are based on the same kind of > forest->mono repo conversion, followed by hg->git conversion that > mainline went through. > > I have been working for a while now on adapting the scripts from JEP 296 > to work for the old update releases. This has required more work than I > first anticipated as the problem now requires a more generalized > solution, but I believe I now have something that works reasonably well. > If you are curious on the details, please continue reading. > > Volker's description of the processes is pretty accurate on a high > level. The main difference in 8u compared to a main release is that the > tags are not sequential in history. This means that we can't transplant > (or splice as it's called in Mercurial terms) changes as freely on top > of each tagged change. In the original JDK 10 consolidation, we had a > handful of changes that weren't linear (around the transition between > JDK 9 and 10), and I handled them differently (basically just merging > them together to recreate the point in history, but not splicing > anything on top afterwards). Since they were only a handful, I could > just list them out explicitly in the script. For 8u, a majority of the > tags are non linear, so a big problem was creating an algorithm that > would automatically figure out a reasonable line of tags in sequence > that I could use to splice changes on top of. > > Another big problem is that there are often tags merged together in > different order in different repos. When this happens, the script needs > to figure out the best order to do the conversion. I have tried to > automate this process as much as possible. The ordering is sensitive > when some of the tags are used to splice changes on top of them. There > are also cases of tags missing completely. > > In the end, the state of the mono repo at each tag is verified to be > exactly the same as the forest of repos at each tag. The state of > changes between tags is however less predictable in 8u compared to > mainline due to the large amount of non linear tags. > > For the extra curious, here is what the current algorithm for choosing > the "splice tags" looks like: > > 1. Start with the first tag > > 2. Continue with each consecutive build for current release until a gap > in build numbers is detected (we typically have update release builds > b30 that probably aren't that interesting) > > 3. Find the next release in order and then find the first tag in that > release that is also a descendant of the previous splice tag in every repo. > > 4. Repeat from 2 until all tags have been considered. > > /Erik > > [1] > https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html > > On 2021-02-12 13:33, Volker Simonis wrote: > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn wrote: > On 12/02/2021 16:37, Severin Gehwolf wrote: > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some > more thought than 11u. > That's what I was thinking. > > My preference would be to do it in steps: > 1.) HG forest -> monorepo conversion (using JEP 296 scripts) > 2.) HG -> git conversion using Skara tooling (should take care of > proper metadata, etc.) > Yes, I think this is the right way to go about it. If nothing else > because the tools for the second step assumed that the first one had > happened. > > The really tricky differences I see happen at step 1 (although they > might have a knock-on effect at step 2) > > I think converting 8u to a Git mono-repo might not be as complicated > and risky as it seems. We have to remember that most of the work has > already been done by JEP 296 in jdk10. That process already converted > all the old history and as nobody seems to have been complaining about > it in jdk10 and later, that conversion must have been fine. I.e. The > jdk 10 repository naturally contains the sources of jdk8 from which is > was initially forked (I think at jdk8-b120). > > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120: > > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120 > > This will give us a mono-repo at the stage of jdk8-b120. Afterwards, > we only have to use the JEP 296 scripts or something equivalent (I > hope that the Oracle build group can assist or at least give some good > advice here :) > > From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created > with the above command, it looks like the "JEP 296" script worked as > follows: > - let's assume were at a changeset which merges all the subrepos at a > specific build tag "jdk8-bXX" (builds were usually tagged weekly, so > every jdk8-bXX tag corresponds to a weekly version). > - sequentially transplant all the changes from a single subrepo up > until the next tag "jdk8-bXX+1" into the new repo > - do this sequentially for all the other sub-repositories > - create a merge change in the new mono-repo which merges all the > newly transplanted changes and tag it with "jdk8-bXX+1" > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are > bit-wise equal to the sources of the jdk8u forest when every single > repo is synced to the same tag. > - repeat the procedure for all the other jdk8-bXX tags > > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow > the described procedure for all the additional changes between > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest. > Needless to say that the Corretto team is fully supporting the > transition of jdk8u from a Mercurial forest to a Git mono-repo and > will be happy to get involved into the process :) > > Best regards, > Volker > > JEP 296 had to relocate all the java code into modules > JEP 296 did not have to retain (and therefore relocate) all of the > java code we need to keep in jdk8u (corba?, jaxb?, jaxws?) > > I don't suppose these differences would be impossible to sort out but I > think they would require some effort. > > regards, > > > Andrew Dinn > ----------- > From christoph.langer at sap.com Wed Feb 17 21:26:01 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Feb 2021 21:26:01 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> <15fb175913bd4861a788ce1586111fa5@azul.com> Message-ID: Hi Vladimir, > so the old process, with hg: > if backport applies cleanly - do request to backport via jbs, once approved - > push it to the repo, preserving original patch metadata (author, etc) > > new process with skara: > if backport appliess cleanly - create pull request, if bot decides its clean - can > be integrated without review, then get approval via jbs, then integrate > if backport does not apply cleanly - create pull request, wait for it to be > reviewed, then get approval via jbs, then integrate > > issue1: it?s bot who decides if this a clean backport or not, almost clean == > not clean When we had a call with the Skara team, we talked about this point. For the case when the bot doesn't identify a backport as clean but we'd usually argue that it's a clean backport since e.g. only copyright headers changed or similar, we asked for a command to override the bot's decision. E.g. comment the PR with "/clean" or something like that. I don't know how the status of this development item is, though. Anyway, even if such a "/clean" command isn't available, I'd rather think this wouldn't mean a big slowdown. You'd just have to find some reviewer to approve the PR. > issue2 ( small one): clean backport is pushed under the name of backporter, > not original author This is a change of paradigm with the Skara tooling. A backport is now always attributed to the backporter which is something that several people involved in JDK updates backporting were asking for. So I wouldn't consider that as an issue, rather an improvement. > when we only started with skara on jdk13u-dev, clean backports mechanics > wasn?t existing yet, so every backport had to be reviewed, slowing us, now > it?s a bit easier. > > Skara is generally good for backports now. You may want to try to backport > something into jdk13u-dev to test it yourself before you switch jdk11u-dev > to git. Thanks for your insights! Cheers Christoph From christoph.langer at sap.com Wed Feb 17 21:46:40 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Feb 2021 21:46:40 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: Hi all, collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ?? If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle. I'll seek to get answers to some open questions: - How do Merge PRs work? - Will "git bundle" work for the CPU process? - What about "git backport" and the "/backport" command in github? - What's the status of "clean" backports? This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important. If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course. Sounds ok? (No response means yes ??) Best regards Christoph PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev... > -----Original Message----- > From: Andrew Haley > Sent: Donnerstag, 11. Februar 2021 14:47 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Severin Gehwolf > > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > 11.0.13 cycle > > [Add: jdk8u-dev] > > On 10/02/2021 16:39, Langer, Christoph wrote: > > This is why we think the project should move to git: > > I have no objection to this, but it's important to reach consensus, > which ISO defines as > > General agreement, characterized by the absence of sustained opposition > to substantial issues by any important part of the concerned interests > and by a process that involves seeking to take into account the views > of all parties concerned and to reconcile any conflicting arguments > Consensus need not imply unanimity. > > It's also important not to consider 11 in isolation: while we do not > need to move 8 and 11 simultaneously, I very much do not want to see > them use different workflows for a long period. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Feb 17 23:14:48 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Feb 2021 23:14:48 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23> Message-ID: Hi, I?m sorry but this objection/question isn?t valid for this thread. For a general discussion on whether OpenJDK development should be possible without GitHub Lock-In, you could start a discussion on the discuss or jdk-dev mailing lists at a general project level. But the update releases will have to follow the mainline infrastructure. Cheers Christoph From: gouessej at orange.fr Sent: Mittwoch, 17. Februar 2021 23:27 To: Langer, Christoph ; Andrew Haley ; jdk-updates-dev at openjdk.java.net Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz ; Severin Gehwolf Subject: RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle Hello No, it's not ok. I'd add "How to contribute without using a Github account?". > Message du 17/02/21 22:47 > De : "Langer, Christoph" > > A : "Andrew Haley" >, "jdk-updates-dev at openjdk.java.net" > > Copie ? : "jdk8u-dev at openjdk.java.net" >, "Lindenmaier, Goetz" >, "Severin Gehwolf" > > Objet : RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle > > Hi all, > > collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ?? > > If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle. > > I'll seek to get answers to some open questions: > - How do Merge PRs work? > - Will "git bundle" work for the CPU process? > - What about "git backport" and the "/backport" command in github? > - What's the status of "clean" backports? > > This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important. > > If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course. > > Sounds ok? (No response means yes ??) > > Best regards > Christoph > > PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev... > > > > -----Original Message----- > > From: Andrew Haley > > > Sent: Donnerstag, 11. Februar 2021 14:47 > > To: Langer, Christoph >; jdk-updates- > > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Cc: Lindenmaier, Goetz >; Severin Gehwolf > > > > > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > > 11.0.13 cycle > > > > [Add: jdk8u-dev] > > > > On 10/02/2021 16:39, Langer, Christoph wrote: > > > This is why we think the project should move to git: > > > > I have no objection to this, but it's important to reach consensus, > > which ISO defines as > > > > General agreement, characterized by the absence of sustained opposition > > to substantial issues by any important part of the concerned interests > > and by a process that involves seeking to take into account the views > > of all parties concerned and to reconcile any conflicting arguments > > Consensus need not imply unanimity. > > > > It's also important not to consider 11 in isolation: while we do not > > need to move 8 and 11 simultaneously, I very much do not want to see > > them use different workflows for a long period. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From hohensee at amazon.com Wed Feb 17 23:53:11 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Feb 2021 23:53:11 +0000 Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 Message-ID: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com> What you've got looks good. Do you in addition want to other changes, i.e., the patches that switch from using sun.awt.Toolkit to using the Robot test/java/awt/Focus/8073453/AWTFocusTransitionTest.java test/java/awt/Focus/8073453/SwingFocusTransitionTest.java the comment change in test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java two other new tests test/java/awt/font/GlyphVector/TestLayoutFlags.java test/java/awt/font/Underline/UnderlineTest.java and the patch to test/java/awt/xembed/server/TestXEmbedServer.java Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Andrew Hughes Date: Tuesday, February 16, 2021 at 9:56 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 Bugs: https://bugs.openjdk.java.net/browse/JDK-8261867 https://bugs.openjdk.java.net/browse/JDK-8130125 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8261867/webrev.01/ The main focus of JDK-8130125 is irrelevant to 8u, as it concerns the introduction of the module system. However, the change was also used to introduce a number of other test changes and open up three tests [0]. Backporting these tests will increase test coverage in 8u and ease the backport of JDK-8159690.. The webrev above includes a subset of the changes from JDK-8130125, suitable for 8u. [0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 hohensee at amazon.com Wed Feb 17 23:54:08 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Feb 2021 23:54:08 +0000 Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 In-Reply-To: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com> References: <1ABCD1CA-2ACE-4894-A4A4-9A0A95C40624@amazon.com> Message-ID: <8133E657-B987-4830-8E63-97FA54F79A8B@amazon.com> Whoops, sent before noted that test/java/awt/font/GlyphVector/TestLayoutFlags.java test/java/awt/font/Underline/UnderlineTest.java are in your webrev. :) ?-----Original Message----- From: "Hohensee, Paul" Date: Wednesday, February 17, 2021 at 3:53 PM To: Andrew Hughes , "jdk8u-dev at openjdk.java.net" Subject: Re: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 What you've got looks good. Do you in addition want to other changes, i.e., the patches that switch from using sun.awt.Toolkit to using the Robot test/java/awt/Focus/8073453/AWTFocusTransitionTest.java test/java/awt/Focus/8073453/SwingFocusTransitionTest.java the comment change in test/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java two other new tests test/java/awt/font/GlyphVector/TestLayoutFlags.java test/java/awt/font/Underline/UnderlineTest.java and the patch to test/java/awt/xembed/server/TestXEmbedServer.java Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of Andrew Hughes Date: Tuesday, February 16, 2021 at 9:56 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: JDK-8261867: Backport relevant test changes & additions from JDK-8130125 Bugs: https://bugs.openjdk.java.net/browse/JDK-8261867 https://bugs.openjdk.java.net/browse/JDK-8130125 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8261867/webrev.01/ The main focus of JDK-8130125 is irrelevant to 8u, as it concerns the introduction of the module system. However, the change was also used to introduce a number of other test changes and open up three tests [0]. Backporting these tests will increase test coverage in 8u and ease the backport of JDK-8159690.. The webrev above includes a subset of the changes from JDK-8130125, suitable for 8u. [0] https://mail.openjdk.java.net/pipermail/awt-dev/2015-July/009588.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 felix.yang at huawei.com Thu Feb 18 03:25:24 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 18 Feb 2021 03:25:24 +0000 Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event based tracing for monitor inflation Message-ID: Hi, Anyone want to take a look at this? As this adds back "cause" information for the monitor inflation event, it should also improves basic functionality of 8u JFR event-based tracing. Thanks, Felix > -----Original Message----- > From: Yangfei (Felix) > Sent: Tuesday, January 12, 2021 3:39 PM > To: 'jdk8u-dev at openjdk.java.net' > Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event > based tracing for monitor inflation > > Any comments? > > > -----Original Message----- > > From: Yangfei (Felix) > > Sent: Friday, December 18, 2020 8:35 PM > > To: jdk8u-dev at openjdk.java.net > > Subject: RFR: 8258669: fastdebug jvm crashes when do event based > > tracing for monitor inflation > > > > Hi, > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258669 > > Webrev: http://cr.openjdk.java.net/~fyang/8258669/webrev.00 > > > > By referencing jdk11u, I think the reason is that we are not > > setting the "cause" in post_monitor_inflate_event for jdk8u. > > Proposed patch adds back the missing code changes in: 8138562: > > Event based tracing should cover monitor inflation. Also enabled code > > in MonitorInflateCauseConstant::serialize. > > Since this only adds some extra "cause" information for the > > monitor inflation event, I think it should be low risk. > > Performed full jtreg test based on the latest jdk8u-dev. OK? > > > > Thanks, > > Felix From qingfeng.yy at alibaba-inc.com Thu Feb 18 05:26:52 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Thu, 18 Feb 2021 13:26:52 +0800 Subject: =?UTF-8?B?UmU6IFJlOiBQSU5HOiBSRlI6IDh1IGJhY2twb3J0IG9mIEpESy04MjM3NDk5IEpGUjogSW5j?= =?UTF-8?B?bHVkZSBzdGFjayB0cmFjZSBpbiB0aGUgVGhyZWFkU3RhcnQgZXZlbnQ=?= In-Reply-To: <4c526e1a-293b-4216-8576-135871a0d999.qingfeng.yy@alibaba-inc.com> References: <20210202061014.GA120663@rincewind> , <20210203174503.GA264757@rincewind>, <4c526e1a-293b-4216-8576-135871a0d999.qingfeng.yy@alibaba-inc.com> Message-ID: <8eb85206-60c5-44a9-994f-e447b2469b1f.qingfeng.yy@alibaba-inc.com> Gentle Ping v2 :-) ------------------Original Mail ------------------ Sender:Yang Yi Send Date:Thu Feb 4 11:08:39 2021 Recipients:Andrew Hughes CC:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Hi Andrew, Thanks to your explanation, it makes sense, I have updated my patch according to your change. Webrev: HotSpot Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/hotspot-webrev.01/ JDK Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/jdk-webrev/ Cheers, Yang Yi ------------------------------------------------------------------ From:Andrew Hughes Send Time:2021 Feb. 4 (Thu.) 01:45 To:"YANG, Yi" Cc:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On 19:52 Tue 02 Feb , Yang Yi wrote: > Hi Andrew, > > Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? > > Please let me know if I misunderstand your reply. > > Thanks, > Yang Yi > Yes, that's correct. In other words, please add my patch to what you have and provide an updated webrev :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 sgehwolf at redhat.com Thu Feb 18 10:14:45 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Feb 2021 11:14:45 +0100 Subject: [8u] RFR: 8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14 In-Reply-To: <20210217034041.GA641764@rincewind> References: <20210217034041.GA641764@rincewind> Message-ID: <84a05365f7b0edde35de432bd1165f88f99527ff.camel@redhat.com> On Wed, 2021-02-17 at 03:40 +0000, Andrew Hughes wrote: > > > Looks good. Please flag for approval. Thanks for the review! Ready for approval now. Thanks, Severin From sgehwolf at redhat.com Thu Feb 18 10:16:23 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Feb 2021 11:16:23 +0100 Subject: [8u] RFR: 8061777: (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS In-Reply-To: <20210217040012.GB641764@rincewind> References: <5228d4fb05b86363c9d6f1d4ef5939e66c31f8ec.camel@redhat.com> <20210217040012.GB641764@rincewind> Message-ID: On Wed, 2021-02-17 at 04:00 +0000, Andrew Hughes wrote: > On 17:04 Tue 16 Feb???? , Severin Gehwolf wrote: > > Hi, > > > > Please review this zip fs fix. It's a fix Oracle did to their JDK 8 > > too. The JDK 11u patch didn't apply cleanly and required some > > manual > > work. Mostly because: > > > > a) The implementation of ZipFileSystem.getPath() is slightly > > different in 8u. It uses a local String variable 'path' over > > JDK 11's short return approach if more.length == 0. Either way, > > changes shoudl be equivalent. > > I assume you mean JDK 9's, as that is where the patch is from. Ah, yes. Thanks! > The code was changed by JDK-8150496 as an optimisation: > > https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b9ed1a4feefb#l3.82 Nice find. > Please flag for approval. Thanks for the review! It should be ready for approval now. Thanks, Severin From dcherepanov at azul.com Thu Feb 18 12:58:55 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 18 Feb 2021 15:58:55 +0300 Subject: [8u] RFR: 8261952: Avoid converting path to vcruntime140.dll to short-style path Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8261952 Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261952/webrev.v0/ Please review the partial backport for Windows build with VS 2017. This is to avoid converting path to vcruntime140.dll? to short-style path (with vcrunt~1.dll) In JDK 11, it was fixed as a part of https://bugs.openjdk.java.net/browse/JDK-8201267 From original RFR: https://mail.openjdk.java.net/pipermail/build-dev/2018-April/021563.html * In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all ? directories sent in here are already fixed. Calling it here messes up ? the filename of the dll, which in VS2017 is more than 8 chars. Thanks, Dmitry From felix.yang at huawei.com Sat Feb 20 12:49:32 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 20 Feb 2021 12:49:32 +0000 Subject: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory Message-ID: Hi, Please review this 8u aarch64-specific fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8262073 Webrev: http://cr.openjdk.java.net/~fyang/8262073/webrev.00/ Call chain for creating itable stub: create_itable_stub -> load_klass -> decode_klass_not_null -> reinit_heapbase As reported on the issue, we are emitting three instructions in reinit_heapbase for this case: mov, movk and movk. Note that we also emit insns in decode_klass_not_null moving narrow_klass_base into a register. To be safe, I think we should also assume insns for moving narrow_klass_base to be: mov, movk and movk. Patch increases size for both kind of stubs: 16 bytes for itable stub (which calls load_klass twice) and 8 byte for vtable stub (which calls load_klass once). Previously, we reserve extra 216 bytes when DebugVtables is on. This is enough for the itable stub creation case. But this won't work for the vtable stub creation in which case we will exceed the code buffer limit. The reason is that we have two "if (DebugVtables)" blocks in vtable stub creation code. For this case, patch adopts the same way as ppc & sparc: set size to 1000 bytes when those debug options are turned on. Performed full jtreg test on aarch64-linux-gnu. OK? Thanks, Felix From aph at redhat.com Sat Feb 20 18:07:53 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 20 Feb 2021 18:07:53 +0000 Subject: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory In-Reply-To: References: Message-ID: <13ab1a41-f482-7670-8acb-7785f3409ef7@redhat.com> On 20/02/2021 12:49, Yangfei (Felix) wrote: > Performed full jtreg test on aarch64-linux-gnu. OK? OK, looks reasonable. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Sun Feb 21 01:30:50 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sun, 21 Feb 2021 01:30:50 +0000 Subject: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory Message-ID: Hi, Thanks for reviewing this. Flagged for approval. Felix > > On 20/02/2021 12:49, Yangfei (Felix) wrote: > > Performed full jtreg test on aarch64-linux-gnu. OK? > > OK, looks reasonable. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ge.guo at huawei.com Sun Feb 21 09:27:25 2021 From: ge.guo at huawei.com (Guoge(JVM)) Date: Sun, 21 Feb 2021 09:27:25 +0000 Subject: [8u] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 Message-ID: Hi, I would like to request a review for backport of JDK-8240353. Original bug: https://bugs.openjdk.java.net/browse/JDK-8240353 webrev for 8u: http://cr.openjdk.java.net/~gguo/8240353-8u/webrev.00/ The fix is trivial and clean, performed full jtreg test with aarch64 release/fastdebug build. Thanks, Guo Ge From aph at redhat.com Mon Feb 22 10:06:02 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Feb 2021 10:06:02 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com> On 17/02/2021 21:46, Langer, Christoph wrote: > collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ?? > > If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle. > > I'll seek to get answers to some open questions: > - How do Merge PRs work? > - Will "git bundle" work for the CPU process? > - What about "git backport" and the "/backport" command in github? > - What's the status of "clean" backports? That seems like a reasonable list. We need to be sure that OpenJDK Jira and the mailing lists don't miss anything important. Right now we have a log in Jira of the issue being raised, when it gets approved for backport and by whom, and when it gets committed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Feb 22 10:29:57 2021 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 22 Feb 2021 10:29:57 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley > Sent: Montag, 22. Februar 2021 11:06 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > ; Severin Gehwolf > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > 11.0.13 cycle > > On 17/02/2021 21:46, Langer, Christoph wrote: > > collecting the responses in this mail thread so far, I hear that we're about to > reach some kind of consensus with regards to a git switch of JDK11u. ?? > > > > If nobody objects, I will go ahead now and approach the Skara team to > concretely discuss the envisioned switch for the 11.0.13 cycle. > > > > I'll seek to get answers to some open questions: > > - How do Merge PRs work? > > - Will "git bundle" work for the CPU process? > > - What about "git backport" and the "/backport" command in github? > > - What's the status of "clean" backports? > > That seems like a reasonable list. We need to be sure that OpenJDK > Jira and the mailing lists don't miss anything important. Right now > we have a log in Jira of the issue being raised, when it gets approved > for backport and by whom, and when it gets committed. Thanks for the feedback. The points you made here seem to be covered as far as my experiences with Skara backports go, e.g. in 16u. So the approval process will still be handled using the appropriate Jira labels and backport bug items will be created and/or updated by the Skara bots in a way that pretty much resembles what hgupdater has done before. Cheers Christoph From zgu at redhat.com Mon Feb 22 13:42:20 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 22 Feb 2021 08:42:20 -0500 Subject: [8u] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: References: Message-ID: <2970b867-0ecf-bc9f-c69e-81875261d174@redhat.com> On 2/21/21 4:27 AM, Guoge(JVM) wrote: > Hi, > > I would like to request a review for backport of JDK-8240353. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8240353 > webrev for 8u: http://cr.openjdk.java.net/~gguo/8240353-8u/webrev.00/ > > The fix is trivial and clean, performed full jtreg test with aarch64 release/fastdebug build. > If the original patch applies cleanly, you don't need a code review. Please follow instructions [0] for requesting an approval. The same applies to 11u [1]. -Zhengyu [0] https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Contributing [1] http://openjdk.java.net/projects/jdk-updates/approval.html > Thanks, > Guo Ge > From felix.yang at huawei.com Tue Feb 23 01:46:35 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 23 Feb 2021 01:46:35 +0000 Subject: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory In-Reply-To: <13ab1a41-f482-7670-8acb-7785f3409ef7@redhat.com> References: <13ab1a41-f482-7670-8acb-7785f3409ef7@redhat.com> Message-ID: Hi again, > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Sunday, February 21, 2021 2:08 AM > To: jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer > memory > > On 20/02/2021 12:49, Yangfei (Felix) wrote: > > Performed full jtreg test on aarch64-linux-gnu. OK? > > OK, looks reasonable. May I ask to make one more change here? In addition to rework vtable/itable stub size calculation, JDK-8207343 introduced this safety check [1] in aarch64 during itable stub creation. With this change, we won't use CodeCache for itable stub allocations if it is already full instead of failing the entire VM. For aarch64 8u, we already have the check for vtable stub creation, I think we should also add same check for itable stub case to be safe. New webrev adding this extra check: http://cr.openjdk.java.net/~fyang/8262073/webrev.01/ Still passed full jtreg test. [1] http://hg.openjdk.java.net/jdk/jdk/rev/54b344d9dd4e#l1.122 Thanks, Felix From aph at redhat.com Tue Feb 23 09:24:14 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 23 Feb 2021 09:24:14 +0000 Subject: RFR: 8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory In-Reply-To: References: <13ab1a41-f482-7670-8acb-7785f3409ef7@redhat.com> Message-ID: <430f19f8-8571-fad4-9e63-05b752e3f220@redhat.com> On 23/02/2021 01:46, Yangfei (Felix) wrote: > For aarch64 8u, we already have the check for vtable stub creation, I think we should also add same check for itable stub case to be safe. > New webrev adding this extra check: http://cr.openjdk.java.net/~fyang/8262073/webrev.01/ > Still passed full jtreg test. Sure. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Tue Feb 23 10:36:16 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 23 Feb 2021 10:36:16 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com> Message-ID: Hi, I have done my first jdk16u backport according to [1] and it has worked pretty smoothly even without Skara CLI tools. It will certainly be even simpler when using them. So I appreciate establishing the same backport process for 11u. It would be great to have the same backport process for all update releases, especially when we need to backport the same fix to several update releases. Thanks and best regards, Martin [1] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-BackportPullRequests > -----Original Message----- > From: jdk8u-dev On Behalf Of Langer, > Christoph > Sent: Montag, 22. Februar 2021 11:30 > To: Andrew Haley ; jdk-updates-dev at openjdk.java.net > Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > ; Severin Gehwolf > Subject: RE: [11u] Proposal: Switch jdk11u development to Git/Skara with > 11.0.13 cycle > > Hi, > > > -----Original Message----- > > From: Andrew Haley > > Sent: Montag, 22. Februar 2021 11:06 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net > > Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > > ; Severin Gehwolf > > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > > 11.0.13 cycle > > > > On 17/02/2021 21:46, Langer, Christoph wrote: > > > collecting the responses in this mail thread so far, I hear that we're about > to > > reach some kind of consensus with regards to a git switch of JDK11u. ?? > > > > > > If nobody objects, I will go ahead now and approach the Skara team to > > concretely discuss the envisioned switch for the 11.0.13 cycle. > > > > > > I'll seek to get answers to some open questions: > > > - How do Merge PRs work? > > > - Will "git bundle" work for the CPU process? > > > - What about "git backport" and the "/backport" command in github? > > > - What's the status of "clean" backports? > > > > That seems like a reasonable list. We need to be sure that OpenJDK > > Jira and the mailing lists don't miss anything important. Right now > > we have a log in Jira of the issue being raised, when it gets approved > > for backport and by whom, and when it gets committed. > > Thanks for the feedback. The points you made here seem to be covered as > far as my experiences with Skara backports go, e.g. in 16u. So the approval > process will still be handled using the appropriate Jira labels and backport bug > items will be created and/or updated by the Skara bots in a way that pretty > much resembles what hgupdater has done before. > > Cheers > Christoph From gnu.andrew at redhat.com Wed Feb 24 06:02:38 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Feb 2021 06:02:38 +0000 Subject: [8u] RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f Message-ID: <20210224060238.GA1121302@rincewind> Bug: https://bugs.openjdk.java.net/browse/JDK-8259048 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8259048/webrev.01/ Usual update for the in-tree tzdata update. Although I did the update manually from the rearguard version of the tzdata2020f data, there is no difference between the patch for the files in make in 11u and those in this 8u patch. The only difference between the patches as a whole is 8u has the changes duplicated in the test subdirectory. Tests for sun.util.calendar and java.time.test all passed on the patched build. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 aph at redhat.com Wed Feb 24 10:32:55 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Feb 2021 10:32:55 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com> Message-ID: <4b282384-0fff-9a32-d6cf-bfd3fd9e31c1@redhat.com> On 23/02/2021 10:36, Doerr, Martin wrote: > I have done my first jdk16u backport according to [1] and it has worked pretty smoothly even without Skara CLI tools. > It will certainly be even simpler when using them. > So I appreciate establishing the same backport process for 11u. It would be great to have the same backport process for all update releases, especially when we need to backport the same fix to several update releases. OK, thanks for letting us know. Sounds good. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Feb 24 10:57:01 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Feb 2021 10:57:01 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com> <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com> <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com> <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com> Message-ID: <90476fae-3ffb-1661-cb2c-06fe99b5ff6a@redhat.com> On 17/02/2021 15:19, Lindenmaier, Goetz wrote: > I think it is about time to start a thread of its own to discuss this for 8. We've already been discussing 8, and there is some disagreement. We must move 8 to Skara eventually, but it can wait until we have some experience with 11. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Wed Feb 24 21:42:06 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Feb 2021 21:42:06 +0000 Subject: [8u]: 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw Message-ID: <23F50014-34FB-425F-84CB-CD8F2BE7A227@amazon.com> Please review this test-only backport. The JBS issue is private, so I can?t create a backport issue. We?ll have to rely on hg-updater when pushed, and maintainer approval will have to be on the list. Original patch: http://hg.openjdk.java.net/jdk-updates/jdk9u/jdk/rev/ddc8bbf88d36 8u webrev: http://cr.openjdk.java.net/~phh/8136592/webrev.8u.jdk.02/ The @modules attributes have been removed, and implicit casts have been replaced by explicit ones to XEmbedCanvasPeer, FramePeer, and ListPeer. The first two required importing sun.awt.X11.*. The two new tests pass. Thanks, Paul From gnu.andrew at redhat.com Thu Feb 25 05:01:51 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 25 Feb 2021 05:01:51 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com> Message-ID: <20210225050151.GA1162457@rincewind> On 18:52 Fri 12 Feb , Andrew Haley wrote: > On 12/02/2021 07:15, Andrew Hughes wrote: > > even been released yet. Why the rush? > > > > I don't see any reason at all to start altering 8u at such a late > > stage in its development. All risk and no gain. > > > > [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241 > > We've always been a bit short of boots on the ground, and being > stuck on an obsolete VCS will only isolate 8u even more. Maybe this > is an optimist-versus-pessimist thing, but 8u may be about halfway > through its lifetime! > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > Since when is Mercurial obsolete? Looking at its Wikipedia page, it seems to have had a new release more recently than OpenJDK! Are there people who want to contribute to 8u, but are being prevented by the choice of version control system? It seems unlikely to me. I'm much more concerned about the disruption a change would cause to those who already contribute to 8u. That goes further than just developers active on this mailing list. It includes many people testing it and distributing it via various channels. Over the course of the last week, I've had to redirect two IcedTea bugs that will filed for IcedTea-Web, which moved to a git repository elsewhere some time ago, and take over our update to 16u, which was initially pointing at the last Mercurial sources, which apparently are still around to cause confusion. In short, it takes time for such changes to filter to all concerned and the impact is more extensive than it may initially appear. There are really two issues here. The first is the choice of version control system. As one of the people who has to do more with the repositories than just pushing my own patches, I'm probably more aware of the failings of Mercurial than some. In particular, 11u's use of a mono repository is painfully slow in Mercurial. 8u, on the other hand, would likely be slower as a git mono repository than the current individual Mercurial repositories. However, I don't see the great rush to switch to git. The potential disruption that would cause seems greater than the pains of Mercurial. What baffles me about OpenJDK's use of git is why the main advantage of branches hasn't been used, and update repositories are being created as separate trees as before. The obvious advantage of using git to me would be to have one repository with multiple branches and thus fewer things to check out. However, as someone who already uses git for other projects, I wouldn't have a problem with our repositories using it; my concern there is more for the impact downstream and on those not familiar with git. My much greater concern is we don't seem to be apply to just switch VCS, but have to adopt a completely different set of processes as well, which are frankly more confusing, less trustworthy and still seem to be heavily in development. If we could just switch to git without this SKARA thing, I'd be much less concerned. As it stands, SKARA has not yet even been used to produce a new OpenJDK release, yet there seems to be some bizarre rush to use it on production update releases. I really don't understand this and I've put off even replying to this thread because it's making me quite angry. Are we expecting all the Mercurial trees to vanish by the end of the year? I can't otherwise see why we need to jump on this so quickly. Reading other comments on this thread, it seems backporting support isn't yet ready in SKARA. If so, why are we even considering switching to it so soon? My own experience is that I still have a bug pending to backport to 13u & 16u and no idea how to do it. Pushing it to 11u was trivial. Why do we want to make lives harder for ourselves? -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 Thu Feb 25 05:06:37 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 25 Feb 2021 05:06:37 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> Message-ID: <20210225050637.GB1162457@rincewind> On 08:38 Fri 12 Feb , Langer, Christoph wrote: > Hi Andrew, > > you have valid concerns which I hope we can get sorted out until the proposed 11u switch. Let me answer in detail: > > > I have still not seen any answer to my question of how a bulk update is > > pushed for the CPU. > > I think generally this is kind of answered. For the 11u <-> 11u-dev merges we can use a facility called "Merge PR", something like people used to merge jdk16 back into jdk [0]. > Although I've not yet done it myself and will need to talk to Skara folks to get it explained better, I think this is what we can use. > > For working on the CPU I hope to be able to use "git bundle" to distribute the state of work on vuln-dev (Similar to what we do with hg bundle now) and eventually push the release via a Merge PR. I will explore this in detail in the next weeks and see if it's bound to work. In case I don't see it working, I'd consider it a showstopper. So I'll update you on this soon, in time before the advised github switch. > > > My own attempts to backport to jdk13u suggest the tooling still needs > > work on this, or at least better documentation. [0] > > I think you have a point here. As far as I know the "git backport" command does not exist yet and also the process to backport a change by commenting "/backport" on the original change in the jdk repository is not activated yet. I've brought this up to the skara team and they said that they hope to be able to enable it soon [1]. At the moment a backport would work like documented in the manual steps of this link [2] - which is not too convenient. I'll approach Skara folks again about that. > This all sounds like deploying this in just four months is too soon for me. Why not allow Skara to mature first, if we must use it at all? Can we not just switch 11u to git only and retain the existing processes that work fine? > > OpenJDK 16, the first release to use git during development, has not > > even been released yet. Why the rush? > > Well, I would not consider it to be in a rush, given the proposal of switching in about 4 months from now. But overall, to align processes, to me it seems favorable to go to git with 11u and we should not overly delay it. At that time JDK16 and its first update release 16.0.1 will have been delivered out of git (as well as a few jdk13u update releases). > It's less git I'm concerned about, than that it seems to bring along Skara with it. I found jcheck painful enough with Mercurial. Skara terrifies me and seems to steal a lot of control away from us. > > I don't see any reason at all to start altering 8u at such a late > > stage in its development. All risk and no gain. > > That's a different discussion which I won't take part in as I'm not involved so much in 8u. The only point I have on that is that there's no reason to couple the decisions for 8 and 11, as was stated by Severin and Goetz already. > No, I agree on that. 8u is quite different and doesn't suffer from the painfully slow monorepo 11u does. > Best regards > Christoph > > [0] https://github.com/openjdk/jdk/pull/2392 > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-January/004051.html > [2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI > -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 hedongbo at huawei.com Thu Feb 25 07:48:39 2021 From: hedongbo at huawei.com (hedongbo) Date: Thu, 25 Feb 2021 07:48:39 +0000 Subject: FW: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream Message-ID: <8FC616E5EC1A774287430B1CC2696FE304788C1E@dggeml513-mbx.china.huawei.com> Ping? From: hedongbo Sent: Friday, February 5, 2021 10:27 AM To: 'jdk8u-dev' Subject: RFR: [8u] 6878250: (so) IllegalBlockingModeException thrown when reading from a closed SocketChannel's InputStream Hi, Please help review this changes. webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-6878250 related bug: https://bugs.openjdk.java.net/browse/JDK-8260875 related thread: https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008123.html Thanks, dongbohe From goetz.lindenmaier at sap.com Thu Feb 25 08:12:42 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 25 Feb 2021 08:12:42 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <20210225050637.GB1162457@rincewind> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> <20210225050637.GB1162457@rincewind> Message-ID: Hi, could you please start a mail thread of its own for discussing the move of 8u to git? This mail thread is about moving 11u to git. Best regards, Goetz. > -----Original Message----- > From: Andrew Hughes > Sent: Thursday, February 25, 2021 6:07 AM > To: Langer, Christoph > Cc: Andrew Haley ; jdk-updates-dev at openjdk.java.net; > jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz > ; Severin Gehwolf > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > 11.0.13 cycle > > On 08:38 Fri 12 Feb , Langer, Christoph wrote: > > Hi Andrew, > > > > you have valid concerns which I hope we can get sorted out until the > proposed 11u switch. Let me answer in detail: > > > > > I have still not seen any answer to my question of how a bulk update is > > > pushed for the CPU. > > > > I think generally this is kind of answered. For the 11u <-> 11u-dev merges > we can use a facility called "Merge PR", something like people used to merge > jdk16 back into jdk [0]. > > Although I've not yet done it myself and will need to talk to Skara folks to > get it explained better, I think this is what we can use. > > > > For working on the CPU I hope to be able to use "git bundle" to distribute > the state of work on vuln-dev (Similar to what we do with hg bundle now) > and eventually push the release via a Merge PR. I will explore this in detail in > the next weeks and see if it's bound to work. In case I don't see it working, > I'd consider it a showstopper. So I'll update you on this soon, in time before > the advised github switch. > > > > > My own attempts to backport to jdk13u suggest the tooling still needs > > > work on this, or at least better documentation. [0] > > > > I think you have a point here. As far as I know the "git backport" command > does not exist yet and also the process to backport a change by commenting > "/backport" on the original change in the jdk repository is not activated yet. > I've brought this up to the skara team and they said that they hope to be able > to enable it soon [1]. At the moment a backport would work like > documented in the manual steps of this link [2] - which is not too convenient. > I'll approach Skara folks again about that. > > > > This all sounds like deploying this in just four months is too soon > for me. Why not allow Skara to mature first, if we must use it at all? > > Can we not just switch 11u to git only and retain the existing processes that > work fine? > > > > OpenJDK 16, the first release to use git during development, has not > > > even been released yet. Why the rush? > > > > Well, I would not consider it to be in a rush, given the proposal of switching > in about 4 months from now. But overall, to align processes, to me it seems > favorable to go to git with 11u and we should not overly delay it. At that time > JDK16 and its first update release 16.0.1 will have been delivered out of git > (as well as a few jdk13u update releases). > > > > It's less git I'm concerned about, than that it seems to bring along > Skara with it. I found jcheck painful enough with Mercurial. Skara > terrifies me and seems to steal a lot of control away from us. > > > > I don't see any reason at all to start altering 8u at such a late > > > stage in its development. All risk and no gain. > > > > That's a different discussion which I won't take part in as I'm not involved > so much in 8u. The only point I have on that is that there's no reason to > couple the decisions for 8 and 11, as was stated by Severin and Goetz already. > > > > No, I agree on that. 8u is quite different and doesn't suffer from the painfully > slow monorepo 11u does. > > > Best regards > > Christoph > > > > [0] https://github.com/openjdk/jdk/pull/2392 > > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021- > January/004051.html > > [2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI > > > > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 aph at redhat.com Thu Feb 25 10:08:03 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Feb 2021 10:08:03 +0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: <20210225050151.GA1162457@rincewind> References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com> <20210225050151.GA1162457@rincewind> Message-ID: On 25/02/2021 05:01, Andrew Hughes wrote: > On 18:52 Fri 12 Feb , Andrew Haley wrote: >> On 12/02/2021 07:15, Andrew Hughes wrote: >>> even been released yet. Why the rush? Who's rushing? All we're doing right now is talking. >>> I don't see any reason at all to start altering 8u at such a late >>> stage in its development. All risk and no gain. >>> >>> [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241 >> >> We've always been a bit short of boots on the ground, and being >> stuck on an obsolete VCS will only isolate 8u even more. Maybe this >> is an optimist-versus-pessimist thing, but 8u may be about halfway >> through its lifetime! > > Since when is Mercurial obsolete? Looking at its Wikipedia page, it > seems to have had a new release more recently than OpenJDK! It's very slow and doesn't scale well, and is rapidly losing out to Git. Its maintainers may heroically try to keep it going, but it's obsolescent now and will be obsolete some time during the life of OpenJDK 8. > Are there people who want to contribute to 8u, but are being prevented > by the choice of version control system? It seems unlikely to me. I'm thinking of a contributor who wants to push a bug fix through to all supported versions of OpenJDK. I don't want to put roadblocks in their way. I very much expect that anyone who joins OpenJDK today will *never* use Mercurial, for anything. This means that they'll either need a proxy to push their patch to 8u or it simply won't get fixed. > I'm much more concerned about the disruption a change would cause to > those who already contribute to 8u. That's a general-purpose argument against any change, even one that is in the long (or even medium) term beneficial. But Skara has proved to be a huge improvement in workflow across all of OpenJDK active development, such that it makes no sense to starve 8u forever of its benefits. Now, it doesn't work so well with backports; they have not been Skara's primary goal, that is true. But Skara development is moving fast, and I expect there will be a good backport process soon. > There are really two issues here. The first is the choice of version > control system. As one of the people who has to do more with the > repositories than just pushing my own patches, I'm probably more > aware of the failings of Mercurial than some. In particular, 11u's > use of a mono repository is painfully slow in Mercurial. 8u, on the > other hand, would likely be slower as a git mono repository than the > current individual Mercurial repositories. Maybe, but I doubt it. > However, I don't see the great rush to switch to git. The potential > disruption that would cause seems greater than the pains of > Mercurial. > What baffles me about OpenJDK's use of git is why the main advantage > of branches hasn't been used, and update repositories are being > created as separate trees as before. The obvious advantage of using > git to me would be to have one repository with multiple branches and > thus fewer things to check out. Having many individual forks is the GitHub way of working. It works well, IMO better than multiple branches would, but that's another discussion. > However, as someone who already uses git for other projects, I > wouldn't have a problem with our repositories using it; my concern > there is more for the impact downstream and on those not familiar > with git. My much greater concern is we don't seem to be apply to > just switch VCS, but have to adopt a completely different set of > processes as well, which are frankly more confusing, less > trustworthy and still seem to be heavily in development. > > If we could just switch to git without this SKARA thing, I'd be much > less concerned. OK. So let's do that to start with, and see how it goes. We don't have to use the Skara tooling if we don't want to. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Thu Feb 25 14:56:31 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 25 Feb 2021 15:56:31 +0100 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> <20210212071559.GC340416@rincewind> <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com> <20210225050151.GA1162457@rincewind> Message-ID: On Thu, Feb 25, 2021 at 11:08 AM Andrew Haley wrote: > > On 25/02/2021 05:01, Andrew Hughes wrote: > > On 18:52 Fri 12 Feb , Andrew Haley wrote: > >> On 12/02/2021 07:15, Andrew Hughes wrote: > >>> even been released yet. Why the rush? > > Who's rushing? All we're doing right now is talking. > > >>> I don't see any reason at all to start altering 8u at such a late > >>> stage in its development. All risk and no gain. > >>> > >>> [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241 > >> > >> We've always been a bit short of boots on the ground, and being > >> stuck on an obsolete VCS will only isolate 8u even more. Maybe this > >> is an optimist-versus-pessimist thing, but 8u may be about halfway > >> through its lifetime! > > > > Since when is Mercurial obsolete? Looking at its Wikipedia page, it > > seems to have had a new release more recently than OpenJDK! > > It's very slow and doesn't scale well, and is rapidly losing out to > Git. Its maintainers may heroically try to keep it going, but it's > obsolescent now and will be obsolete some time during the life of > OpenJDK 8. > > > Are there people who want to contribute to 8u, but are being prevented > > by the choice of version control system? It seems unlikely to me. > > I'm thinking of a contributor who wants to push a bug fix through to > all supported versions of OpenJDK. I don't want to put roadblocks in > their way. I very much expect that anyone who joins OpenJDK today will > *never* use Mercurial, for anything. This means that they'll either > need a proxy to push their patch to 8u or it simply won't get fixed. > > > I'm much more concerned about the disruption a change would cause to > > those who already contribute to 8u. > It might also be worth mentioning that at least three major downstream distributions (AdoptOpenJDK, SapMachine and Corretto) already use GitHub to manage their update releases and each of them on their own already convert the up-stream Mercurial repositories to Git. > That's a general-purpose argument against any change, even one that is > in the long (or even medium) term beneficial. But Skara has proved to > be a huge improvement in workflow across all of OpenJDK active > development, such that it makes no sense to starve 8u forever of its > benefits. Now, it doesn't work so well with backports; they have not > been Skara's primary goal, that is true. But Skara development is > moving fast, and I expect there will be a good backport process soon. > > > There are really two issues here. The first is the choice of version > > control system. As one of the people who has to do more with the > > repositories than just pushing my own patches, I'm probably more > > aware of the failings of Mercurial than some. In particular, 11u's > > use of a mono repository is painfully slow in Mercurial. 8u, on the > > other hand, would likely be slower as a git mono repository than the > > current individual Mercurial repositories. > > Maybe, but I doubt it. > > > However, I don't see the great rush to switch to git. The potential > > disruption that would cause seems greater than the pains of > > Mercurial. > > > What baffles me about OpenJDK's use of git is why the main advantage > > of branches hasn't been used, and update repositories are being > > created as separate trees as before. The obvious advantage of using > > git to me would be to have one repository with multiple branches and > > thus fewer things to check out. > > Having many individual forks is the GitHub way of working. It works > well, IMO better than multiple branches would, but that's another > discussion. > > > However, as someone who already uses git for other projects, I > > wouldn't have a problem with our repositories using it; my concern > > there is more for the impact downstream and on those not familiar > > with git. My much greater concern is we don't seem to be apply to > > just switch VCS, but have to adopt a completely different set of > > processes as well, which are frankly more confusing, less > > trustworthy and still seem to be heavily in development. > > > > If we could just switch to git without this SKARA thing, I'd be much > > less concerned. > > OK. So let's do that to start with, and see how it goes. We don't have > to use the Skara tooling if we don't want to. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From gouessej at orange.fr Wed Feb 17 22:26:41 2021 From: gouessej at orange.fr (gouessej at orange.fr) Date: Wed, 17 Feb 2021 22:26:41 -0000 Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle In-Reply-To: References: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com> Message-ID: <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23> Hello ? No, it's not ok. I'd add "How to contribute without using a Github account?". ? ? > Message du 17/02/21 22:47 > De : "Langer, Christoph" > A : "Andrew Haley" , "jdk-updates-dev at openjdk.java.net" > Copie ? : "jdk8u-dev at openjdk.java.net" , "Lindenmaier, Goetz" , "Severin Gehwolf" > Objet : RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle > > Hi all, > > collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ?? > > If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle. > > I'll seek to get answers to some open questions: > - How do Merge PRs work? > - Will "git bundle" work for the CPU process? > - What about "git backport" and the "/backport" command in github? > - What's the status of "clean" backports? > > This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important. > > If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course. > > Sounds ok? (No response means yes ??) > > Best regards > Christoph > > PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev... > > > > -----Original Message----- > > From: Andrew Haley > > Sent: Donnerstag, 11. Februar 2021 14:47 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Cc: Lindenmaier, Goetz ; Severin Gehwolf > > > > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with > > 11.0.13 cycle > > > > [Add: jdk8u-dev] > > > > On 10/02/2021 16:39, Langer, Christoph wrote: > > > This is why we think the project should move to git: > > > > I have no objection to this, but it's important to reach consensus, > > which ISO defines as > > > > General agreement, characterized by the absence of sustained opposition > > to substantial issues by any important part of the concerned interests > > and by a process that involves seeking to take into account the views > > of all parties concerned and to reconcile any conflicting arguments > > Consensus need not imply unanimity. > > > > It's also important not to consider 11 in isolation: while we do not > > need to move 8 and 11 simultaneously, I very much do not want to see > > them use different workflows for a long period. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > >