From james.laskey at oracle.com Fri Feb 3 14:07:21 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 3 Feb 2023 14:07:21 +0000 Subject: Result: New amber Committer: Adam Sotona In-Reply-To: References: Message-ID: <7A0B2AC4-4764-40F4-AF06-EC9E42EA0D2F@oracle.com> Voting for Adam Sotona [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.org/pipermail/amber-dev/2023-January/007700.html On Jan 18, 2023, at 2:00 PM, Jim Laskey wrote: I hereby nominate Adam Sotona [asotona] as a committer in the amber Project. Adam Sotona[1] is a member of Oracle's JDK LangTools team and a committer of the jdk project; working on javac, javap, jshell, new classfile[2] and related API and tools. He has made about 40 changes [3][4] to the OpenJDK repository. Votes are due by 20:00 UTC February 1, 2023. Only current committers and reviewers of the amber Project [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [6]. Jim Laskey [1] https://openjdk.org/census#asotona [2] https://github.com/openjdk/jdk/pull/10982 [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Sotona%22&type=commits [4] git log --author="Adam Sotona" --format='%h %s' [5] https://openjdk.org/census#amber [6] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Feb 7 23:38:56 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Feb 2023 18:38:56 -0500 Subject: CFV: New amber Committer: Archie Cobbs Message-ID: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> I hereby nominate Archie Cobbs [acobbs] as a committer in the amber Project. Archie Cobbs [1] is an author of the jdk project; he has been working on javac, fixing bugs and implementing enhancements in different areas of the compiler. One of these bugs have entity enough to be considered a JEP that would initially be implemented in the amber repo, see [2]. He has made about 13 changes [3] to the OpenJDK repository. Votes are due by 20:00 UTC February 21, 2023. Only current committers and reviewers of the amber Project [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. Vicente Romero [1] https://openjdk.org/census#acobbs [2]https://bugs.openjdk.org/browse/JDK-8300786 [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Cobbs%22&type=commits [4] https://openjdk.org/census#amber [5] https://openjdk.org/groups/#member-vote From vicente.romero at oracle.com Tue Feb 7 23:42:04 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 7 Feb 2023 18:42:04 -0500 Subject: CFV: New amber Committer: Archie Cobbs In-Reply-To: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> References: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> Message-ID: <536e4ad5-5e52-f439-e5b2-c05c05ba4d45@oracle.com> vote: yes On 2/7/23 18:38, Vicente Romero wrote: > I hereby nominate Archie Cobbs [acobbs] as a committer in the amber > Project. > > Archie Cobbs [1] is an author of the jdk project; he has been working > on javac, fixing bugs and implementing enhancements in different areas > of the compiler. > One of these bugs have entity enough to be considered a JEP that would > initially be implemented in the amber repo, see [2]. > > He has made about 13 changes [3] to the OpenJDK repository. > Votes are due by 20:00 UTC February 21, 2023. > > Only current committers and reviewers of the amber Project [4] are > eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Vicente Romero > > [1] https://openjdk.org/census#acobbs > [2]https://bugs.openjdk.org/browse/JDK-8300786 > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Cobbs%22&type=commits > [4] https://openjdk.org/census#amber > [5] https://openjdk.org/groups/#member-vote From hchao at openjdk.org Tue Feb 7 23:54:52 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 7 Feb 2023 23:54:52 GMT Subject: git: openjdk/amber: created branch super-init based on the branch onramp containing 380 unique commits Message-ID: <0c26c68f-be3b-4acd-a41a-00af091f2bc2@openjdk.org> The following commits are unique to the super-init branch: ======================================================== 3918f9f5: 8299090: Specify coordinate order for additional CaptureCallState parameters on class as well 752a3701: 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR 6a4a8743: 8299034: Runtime::exec clarification of inherited environment 4b92fb0c: 8299918: Update Xcode11.3.1-MacOSX10.15 devkit at Oracle 98870472: Merge 19628e3e: 8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC 640eff64: 8300040: TypeOopPtr::make_from_klass_common calls itself with args in wrong order be8e6d05: 8299957: Enhance error logging in instrument coding with additional jplis_assert_msg ac63f5f8: 8297877: Risk for uninitialized memory in case of CHECK macro early return as part of field access c2502228: 8300110: Unproblemlist Fuzz.java from ProblemList-zgc.txt e7fa150b: 8299032: Interface IN_NATIVE oop stores for C2 3ffc9557: 8300099: Configuration fails to auto-detect build user through $USER in dockers ce1193a1: 8299976: Initialize static fields in Net eagerly d1179795: 8300054: Use static_assert in basic_types_init 4ec36598: 8278349: JarSigner javadoc example uses SHA-1 500b45e1: 8299865: Unnecessary NullPointerException catch in java.util.TimeZone#setDefaultZone 8cb25d3d: 8298644: JNI call of getCurrentComponent on a wrong thread f4e119d5: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method e0081462: 8300055: [BACKOUT] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE bc498f87: 8300141: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC ab7f43f0: 8299498: Usage of constructors of primitive wrapper classes should be avoided in java.lang API docs 628266af: 8299501: Usage of constructors of primitive wrapper classes should be avoided in java.util API docs 98eae6da: 8299500: Usage of constructors of primitive wrapper classes should be avoided in java.text API docs dc5cc616: 8299499: Usage of constructors of primitive wrapper classes should be avoided in java.net API docs 87865e0e: 8299502: Usage of constructors of primitive wrapper classes should be avoided in javax.xml API docs 4be94e43: Merge 7bcd5f41: 8297914: Remove java_lang_Class::process_archived_mirror() 12edd6f9: 8300052: PdhDll::PdhCollectQueryData and PdhLookupPerfNameByIndex will never be NULL fe7fca01: 8300032: DwarfParser resource leak 50e7df91: 8300024: Replace use of JNI_COMMIT mode with mode 0 83f2c9a2: 8293410: Remove GenerateRangeChecks flag abfd7e89: 8300113: C2: Single-bit fields with signed type in TypePtr after JDK-8297933 7c1ebcc4: 8299962: Speed up compiler/intrinsics/unsafe/DirectByteBufferTest.java and HeapByteBufferTest.java 6fea233e: 8299960: Speed up test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java cac72a60: 8300053: Shenandoah: Handle more GCCauses in ShenandoahControlThread::request_gc 98d75f18: 8299038: Add AArch64 backend support for auto-vectorized FP16 conversions a7342853: 8299879: CollectedHeap hierarchy should use override a2f67660: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines 289aed46: 8298128: runtime/ErrorHandling/TestSigInfoInHsErrFile.java fails to find pattern with slowdebug 319de6a6: 8300124: Remove unnecessary assert in GenCollectedHeap::initialize 506c8186: 8296401: ConcurrentHashTable::bulk_delete might miss to delete some objects 4073b685: 8298047: Remove all non-significant trailing whitespace from properties files 4c1e66e0: 8299971: Remove metaprogramming/conditional.hpp f52f6e65: 8299972: Remove metaprogramming/removeReference.hpp 240830df: 8297092: [macos_aarch64] Add support for SHA feature detection 859ccd1a: 8299847: RISC-V: Improve PrintOptoAssembly output of CMoveI/L nodes 06f9374e: 8298867: Basics.java fails with SSL handshake exception 382fe51b: 8163229: several regression tests have a main method that is never executed 8365c677: 8300084: AquaFileChooserUI.getDefaultButton returns null 6a81d528: 8299213: Bad cast in GrowableArrayWithAllocator<>::grow f829a679: 8300227: [macos_aarch64] assert(cpu_has("hw.optional.arm.FEAT_AES")) failed after JDK-8297092 3462438a: 8299576: Reimplement java.io.Bits using VarHandle access 9a36f8aa: 8299673: Simplify object pinning interactions with string deduplication e82dc693: 8300205: Swing test bug8078268 make latch timeout configurable 07d57531: 8300168: Typo in AccessibleJTableHeaderEntry javadoc b7fb8ef8: 8299323: Allow extended registers for cmpw e15bdc58: 8299789: Compilation of gtest causes build to fail if runtime libraries are in different dirs 85d70acc: Merge 4cd166ff: 8300125: Serial: Remove unused Generation::reset_saved_marks fb147aae: 8300228: ModuleReader.find on exploded module throws if resource name maps to invalid file path e139ec3d: 8300069: Left shift of negative value in share/adlc/dict2.cpp 75b122fe: 8300120: Configure should support different defaults for CI/dev build environments 0b9ff06f: 8300184: Optimize ResourceHashtableBase::iterate_all using _number_of_entries e7e37121: 8300010: UnsatisfiedLinkError on calling System.console().readPassword() on Windows 8c12ae86: 8283203: Fix typo in SystemTray.getTrayIconSize javadoc d7c05d18: 8300011: Refactor code examples to use @snippet in java.util.TimeZone ade08e19: 8300093: Refactor code examples to use @snippet in java.text.MessageFormat e37078f5: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops 00b6c551: 8300254: ASan build does not correctly propagate ASAN_OPTIONS f9883fc4: 8300279: Use generalized see and link tags in core libs in client libs 1d8b87dd: 8300321: Use link tags in javax.sql.rowset package-info 7071397e: 8299224: TestReporterStreams.java has bad indentation for legal header 89a032dc: 8300002: Performance regression caused by non-inlined hot methods due to post call noop instructions f1194dc0: 8300109: RISC-V: Improve code generation for MinI/MaxI nodes 1f438a8a: 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 66f7387b: 8299074: nmethod marked for deoptimization is not deoptimized c7056737: 8299089: Instrument global jni handles with tag to make them distinguishable 7c8b99ee: 8300117: Replace use of JNI_COMMIT mode with mode 0 d9180423: 8300267: Remove duplicated setter/getter for do_not_unlock 15a9186d: 8300169: Build failure with clang-15 bd5ca953: 8300222: Replace NULL with nullptr in share/logging 1aded82e: 8300488: Incorrect usage of CATCH_BAD_ALLOC as a macro call c464ef1d: 8292741: Convert JvmtiTagMapTable to ResourceHashtable 85d8bacb: 8300166: Unused array allocation in ProcessPath.doProcessPath 754f6e61: 8300237: Minor improvements in MethodHandles b3684f4b: 8153837: AArch64: Handle special cases for MaxINode & MinINode c3242ee4: 8298596: vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java fails with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" c205caea: 8297851: Add devkit for RISC-V fcbf9d05: 8300243: Replace NULL with nullptr in share/compiler/ 3ea0b8bc: 8300489: Use ArraysSupport.vectorizedHashCode in j.l.CharacterName 2a46e07f: 8286581: Make Java process DPI Aware if sun.java2d.dpiaware property is set 7bf0d146: 8300133: Use generalized see and link tags in core libs 5473e8a1: 8300357: Use generalized see and link tags in java.management ba899b42: 8300550: BASIC_JVM_LIBS is set for buildjdk even if this is incorrect 8b70c432: 8299772: The ColorModel.getRGBdefault() method is not thread-safe 601e0ae7: 8300594: Use generalized see and link tags in UnicastRemoteObject dfe94b89: 8300307: Refactor code examples to use @snippet in java.text.DateFormat 31a2e02a: 8300308: java.text.MessageFormat has incorrect doc comment ae0e0276: 8298059: Linked stack watermarks don't support nesting ba86c23e: 8286070: Improve UTF8 representation 5aae8226: 8288516: Enhance font creation 51e52c4e: 8286496: Improve Thread labels b7cfb681: 8293598: Enhance InetAddress address handling 3364c460: 8293734: Improve BMP image handling d6b15132: 8293717: Objective view of ObjectView 2e8073e4: 8287411: Enhance DTLS Performance 6c5aefe6: 8293554: Enhanced DH Key Exchanges 93161e46: 8293742: Better Banking of Sounds bd324cee: 8295687: Better BMP bounds 0f925fef: 8295723: security/infra/wycheproof/RunWycheproof.java fails with Assertion Error c1b4212a: 8300195: Fall-through issue occurs when using record pattern in switch statements b9275a8e: 8300275: SegmentScope.isAccessibleBy returning incorrect values fc9f8baf: Merge 910dffea: 8292635: Run ArchivedEnumTest.java in jdk tier testing 715b509f: 8298632: [TESTBUG] Add IR checks in jtreg vectorization tests 8e3036cf: 8300595: Use improved @see and @link syntax in javax.lang.model and javax.tools 24cdcd4c: 8293841: RISC-V: Implementation of Foreign Function & Memory API (Preview) 7348b9ec: 8300167: Add validation of the raster's layout before using in native 2e9cb4b1: 8267582: BasicLookAndFeel should not call getComponentPopupMenu twice to get a popup menu 5b0af1a8: 8208077: File.listRoots performance degradation 5f66024e: 8299959: C2: CmpU::Value must filter overflow computation against local sub computation cfe57466: 8300242: Replace NULL with nullptr in share/code/ 08e62182: 8300526: Test runtime/jni/IsVirtualThread/IsVirtualThread.java should exercise alternative virtual thread implementation eba87a0e: 8300264: Remove metaprogramming/isPointer.hpp 8f7faa63: 8300447: Parallel: Refactor PSPromotionManager::drain_stacks_depth 11df6eb2: 8300540: Serial: Remove obsolete comments in GenMarkSweep e326b86d: 8300042: Improve CPU related JFR events descriptions 2e4a3c47: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null' dea58efb: 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems 1084fd24: 8299973: Replace NULL with nullptr in share/utilities/ 453dbd12: 8298377: JfrVframeStream causes deadlocks in ZGC d85243f0: 8300647: Miscellaneous hashCode improvements in java.base b317658d: 8300399: EdDSA does not verify when there is no message 80ab50b3: 8294680: Refactor scaled border rendering 558d610b: 8299553: Make ScaledEtchedBorderTest.java comprehensive f2a1eb98: 8300698: Missing @since tag for ClassFileFormatVersion.RELEASE_21 62a2f232: 8300490: Spaces in name of MacOS Code Signing Identity are not correctly handled after JDK-8293550 1c840506: 8298400: Virtual thread instability when stack overflows dfcd65c2: Merge fbbb27e7: 8300356: Refactor code examples to use @snippet in java.text.CollationElementIterator 9b97699b: 8300586: Refactor code examples to use @snippet in java.text.Collator 93a933d4: 8300400: Update --release 20 symbol information for JDK 20 build 32 77f2d20e: 8287873: Add test for using -XX:+AutoCreateSharedArchive with different JDK versions e1893976: 8296403: [TESTBUG] IR test runner methods in TestLongRangeChecks.java invoke wrong test methods 49d60fee: 8300172: java/net/httpclient/MappingResponseSubscriber.java failed with java.net.ConnectException eca64795: 8300087: Replace NULL with nullptr in share/cds/ 26410c18: 8281213: Unsafe uses of long and size_t in MemReporterBase::diff_in_current_scale 4562b402: 8300682: InstanceKlassMiscStatus is a bad name 97c611d0: 8289748: C2 compiled code crashes with SIGFPE with -XX:+StressLCM and -XX:+StressGCM 623ba5b6: 8300653: G1EvacInfo should use common naming scheme for collection set b2d36221: 8299896: Reduce enum values of HtmlLinkInfo.Kind c6d56003: 8038146: Clarify Map.Entry's connection to the underlying map 92d8326e: 8299827: Add resolved IP address in connection exception for sockets e8038557: 8299863: URLFromURITest.java should import org.junit.jupiter.api.Test facd4151: 8297757: VarHandles.getStaticFieldFromBaseAndOffset should get the receiver type from VarHandle 9d44dd0c: 8297972: Poly1305 Endianness on ByteBuffer not enforced 5784eb7b: 8300721: Cleanup ProblemList-svc-vthread.txt 7c2f77a4: 8300584: Accelerate AVX-512 CRC32C for small buffers e1ee6727: 8300725: Improve performance of ColorConvertOp for default destinations with alpha 5331a3ef: 8298908: Instrument Metaspace for ASan 06394ee8: 8300590: [JVMCI] BytecodeFrame.equals is broken bb42e61a: 8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder a6c2a2ae: 8300692: GCC 12 reports some compiler warnings in bundled freetype c8dd7583: 8300260: Remove metaprogramming/isSame.hpp 67b1c890: 8294693: Add Collections.shuffle overload that accepts RandomGenerator interface cbfc069f: 8300731: Avoid unnecessary array fill after creation in PaletteBuilder 3ea4eac1: 8300817: The build is broken after JDK-8294693 7ced08d4: 8300638: Tier1 IR Test failure after JDK-8298632 on macosx-x64-debug 030b071d: 8300207: Add a pre-check for the number of canonical equivalent permutations in j.u.r.Pattern 45e4e009: 8300079: SIGSEGV in LibraryCallKit::inline_string_copy due to constant NULL src argument 836198a4: 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc 11aadc9d: 8244400: MenuItem may cache the size and did not update it when the screen DPI is changed f307e8c6: 8299795: Relativize locals in interpreter frames 5a4945c0: 8299975: Limit underflow protection CMoveINode in PhaseIdealLoop::do_unroll must also protect type from underflow 03a9a88e: 8300265: Remove metaprogramming/isSigned.hpp 542bfe61: 8300587: (bf) Some covariant overrides are missing @since tags a56598f5: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly 079255e3: 8300864: Declare some fields in java.io as final a7f035db: 8300868: Reduce visibility in java.io.SerialCallbackContext 4525aa31: 8300867: Fix document issues in java.io 86fed796: 8300693: Lower the compile threshold and reduce the iterations of warmup loop in VarHandles tests 1a3cb8c5: 8296343: CPVE thrown on missing content-length in OCSP response d1173508: 8300866: Declare some classes final in java.io dcf1523b: 8300077: Refactor code examples to use @snippet in java.text.ChoiceFormat 0ea2dd1f: 8146132: Excessive output from make test-image fd752178: 8290919: Update nroff pages in JDK 20 before RC 56dc3b08: Merge f79e5871: 8300828: Avoid unnecessary array fill after creation in com.sun.media.sound 77a50105: 8286775: Remove identical per-compiler definitions of unsigned integral jtypes b5ee3d1f: 8299497: Usage of constructors of primitive wrapper classes should be avoided in java.desktop API docs 0323609f: 8300706: Use @snippet in java.text 2da2e5a0: 8300946: Add sun/security/provider/certpath/OCSP/OCSPNoContentLength to ProblemList 937ba1ca: 8300111: Add rpath for common lib locations for jpackageapplauncher afd5921f: 8298610: Refactor archiving of ConstantPool::resolved_references() b3822f50: 8300589: Use @snippet and @linkplain in java.text.CollationKey and java.text.CompactNumberFormat 6dd8723f: 8290918: Initial nroff manpage generation for JDK 21 2292ce13: 8294677: chunklevel::MAX_CHUNK_WORD_SIZE too small for some applications 57f2d48e: 8300863: Remove C-style array declarations in java.io 544c16e0: 8300266: Detect Virtualization on Linux aarch64 048705c0: 8300910: Remove metaprogramming/integralConstant.hpp 859ca75b: 8300862: Remove some G1 collection set remembered set debugging code 3be5758b: 8300769: Remove G1CollectionSet::_inc_bytes_used_before b678e700: 8300942: JDK-8299684 breaks x86 build cf46004f: 8300272: Improve readability of the test JarWithOneNonDisabledDigestAlg a3ed7e94: 8300623: Lambda deserialization regression involving Enum method reference 60b8a985: 8300591: @SuppressWarnings option "lossy-conversions" missing from jdk.compiler module javadoc 81d523d3: Merge 13394615: 8300981: Build failure on 32-bit platforms after JDK-8281213 fbe5ab00: 8300830: Remove redundant assertion in src/hotspot/share/runtime/javaCalls.cpp 7465de45: 6603771: Nimbus L&F: Ctrl+F7 keybinding for Jinternal Frame throws a NPE. 5a478ef7: 8297730: C2: Arraycopy intrinsic throws incorrect exception 95fafd09: 8300644: Remove gc/shenandoah/jni/TestStringCriticalWithDedup.java b2071f79: 8300657: Remove null filtering in CLD oop handle area 3c61d5aa: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values 71107f46: 8300651: Replace NULL with nullptr in share/runtime/ a5d8e128: 8300244: Replace NULL with nullptr in share/interpreter/ 74e1a8bf: 8300236: Use VarHandle access in Data(Input | Output)Stream classes c8ad6000: 8301004: httpclient: Add more debug to HttpResponseInputStream 8a47429d: 8295944: Move the Http2TestServer and related classes into a package of its own 61775c85: 8300997: Add curl support to createJMHBundle.sh a23ff63a: 8301086: jdk/internal/util/ByteArray/ReadWriteValues.java fails with CompilationError f279c751: 8300805: Update autoconf build-aux files with latest from 2022-09-17 e80b5ea4: 8299635: Hotspot update for deprecated sprintf in Xcode 14 edf1e1ab: 8300592: ASan build does not correctly propagate options to some test launchers ccf2f583: 8300806: Update googletest to v1.13.0 9f0887e2: 8296661: Typo Found In CSSParser.java adcfd257: 8301098: Remove dead code FileMapInfo::stop_sharing_and_unmap() 7e951f4b: 8301092: Add benchmark for CRC32 b5a4744f: 8300857: State return value for Types.asElement(NoType) explicitly 252621d4: 8301063: Remove dead code from GrowableArray 4b0e656b: 8298118: split-if optimization causes empty loop to temporarily have more than one phi 48152ef6: 8287134: HttpURLConnection chunked streaming mode doesn't enforce specified size 3589b808: 8300127: Serial: Remove unnecessary from-space iteration in DefNewGeneration::oop_since_save_marks_iterate 30cb305d: 8292170: Convert CodeRootSetTable to use ResourceHashtable 7328182b: 8300958: Parallel: Remove unused MutableNUMASpace::capacity_in_words b0376a5f: 8301069: Replace NULL with nullptr in share/libadt/ 15a14884: 8297437: javadoc cannot link to old docs (with old style anchors) a9b8acb6: 8300652: Parallel: Refactor oop marking stack in Full GC 7725fe84: 8299953: Merge ContiguousSpaceDCTOC into DirtyCardToOopClosure da80e7a4: 8300962: Parallel: Remove PSParallelCompact::_total_invocations 3f633814: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded 28545dcf: 8300247: Harden C1 xchg on AArch64 and PPC 64ddf953: 8299858: [Metrics] Swap memory limit reported incorrectly when too large 973f7419: 8300968: Accessorize raw oop load in DeadCounterClosure 14114c25: 8301005: Clean up Copy::conjoint_*_atomic on windows 315398c2: 8221785: Let possibly_parallel_threads_do cover the same threads as threads_do d98a323a: 8301070: Replace NULL with nullptr in share/memory/ a2a77033: 8299444: java.util.Set.copyOf allocates needlessly for empty input collections fc26d3e5: 8298873: Update IllegalRecordVersion.java for changes to TLS implementation 7ddafd75: 8301189: validate-source fails after JDK-8298873 c4278144: 8299982: (bf) Buffer.checkIndex(int, int) should use Preconditions.checkIndex(int, int, BiFunction) d6007a35: 8298869: Update ConnectionTest.java for changes to TLS implementation 7eff5787: 8288050: Add support of SHA-512/224 and SHA-512/256 to the PBKDF2 and PBES2 impls in SunJCE provider c3ff1514: 8301190: [vectorapi] The typeChar of LaneType is incorrect when default locale is tr 0eb1f66f: 8298038: [s390] Configure script detects num_cores +1 938b4096: 8301133: IGV: NPE occurs when creating a diff graph with a graph in a different folder c6b3f2dd: 8301129: Link to debuginfo files should only be made after stripping 6e4710bc: 8300253: Introduce AArch64 nzcv accessors f7da09c3: 8301164: Remove unused ResourceStack class b77abc6a: 8301178: Replace NULL with nullptr in share/gc/epsilon/ 107e184d: 8301179: Replace NULL with nullptr in share/gc/serial/ d7aa87fd: 8300176: URLEncoder/URLDecoder static fields should be private static final 3758487f: 8301180: Replace NULL with nullptr in share/gc/parallel/ db8fa1be: 8300405: Screen capture for test JFileChooserSetLocationTest.java, failure case e4252bb9: 8300823: UB: Compile::_phase_optimize_finished is initialized too late fccf8189: 8301123: Enable Symbol refcounting underflow checks in PRODUCT e2a3b20c: 8301187: Memory leaks in OopMapCache dff41316: 8285850: [AIX] unreachable code in basic_tools.m4 -> BASIC_CHECK_TAR 5c1ec826: 8301077: Replace NULL with nullptr in share/services/ f52d35c8: 8300240: Replace NULL with nullptr in share/ci/ 49ff5208: 8300241: Replace NULL with nullptr in share/classfile/ 7aaf76c5: 8300924: Method::invoke throws wrong exception type when passing wrong number of arguments to method with 4 or more parameters 22c976a9: 8177418: NPE is not apparent for methods in java.util.TimeZone API docs 7f05d57a: 8217920: Lookup.defineClass injects a class that can access private members of any class in its own module 9c4bc2c3: 8301132: Test update for deprecated sprintf in Xcode 14 b8e5abc1: 8301097: Update GHA XCode to 12.5.1 ae0e76d3: 8301120: Cleanup utility classes java.util.Arrays and java.util.Collections a67b1e77: 8300719: JDK 20 RDP2 L10n resource files update b22e5216: 8300953: ClassDesc::ofInternalName missing @since tag e5860ef6: 8301206: Fix issue with LocaleData after JDK-8300719 5c59de52: Merge 5dfc4ec7: 8300140: ZipFile.isSignatureRelated returns true for files in META-INF subdirectories af564e46: 8299844: RISC-V: Implement _onSpinWait intrinsic 6475501a: 8300208: Optimize Adler32 stub for AVX-512 targets. d4e9f5e5: 8238170: BeanContextSupport remove and propertyChange can deadlock 1ff4646e: 8298612: Refactor archiving of java String objects 64b25ea0: 8291569: Consider removing JNI checks for signals SIGPIPE and SIGXFSZ 4bd3f0a0: 8301088: oopDesc::print_on should consistently use a trailing newline c2ebd179: 6187113: DefaultListSelectionModel.removeIndexInterval(0, Integer.MAX_VALUE) fails cbefe1fd: 8301163: jdk/internal/vm/Continuation/Fuzz.java increase COMPILATION_TIMEOUT for Linux ppc64le 3db558b6: 8300915: G1: incomplete SATB because nmethod entry barriers don't get armed 08b24ac7: 8294066: IGV: Graph changes when deleting a graph in the same group with smaller index f50cda7d: 8301217: Remove FilteringClosure 7fae3a1d: 8301229: Clean up SuspendibleThreadSet::_suspend_all cee4bd3e: 8301047: Clean up type unsafe uses of oop from compiler code c672ed16: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc 82df4a2a: 8301148: Serial: Remove ContiguousSpace::reset_saved_mark 61a5f114: 8301033: RISC-V: Handle special cases for MinI/MaxI nodes for Zbb ebb84ad7: 8301036: RISC-V: Factor out functions baseOffset & baseOffset32 from MacroAssembler 476f58ad: 8298424: Remove redundant FOUND_CORES variable in build-performance.m4 041a12e6: 8301255: Http2Connection may send too many GOAWAY frames a74ebd04: 8299325: java/net/httpclient/CancelRequestTest.java fails "test CancelRequestTest.testGetSendAsync("https://localhost:46509/https1/x/same/interrupt", true, true)" f4592b14: 8267935: Replace BasicHashtable and Hashtable 32381398: 8300916: Re-examine the initialization of JNU Charset in StaticProperty a91143cc: 8298907: nsk JDI tests pass if the debuggee failed to launch a128a5d0: 8300810: Get rid of unused JDI removeListener() methods b84f4c40: 8301267: Update of config.guess broke build on WSL 63bb2ce8: 8301205: Port fdlibm log10 to Java ef6200c7: 8300269: The selected item in an editable JComboBox with titled border is not visible in Aqua LAF 561a25e0: Merge 2d7690b2: 8301207: (jdeps) Deprecate jdeps -profile option 622b6594: 8262994: Refactor String.split to help method inlining aa349244: 8300463: Build failure on Windows 32 after JDK-8296401 a6867a7e: 8301378: CodeHeap has virtual methods that are not overridden 7b3919d3: 8301346: Remove dead emit_entry_barrier_stub definition 4b0e259d: 8301344: G1: Remove DirtyCardToOopClosure forward declaration in g1OopClosures.hpp 633e291c: 8301067: RISC-V: better error message when reporting unsupported satp modes 9cc0171e: 8301153: RISC-V: pipeline class for several instructions is not set correctly cdb4ba96: 8301326: Optimize compiler/uncommontrap/TestDeoptOOM.java test 33e653e2: 8301448: [BACKOUT] CodeHeap has virtual methods that are not overridden 810c8a27: 8301170: perfMemory_windows.cpp add free_security_attr to early returns d583767b: 8301338: Identical branch conditions in CompileBroker::print_heapinfo 419409bc: 8301337: Remove unused os::_polling_page 90ec19ef: 8301068: Replace NULL with nullptr in share/jvmci/ b76a52f2: 8301076: Replace NULL with nullptr in share/prims/ 60c535de: 8301340: Make DirtyCardToOopClosure stack-allocated e193a0b7: 8295951: intermittent cmp_baseline task failures with CDS files 5744c91b: 8297158: Suspicious collection method call in Types.isSameTypeVisitor e1bf4713: 8301555: Remove constantPoolCacheKlass friend 4bef233a: 8301549: Fix comment about ClassCircularityError 6beadbbe: 8293519: deprecation warnings should be emitted for uses of annotation methods inside other annotations 09bfbf80: 8300909: Update com/sun/jndi/dns/Test6991580.java manual test instruction 8164cfbc: 8300696: [AIX] AttachReturnError fails d269ebba: 8301570: Test runtime/jni/nativeStack/ needs to detach the native thread a0aed9bd: 8301459: Serial: Merge KeepAliveClosure into FastKeepAliveClosure 4f6f3cc6: 8301446: Remove unused includes of gc/shared/genOopClosures ef0d0a70: 8301402: os::print_location gets is_global_handle assert 2a8ae2ff: 8300256: C2: vectorization is sometimes skipped on loops where it would succeed 969f6a37: 8301093: C2 fails assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out cae577a7: 8295486: Inconsistent constant field values observed during compilation 7c6a8db3: 8301447: [REDO] CodeHeap has virtual methods that are not overridden bc750f70: 8294527: Some java.security.debug options missing from security docs 3361a26d: 8298874: Update TestAllSuites.java for TLS v1.2 and 1.3 24ff3da0: 8301201: Allow \n@ inside inline tags using inlineContent 99521087: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL 51ac8783: 8284236: Remove java/lang/ref/ReferenceEnqueue.java from ProblemList-Xcomp.txt 6c927c92: 8301299: Wrong class spec on sun.security.util.Pem 960c3931: 8301393: Include cdb in the Windows devkit 225f8053: 8299891: JMX ObjectInputFilter additional classes needed 1330d4ea: 8298377: JfrVframeStream causes deadlocks in ZGC d6832121: Merge 8d6e8a47: 8301618: Compare elements and type mirrors properly af474ce3: 8297582: C2: very slow compilation due to type system verification code b1e96989: 8301506: Replace NULL with nullptr in os_cpu/linux_ppc 13fcd602: 8301504: Replace NULL with nullptr in os_cpu/linux_aarch64 6daff6b2: 8301502: Replace NULL with nullptr in os_cpu/bsd_x86 5d1f71da: 8301509: Replace NULL with nullptr in os_cpu/linux_x86 182d1b2f: 8301507: Replace NULL with nullptr in os_cpu/linux_riscv c109dae4: 8301513: Replace NULL with nullptr in os_cpu/windows_x86 8cc399b6: 8301503: Replace NULL with nullptr in os_cpu/bsd_zero ad79e491: 8301512: Replace NULL with nullptr in os_cpu/windows_aarch64 42a286a1: 8301511: Replace NULL with nullptr in os_cpu/linux_zero b81f0ff4: 8301505: Replace NULL with nullptr in os_cpu/linux_arm 218223e4: 8301501: Replace NULL with nullptr in os_cpu/bsd_aarch64 c8307e37: 8301500: Replace NULL with nullptr in os_cpu/aix_ppc d097b5e6: 8301508: Replace NULL with nullptr in os_cpu/linux_s390 7b6ac41a: 8286876: NMT.test_unaliged_block_address_vm_assert fails if using clang toolchain 03b23a1e: 8301367: Add exception handler method to the BaseLdapServer 21c1afbc: 8301612: OopLoadProxy constructor should be explicit 5b1584b9: 8298880: VectorLogicalOpIdentityTest.java IR test incorrectly use avx3 instead of avx512 59b7fb1a: 8300273: [IR framework] Handle message instead of bailing out 2d50c7d4: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java 725d57b2: 8301659: Resolve initialization reordering issues on Windows for libawt and libsaproc 930ec008: 8301636: Minor cleanup in CommentHelper and DocPretty de577332: 8301644: com/sun/jdi/JdbStopThreadTest.java fails after JDK-8300811 c647ae6c: 8301149: Parallel: Refactor MutableNUMASpace::update_layout cf6b9eb8: 8301637: ThreadLocalRandom.current().doubles().parallel() contention f696785f: 8300869: Make use of the Double.toString(double) algorithm in java.util.Formatter ee0f5b5e: 8301392: Port fdlibm log1p to Java b00b70c2: 8286907: keytool should warn about weak PBE algorithms From brian.goetz at oracle.com Wed Feb 8 01:50:57 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 7 Feb 2023 20:50:57 -0500 Subject: CFV: New amber Committer: Archie Cobbs In-Reply-To: <536e4ad5-5e52-f439-e5b2-c05c05ba4d45@oracle.com> References: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> <536e4ad5-5e52-f439-e5b2-c05c05ba4d45@oracle.com> Message-ID: <5badf8e6-9163-3eec-928c-4b9d433f12b6@oracle.com> Vote: yes On 2/7/2023 6:42 PM, Vicente Romero wrote: > vote: yes > > On 2/7/23 18:38, Vicente Romero wrote: >> I hereby nominate Archie Cobbs [acobbs] as a committer in the amber >> Project. >> >> Archie Cobbs [1] is an author of the jdk project; he has been working >> on javac, fixing bugs and implementing enhancements in different >> areas of the compiler. >> One of these bugs have entity enough to be considered a JEP that >> would initially be implemented in the amber repo, see [2]. >> >> He has made about 13 changes [3] to the OpenJDK repository. >> Votes are due by 20:00 UTC February 21, 2023. >> >> Only current committers and reviewers of the amber Project [4] are >> eligible to vote on this nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [5]. >> >> Vicente Romero >> >> [1] https://openjdk.org/census#acobbs >> [2]https://bugs.openjdk.org/browse/JDK-8300786 >> [3] >> https://github.com/openjdk/jdk/search?q=author-name%3A%22Cobbs%22&type=commits >> [4] https://openjdk.org/census#amber >> [5] https://openjdk.org/groups/#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Wed Feb 8 01:58:03 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 8 Feb 2023 01:58:03 +0000 Subject: CFV: New amber Committer: Archie Cobbs In-Reply-To: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> References: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> Message-ID: <5D297374-B942-4A34-98E2-9C07B648D94E@oracle.com> Vote: yes ? > On Feb 7, 2023, at 7:39 PM, Vicente Romero wrote: > > ?I hereby nominate Archie Cobbs [acobbs] as a committer in the amber Project. > > Archie Cobbs [1] is an author of the jdk project; he has been working on javac, fixing bugs and implementing enhancements in different areas of the compiler. > One of these bugs have entity enough to be considered a JEP that would initially be implemented in the amber repo, see [2]. > > He has made about 13 changes [3] to the OpenJDK repository. > Votes are due by 20:00 UTC February 21, 2023. > > Only current committers and reviewers of the amber Project [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Vicente Romero > > [1] https://openjdk.org/census#acobbs > [2]https://bugs.openjdk.org/browse/JDK-8300786 > [3] https://github.com/openjdk/jdk/search?q=author-name%3A%22Cobbs%22&type=commits > [4] https://openjdk.org/census#amber > [5] https://openjdk.org/groups/#member-vote From duke at openjdk.org Wed Feb 8 03:47:19 2023 From: duke at openjdk.org (duke) Date: Wed, 8 Feb 2023 03:47:19 GMT Subject: git: openjdk/amber: super-init: 2 new changesets Message-ID: <5c18533b-cefc-47c0-86cb-efbc337100a6@openjdk.org> Changeset: 22847023 Author: Vicente Romero Date: 2023-02-07 22:44:04 +0000 URL: https://git.openjdk.org/amber/commit/2284702395e63a807b46832781d4480ec6e2fdfd test first push ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: 29f658c0 Author: Vicente Romero Zaldivar <62155190+vicente-romero-oracle at users.noreply.github.com> Committer: GitHub Date: 2023-02-07 22:45:39 +0000 URL: https://git.openjdk.org/amber/commit/29f658c0b687fbf6d26384263be4d666cc22e69a Merge pull request #88 from vicente-romero-oracle/test.first.push just testing the pipelines From duke at openjdk.org Wed Feb 8 03:58:20 2023 From: duke at openjdk.org (duke) Date: Wed, 8 Feb 2023 03:58:20 GMT Subject: git: openjdk/amber: super-init: 2 new changesets Message-ID: <7fb4e040-0c02-4217-848e-ab607e19bc3a@openjdk.org> Changeset: b15af9b1 Author: Vicente Romero Date: 2023-02-07 22:55:46 +0000 URL: https://git.openjdk.org/amber/commit/b15af9b18c21b48529b31a7a06bc5bb1f107b2f1 remove test comment ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: 7262bed6 Author: Vicente Romero Zaldivar <62155190+vicente-romero-oracle at users.noreply.github.com> Committer: GitHub Date: 2023-02-07 22:56:58 +0000 URL: https://git.openjdk.org/amber/commit/7262bed6b73eee67f4817a67579cb7e0e0bf4b6a Merge pull request #89 from vicente-romero-oracle/remove.test.comment remove test comment From archie.cobbs at gmail.com Thu Feb 9 16:07:02 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 9 Feb 2023 10:07:02 -0600 Subject: @OverrideShouldInvoke Message-ID: Just throwing this out there - I'm curious whether this idea resonates with anyone else... or alternately offends... First, a big picture observation: There is a lot of "activity" in Java centered around the superclass-subclass relationship. For example, we have the protected keyword. We have the final keyword. We have a bunch of rules around how constructors are allowed (or not allowed) to invoke super(). We have @Overrides. We have abstract methods that force behavior on subclasses. Basically, all of this stuff amounts to a somewhat ad hoc "API" that a superclass defines and a subclass uses (and in some cases, vice-versa). But this "API" is not always clearly or fully defined. For example, bugs caused by 'this' escapes result from what can be described as an ambiguity in the "API" between superclass and subclass. I guess I'm just saying that this "API" and how we define it (or fail to define it) is an area of interest to me. OK, back to earth... Here's a proposal that addresses one more little bit of this "API". I'm on the fence as to whether this would be worthwhile and am curious what others think. The problem is this: often a superclass method foo() implements some important superclass functionality, but it is not final so that it can be overridden. In these cases, the superclass often wants to be able to specify "If you override this method, then you should also invoke super.foo() at some point unless you really know what you're doing". An example of such a method is Object.finalize(). There are arguments that such methods are bad style - instead, there should be a separate empty method provided for subclasses to override. So this idea would have to be weighed against that. But regardless, today there are lots of examples of such methods out there already. The rough proposal is: - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() overrides a superclass method Sup.foo() that has an @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it invoke Sup.foo() (via a super.foo() expression), then an error occurs. - Add a new property boolean withoutInvokingSuper default false to the @Overrides annotation that allows Sub.foo() to suppress this error if it "really knows what it's doing". For simplicity, we'd only count invocations of the overridden method exactly, not some overloaded variant. So for example if an override of ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, if you wanted to get fancy, you could make this optional via something like @OverrideShouldInvoke(allowOverloads = true). Here's are some examples of where you might want to use this: public class Object { @OverrideShouldInvoke protected native Object clone() throws CloneNotSupportedException; @OverrideShouldInvoke protected void finalize() throws Throwable { ... } } public class FileOutputStream extends OutputStream { @OverrideShouldInvoke public void close() throws IOException { ... } } public abstract class AbstractExecutorService implements ExecutorService { @OverrideShouldInvoke public Future submit(Runnable task) { ... } } Thoughts? -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbepincket at live.be Thu Feb 9 18:09:20 2023 From: robbepincket at live.be (Robbe Pincket) Date: Thu, 9 Feb 2023 18:09:20 +0000 Subject: @OverrideShouldInvoke In-Reply-To: References: Message-ID: On 2023-02-09 16:07 UTC, Archie Cobbs wrote: > The rough proposal is: > - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() > overrides a superclass method Sup.foo() that has an @OverrideShouldInvoke > annotation, and nowhere in Sub.foo() does it invoke Sup.foo() (via a > super.foo() expression), then an error occurs. > - Add a new property boolean withoutInvokingSuper default false to the > @Overrides annotation that allows Sub.foo() to suppress this error if it > "really knows what it's doing". Having 'Should' in the annotation name, and then making it produce an error instead of a warning annoys greatly. It doesn't feel like that agrees with RFC 2119. If it's a warning it could also be suppressed by a simple `@SuppressWarnings` instead of a new argument on `@Override` Regards Robbe Pincket -------------- next part -------------- An HTML attachment was scrubbed... URL: From blaisebass at gmail.com Thu Feb 9 16:12:57 2023 From: blaisebass at gmail.com (Blaise B.) Date: Thu, 9 Feb 2023 17:12:57 +0100 Subject: Regression Bug for Record patterns in Switch in JDK 20 Message-ID: Hello team, I would like to report a behavior I stumbled upon when a record pattern in switch is unconditional. public class Main { > record SomeRecord(Number num) {} > public static void main(String[] args) { > //var rec = new SomeRecord(null); > var rec = new SomeRecord(1.0f); > switch (rec) { > case SomeRecord(Double d) -> System.out.println("got a > double: " + d); > case SomeRecord(Number n) -> System.out.println("value > is " + n); > } > } > } Here, I expect variable "n" to be of type Number, but instead it displays "value is SomeRecord[num=1.0]". When I comment out the first case label, it works as expected. The issue is not present on JDK 19. I've observed it only on EA builds of jdk-20 and jdk-21. I also tried a record with two components: public class Main { > record Foo(Number num, String s) {} > public static void main(String[] args) { > Foo myfoo = new Foo(2, "me"); > switch (myfoo) { > case Foo(Double d, String s) -> > System.out.println("component values: " + d + ", " + s); > case Foo(Number n, String s) -> > System.out.println("component values: " + n + ", " + s); > } > } > } This time, the code compiles but fails to run with error message: > Error: Unable to initialize main class Main > Caused by: java.lang.VerifyError: Bad local variable type Again it works fine on jdk-19. Hope this helps. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Thu Feb 9 18:42:56 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 9 Feb 2023 12:42:56 -0600 Subject: @OverrideShouldInvoke In-Reply-To: References: Message-ID: On Thu, Feb 9, 2023 at 12:09 PM Robbe Pincket wrote: > > The rough proposal is: > > > - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() > > > overrides a superclass method Sup.foo() that has an > @OverrideShouldInvoke > > > annotation, and nowhere in Sub.foo() does it invoke Sup.foo() (via a > > > super.foo() expression), then an error occurs. > > > - Add a new property boolean withoutInvokingSuper default false to the > > > @Overrides annotation that allows Sub.foo() to suppress this error if > it > > > "really knows what it's doing". > > > > Having 'Should' in the annotation name, and then making it produce > > an error instead of a warning annoys greatly. It doesn't feel like > > that agrees with RFC 2119. > > > > If it's a warning it could also be suppressed by a simple > > `@SuppressWarnings` instead of a new argument on `@Override` > Yes - a warning would work also. I wrote "error" because that's what the @Override annotation generates when tripped and figured it should be consistent. Or, you could change the name to @OverrideMustInvoke :) -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Feb 9 19:44:41 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 9 Feb 2023 14:44:41 -0500 Subject: @OverrideShouldInvoke In-Reply-To: References: Message-ID: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> In a previous life, I was involved in several static analysis efforts.? One of the common factors there is that annotations like @ShouldntIgnoreReturnValue or @ShouldWashYourHands is that these are always approximations, guidelines aimed at identifying _likely bugs_ rather than _invalid programs_.? Usually such annotations beget requests for more annotations to refine the behavior in increasingly rarefied corners. @OverrideShouldInvoke seems like it would be equally subject to this; it's a good starting point for "this is what the superclass intends", but is unlikely to be precise enough to not create new problems. The language, on the other hand, should mostly be in the business of identifying _invalid programs_.? If something is important enough that the language should reject a program over it, it should probably be part of the language, not an annotation.? (An obvious exception is @Override; in hindsight, it was probably excessive exuberance to use the new shiny annotation tool for this, rather than introducing a conditional `override` keyword at the time (Java 5).) So my gut sense is that this belongs in an effort like Checkers rather than in the language itself. On 2/9/2023 11:07 AM, Archie Cobbs wrote: > Just throwing this out there - I'm curious whether this idea resonates > with anyone else... or alternately offends... > > First, a big picture observation: > > There is a lot of "activity" in Java centered around the > superclass-subclass relationship. For example, we have the protected > keyword. We have the final keyword. We have a bunch of rules around > how constructors are allowed (or not allowed) to invoke super(). We > have @Overrides. We have abstract methods that force behavior on > subclasses. > > Basically, all of this stuff amounts to a somewhat ad hoc "API" that a > superclass defines and a subclass uses (and in some cases, vice-versa). > > But this "API" is not always clearly or fully defined. For example, > bugs caused by 'this' escapes result from what can be described as an > ambiguity in the "API" between superclass and subclass. > > I guess I'm just saying that this "API" and how we define it (or fail > to define it) is an area of interest to me. > > OK, back to earth... > > Here's a proposal that addresses one more little bit of this "API". > I'm on the fence as to whether this would be worthwhile and am curious > what others think. > > The problem is this: often a superclass method foo() implements some > important superclass functionality, but it is not final so that it can > be overridden. In these cases, the superclass often wants to be able > to specify "If you override this method, then you should also invoke > super.foo() at some point unless you really know what you're doing". > An example of such a method is Object.finalize(). > > There are arguments that such methods are bad style - instead, there > should be a separate empty method provided for subclasses to override. > So this idea would have to be weighed against that. But regardless, > today there are lots of examples of such methods out there already. > > The rough proposal is: > > * Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() > overrides a superclass method Sup.foo() that has an > @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it > invoke Sup.foo() (via a super.foo() expression), then an error occurs. > * Add a new property boolean withoutInvokingSuper default false to > the @Overrides annotation that allows Sub.foo() to suppress this > error if it "really knows what it's doing". > > For simplicity, we'd only count invocations of the overridden method > exactly, not some overloaded variant. So for example if an override of > ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, > if you wanted to get fancy, you could make this optional via something > like @OverrideShouldInvoke(allowOverloads = true). > > Here's are some examples of where you might want to use this: > > public class Object { > > @OverrideShouldInvoke > ??? protected native Object clone() throws CloneNotSupportedException; > > ? ? @OverrideShouldInvoke > ? ? protected void finalize() throws Throwable { > ? ? ? ? ... > ? ? } > } > > public class FileOutputStream extends OutputStream { > > @OverrideShouldInvoke > ??? public void close() throws IOException { > ??????? ... > ??? } > } > > public abstract class AbstractExecutorService implements ExecutorService { > > @OverrideShouldInvoke > ??? public Future submit(Runnable task) { > ??????? ... > ??? } > } > > Thoughts? > > -Archie > > -- > Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at google.com Thu Feb 9 19:58:14 2023 From: kevinb at google.com (Kevin Bourrillion) Date: Thu, 9 Feb 2023 11:58:14 -0800 Subject: @OverrideShouldInvoke In-Reply-To: References: Message-ID: I think this is a relevant request to the JSpecify project; consider filing a feature request here . I'm also on the fence about its relative importance, but it is sometimes asked for (in a much less well-written-up way than you've already done). It would be fine to discuss it in that context. (Tangent re: must vs. should, in JSpecify I haven't found RFC 2119 to be as directly usable as I'd once hoped, and we're still confounded over how best to use the terms. It feels more like there is one notion, "must, assuming that..." with a whole variety of assumptions that might follow, not just a two-way switch. Also "should" is annoying for having no negation in the English language, leading to awkward phrases like "is neither encouraged nor discouraged", while "must" at least sometimes does. Bleh.) On Thu, Feb 9, 2023 at 8:07 AM Archie Cobbs wrote: > Just throwing this out there - I'm curious whether this idea resonates > with anyone else... or alternately offends... > > First, a big picture observation: > > There is a lot of "activity" in Java centered around the > superclass-subclass relationship. For example, we have the protected > keyword. We have the final keyword. We have a bunch of rules around how > constructors are allowed (or not allowed) to invoke super(). We have > @Overrides. We have abstract methods that force behavior on subclasses. > > Basically, all of this stuff amounts to a somewhat ad hoc "API" that a > superclass defines and a subclass uses (and in some cases, vice-versa). > > But this "API" is not always clearly or fully defined. For example, bugs > caused by 'this' escapes result from what can be described as an ambiguity > in the "API" between superclass and subclass. > > I guess I'm just saying that this "API" and how we define it (or fail to > define it) is an area of interest to me. > > OK, back to earth... > > Here's a proposal that addresses one more little bit of this "API". I'm on > the fence as to whether this would be worthwhile and am curious what others > think. > > The problem is this: often a superclass method foo() implements some > important superclass functionality, but it is not final so that it can be > overridden. In these cases, the superclass often wants to be able to > specify "If you override this method, then you should also invoke > super.foo() at some point unless you really know what you're doing". An > example of such a method is Object.finalize(). > > There are arguments that such methods are bad style - instead, there > should be a separate empty method provided for subclasses to override. So > this idea would have to be weighed against that. But regardless, today > there are lots of examples of such methods out there already. > > The rough proposal is: > > - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() > overrides a superclass method Sup.foo() that has an > @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it > invoke Sup.foo() (via a super.foo() expression), then an error occurs. > - Add a new property boolean withoutInvokingSuper default false to the > @Overrides annotation that allows Sub.foo() to suppress this error if > it "really knows what it's doing". > > For simplicity, we'd only count invocations of the overridden method > exactly, not some overloaded variant. So for example if an override of > ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, if > you wanted to get fancy, you could make this optional via something like > @OverrideShouldInvoke(allowOverloads = true). > > Here's are some examples of where you might want to use this: > > public class Object { > > @OverrideShouldInvoke > protected native Object clone() throws CloneNotSupportedException; > > @OverrideShouldInvoke > protected void finalize() throws Throwable { > ... > } > } > > public class FileOutputStream extends OutputStream { > > @OverrideShouldInvoke > public void close() throws IOException { > ... > } > } > > public abstract class AbstractExecutorService implements ExecutorService { > > @OverrideShouldInvoke > public Future submit(Runnable task) { > ... > } > } > > Thoughts? > > -Archie > > -- > Archie L. Cobbs > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at google.com Thu Feb 9 20:14:59 2023 From: kevinb at google.com (Kevin Bourrillion) Date: Thu, 9 Feb 2023 12:14:59 -0800 Subject: @OverrideShouldInvoke In-Reply-To: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> References: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> Message-ID: I agree and might put it like this: The minimal language rules are those that let the platform understand deterministically *what* to do, whether it's "safely" what the programmer actually *wants* or not. The platform does further make various safety guarantees beyond that, requiring more rules, but tries to keep those to just the highest-value, most-universal ones. Third-party static analyzers are all about saving you from as many bugs as they can, modulo acceptable false-positive thresholds. I work (somewhat) on Error Prone , which addresses this particular issue with a check called "MissingSuperCall". But it's not standardized, and that's where JSpecify might come in. On Thu, Feb 9, 2023 at 11:44 AM Brian Goetz wrote: > In a previous life, I was involved in several static analysis efforts. > One of the common factors there is that annotations like > @ShouldntIgnoreReturnValue or @ShouldWashYourHands is that these are always > approximations, guidelines aimed at identifying _likely bugs_ rather than > _invalid programs_. Usually such annotations beget requests for more > annotations to refine the behavior in increasingly rarefied corners. > @OverrideShouldInvoke seems like it would be equally subject to this; it's > a good starting point for "this is what the superclass intends", but is > unlikely to be precise enough to not create new problems. > > The language, on the other hand, should mostly be in the business of > identifying _invalid programs_. If something is important enough that the > language should reject a program over it, it should probably be part of the > language, not an annotation. (An obvious exception is @Override; in > hindsight, it was probably excessive exuberance to use the new shiny > annotation tool for this, rather than introducing a conditional `override` > keyword at the time (Java 5).) > > So my gut sense is that this belongs in an effort like Checkers rather > than in the language itself. > > On 2/9/2023 11:07 AM, Archie Cobbs wrote: > > Just throwing this out there - I'm curious whether this idea resonates > with anyone else... or alternately offends... > > First, a big picture observation: > > There is a lot of "activity" in Java centered around the > superclass-subclass relationship. For example, we have the protected > keyword. We have the final keyword. We have a bunch of rules around how > constructors are allowed (or not allowed) to invoke super(). We have > @Overrides. We have abstract methods that force behavior on subclasses. > > Basically, all of this stuff amounts to a somewhat ad hoc "API" that a > superclass defines and a subclass uses (and in some cases, vice-versa). > > But this "API" is not always clearly or fully defined. For example, bugs > caused by 'this' escapes result from what can be described as an ambiguity > in the "API" between superclass and subclass. > > I guess I'm just saying that this "API" and how we define it (or fail to > define it) is an area of interest to me. > > OK, back to earth... > > Here's a proposal that addresses one more little bit of this "API". I'm on > the fence as to whether this would be worthwhile and am curious what others > think. > > The problem is this: often a superclass method foo() implements some > important superclass functionality, but it is not final so that it can be > overridden. In these cases, the superclass often wants to be able to > specify "If you override this method, then you should also invoke > super.foo() at some point unless you really know what you're doing". An > example of such a method is Object.finalize(). > > There are arguments that such methods are bad style - instead, there > should be a separate empty method provided for subclasses to override. So > this idea would have to be weighed against that. But regardless, today > there are lots of examples of such methods out there already. > > The rough proposal is: > > - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() > overrides a superclass method Sup.foo() that has an > @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it > invoke Sup.foo() (via a super.foo() expression), then an error occurs. > - Add a new property boolean withoutInvokingSuper default false to the > @Overrides annotation that allows Sub.foo() to suppress this error if > it "really knows what it's doing". > > For simplicity, we'd only count invocations of the overridden method > exactly, not some overloaded variant. So for example if an override of > ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, if > you wanted to get fancy, you could make this optional via something like > @OverrideShouldInvoke(allowOverloads = true). > > Here's are some examples of where you might want to use this: > > public class Object { > > @OverrideShouldInvoke > protected native Object clone() throws CloneNotSupportedException; > > @OverrideShouldInvoke > protected void finalize() throws Throwable { > ... > } > } > > public class FileOutputStream extends OutputStream { > > @OverrideShouldInvoke > public void close() throws IOException { > ... > } > } > > public abstract class AbstractExecutorService implements ExecutorService { > > @OverrideShouldInvoke > public Future submit(Runnable task) { > ... > } > } > > Thoughts? > > -Archie > > -- > Archie L. Cobbs > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Thu Feb 9 20:20:22 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 9 Feb 2023 14:20:22 -0600 Subject: @OverrideShouldInvoke In-Reply-To: References: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> Message-ID: Thanks for the comments & pointers. I agree this idea seems like it better belongs in some kind of "companion" tool and am glad to hear the idea already exists out there. -Archie On Thu, Feb 9, 2023 at 2:15 PM Kevin Bourrillion wrote: > I agree and might put it like this: The minimal language rules are those > that let the platform understand deterministically *what* to do, whether > it's "safely" what the programmer actually *wants* or not. The platform > does further make various safety guarantees beyond that, requiring more > rules, but tries to keep those to just the highest-value, most-universal > ones. > > Third-party static analyzers are all about saving you from as many bugs as > they can, modulo acceptable false-positive thresholds. I work (somewhat) on Error > Prone , which addresses this > particular issue with a check called "MissingSuperCall". But it's not > standardized, and that's where JSpecify might come in. > > > On Thu, Feb 9, 2023 at 11:44 AM Brian Goetz > wrote: > >> In a previous life, I was involved in several static analysis efforts. >> One of the common factors there is that annotations like >> @ShouldntIgnoreReturnValue or @ShouldWashYourHands is that these are always >> approximations, guidelines aimed at identifying _likely bugs_ rather than >> _invalid programs_. Usually such annotations beget requests for more >> annotations to refine the behavior in increasingly rarefied corners. >> @OverrideShouldInvoke seems like it would be equally subject to this; it's >> a good starting point for "this is what the superclass intends", but is >> unlikely to be precise enough to not create new problems. >> >> The language, on the other hand, should mostly be in the business of >> identifying _invalid programs_. If something is important enough that the >> language should reject a program over it, it should probably be part of the >> language, not an annotation. (An obvious exception is @Override; in >> hindsight, it was probably excessive exuberance to use the new shiny >> annotation tool for this, rather than introducing a conditional `override` >> keyword at the time (Java 5).) >> >> So my gut sense is that this belongs in an effort like Checkers rather >> than in the language itself. >> >> On 2/9/2023 11:07 AM, Archie Cobbs wrote: >> >> Just throwing this out there - I'm curious whether this idea resonates >> with anyone else... or alternately offends... >> >> First, a big picture observation: >> >> There is a lot of "activity" in Java centered around the >> superclass-subclass relationship. For example, we have the protected >> keyword. We have the final keyword. We have a bunch of rules around how >> constructors are allowed (or not allowed) to invoke super(). We have >> @Overrides. We have abstract methods that force behavior on subclasses. >> >> Basically, all of this stuff amounts to a somewhat ad hoc "API" that a >> superclass defines and a subclass uses (and in some cases, vice-versa). >> >> But this "API" is not always clearly or fully defined. For example, bugs >> caused by 'this' escapes result from what can be described as an ambiguity >> in the "API" between superclass and subclass. >> >> I guess I'm just saying that this "API" and how we define it (or fail to >> define it) is an area of interest to me. >> >> OK, back to earth... >> >> Here's a proposal that addresses one more little bit of this "API". I'm >> on the fence as to whether this would be worthwhile and am curious what >> others think. >> >> The problem is this: often a superclass method foo() implements some >> important superclass functionality, but it is not final so that it can be >> overridden. In these cases, the superclass often wants to be able to >> specify "If you override this method, then you should also invoke >> super.foo() at some point unless you really know what you're doing". An >> example of such a method is Object.finalize(). >> >> There are arguments that such methods are bad style - instead, there >> should be a separate empty method provided for subclasses to override. So >> this idea would have to be weighed against that. But regardless, today >> there are lots of examples of such methods out there already. >> >> The rough proposal is: >> >> - Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() >> overrides a superclass method Sup.foo() that has an >> @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it >> invoke Sup.foo() (via a super.foo() expression), then an error occurs. >> - Add a new property boolean withoutInvokingSuper default false to >> the @Overrides annotation that allows Sub.foo() to suppress this >> error if it "really knows what it's doing". >> >> For simplicity, we'd only count invocations of the overridden method >> exactly, not some overloaded variant. So for example if an override of >> ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, if >> you wanted to get fancy, you could make this optional via something like >> @OverrideShouldInvoke(allowOverloads = true). >> >> Here's are some examples of where you might want to use this: >> >> public class Object { >> >> @OverrideShouldInvoke >> protected native Object clone() throws CloneNotSupportedException; >> >> @OverrideShouldInvoke >> protected void finalize() throws Throwable { >> ... >> } >> } >> >> public class FileOutputStream extends OutputStream { >> >> @OverrideShouldInvoke >> public void close() throws IOException { >> ... >> } >> } >> >> public abstract class AbstractExecutorService implements ExecutorService { >> >> @OverrideShouldInvoke >> public Future submit(Runnable task) { >> ... >> } >> } >> >> Thoughts? >> >> -Archie >> >> -- >> Archie L. Cobbs >> >> >> > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Thu Feb 9 21:26:54 2023 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 9 Feb 2023 22:26:54 +0100 Subject: @OverrideShouldInvoke In-Reply-To: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> References: <7ca26125-b2e9-734c-b63f-15d813a7daa1@oracle.com> Message-ID: Hello! I agree with Brian. We have such an annotation in JetBrains annotations package named org.jetbrains.annotations.MustBeInvokedByOverriders. There are also javax.annotation.OverridingMethodsMustInvokeSuper and com.google.errorprone.annotations.OverridingMethodsMustInvokeSuper. IntelliJ IDEA static analyzer supports them and allows you to add your own custom annotation with the same semantics. SpotBugs and ErrorProne also have this functionality. So while there's no standard solution in Java itself, users who want to have such a warning have a variety of tools to choose from. And I agree that such an API style is a bad idea. With best regards, Tagir Valeev. On Thu, Feb 9, 2023 at 8:44 PM Brian Goetz wrote: > > In a previous life, I was involved in several static analysis efforts. One of the common factors there is that annotations like @ShouldntIgnoreReturnValue or @ShouldWashYourHands is that these are always approximations, guidelines aimed at identifying _likely bugs_ rather than _invalid programs_. Usually such annotations beget requests for more annotations to refine the behavior in increasingly rarefied corners. @OverrideShouldInvoke seems like it would be equally subject to this; it's a good starting point for "this is what the superclass intends", but is unlikely to be precise enough to not create new problems. > > The language, on the other hand, should mostly be in the business of identifying _invalid programs_. If something is important enough that the language should reject a program over it, it should probably be part of the language, not an annotation. (An obvious exception is @Override; in hindsight, it was probably excessive exuberance to use the new shiny annotation tool for this, rather than introducing a conditional `override` keyword at the time (Java 5).) > > So my gut sense is that this belongs in an effort like Checkers rather than in the language itself. > > On 2/9/2023 11:07 AM, Archie Cobbs wrote: > > Just throwing this out there - I'm curious whether this idea resonates with anyone else... or alternately offends... > > First, a big picture observation: > > There is a lot of "activity" in Java centered around the superclass-subclass relationship. For example, we have the protected keyword. We have the final keyword. We have a bunch of rules around how constructors are allowed (or not allowed) to invoke super(). We have @Overrides. We have abstract methods that force behavior on subclasses. > > Basically, all of this stuff amounts to a somewhat ad hoc "API" that a superclass defines and a subclass uses (and in some cases, vice-versa). > > But this "API" is not always clearly or fully defined. For example, bugs caused by 'this' escapes result from what can be described as an ambiguity in the "API" between superclass and subclass. > > I guess I'm just saying that this "API" and how we define it (or fail to define it) is an area of interest to me. > > OK, back to earth... > > Here's a proposal that addresses one more little bit of this "API". I'm on the fence as to whether this would be worthwhile and am curious what others think. > > The problem is this: often a superclass method foo() implements some important superclass functionality, but it is not final so that it can be overridden. In these cases, the superclass often wants to be able to specify "If you override this method, then you should also invoke super.foo() at some point unless you really know what you're doing". An example of such a method is Object.finalize(). > > There are arguments that such methods are bad style - instead, there should be a separate empty method provided for subclasses to override. So this idea would have to be weighed against that. But regardless, today there are lots of examples of such methods out there already. > > The rough proposal is: > > Add a new annotation @OverrideShouldInvoke. If a method Sub.foo() overrides a superclass method Sup.foo() that has an @OverrideShouldInvoke annotation, and nowhere in Sub.foo() does it invoke Sup.foo() (via a super.foo() expression), then an error occurs. > Add a new property boolean withoutInvokingSuper default false to the @Overrides annotation that allows Sub.foo() to suppress this error if it "really knows what it's doing". > > For simplicity, we'd only count invocations of the overridden method exactly, not some overloaded variant. So for example if an override of ArrayList.add(E) invoked super.add(int, E), that wouldn't count. Or, if you wanted to get fancy, you could make this optional via something like @OverrideShouldInvoke(allowOverloads = true). > > Here's are some examples of where you might want to use this: > > public class Object { > > @OverrideShouldInvoke > protected native Object clone() throws CloneNotSupportedException; > > @OverrideShouldInvoke > protected void finalize() throws Throwable { > ... > } > } > > public class FileOutputStream extends OutputStream { > > @OverrideShouldInvoke > public void close() throws IOException { > ... > } > } > > public abstract class AbstractExecutorService implements ExecutorService { > > @OverrideShouldInvoke > public Future submit(Runnable task) { > ... > } > } > > Thoughts? > > -Archie > > -- > Archie L. Cobbs > > From duke at openjdk.org Thu Feb 9 22:13:04 2023 From: duke at openjdk.org (duke) Date: Thu, 9 Feb 2023 22:13:04 GMT Subject: git: openjdk/amber: super-init: 2 new changesets Message-ID: Changeset: deac3a2c Author: Vicente Romero Date: 2023-02-09 13:10:15 +0000 URL: https://git.openjdk.org/amber/commit/deac3a2cd8441fb55c2bf856c87b3f08757bcbf1 8302038: compiler implementation for statements before super(), first iteration ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java + test/langtools/tools/javac/SuperInit/SuperInitFails.java + test/langtools/tools/javac/SuperInit/SuperInitFails.out + test/langtools/tools/javac/SuperInit/SuperInitGood.java - test/langtools/tools/javac/diags/examples/CallMustBeFirst.java + test/langtools/tools/javac/diags/examples/CallOnlyInConstructor.java + test/langtools/tools/javac/diags/examples/CallsNotAllowedHere.java ! test/langtools/tools/javac/diags/examples/FirstInvocationMustBeAnotherConstructor.java + test/langtools/tools/javac/diags/examples/RedundantSuperclassInit.java + test/langtools/tools/javac/diags/examples/ReturnBeforeSuperclassInit.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: e935c979 Author: Vicente Romero Zaldivar <62155190+vicente-romero-oracle at users.noreply.github.com> Committer: GitHub Date: 2023-02-09 17:09:41 +0000 URL: https://git.openjdk.org/amber/commit/e935c9791570ac81182ba5e1020304fc0237fbfe Merge pull request #90 from vicente-romero-oracle/initial.push 8302038: compiler implementation for statements before super(), first iteration From robbepincket at live.be Fri Feb 10 23:20:20 2023 From: robbepincket at live.be (Robbe Pincket) Date: Fri, 10 Feb 2023 23:20:20 +0000 Subject: Draft JEP on Primitive types in patterns, instanceof, and switch In-Reply-To: References: <99642744-6650-1918-c750-04a50c9d15e5@oracle.com> Message-ID: This email was initially sent to amber-spec-observers by accident. Hi all I've long considered whether I should voice my opinion on the matter or not, given that I felt like some of my arguments had already been made before. Spoiler, I'm not a fan of `instanceof byte`. Every time I write this email, I recheck something in the archives to check something and realize that someone already said *something* about one of the arguments I'm trying to make. So here is just a list of things that have come up that I still felt like mentioning something. --- I asked a whether the following would be legal in an earlier email. The draft now explains that it is, but I still wonder what this snippet would get desugared to. ``` Number num = ...; if (num instanceof byte b) { ... } ``` --- On 2023-01-27 at 12:01 UTC, Ron Pressler wrote (as reaction to an email by Remi Forax on 2023-01-27 at 11:06 UTC): > ?4.10.1 of the JLS has stated that a subtyping relationship among primitives exists (byte <: short <: int <: long, float <: double) since at least Java 1.6 (possibly earlier). > >> By example, you can not override a method that returns a double with a method that returns an int because overriding is about subtyping relationship, not conversion (for the history, Neal Gafter had implemented method overriding that allow primitive conversions in javac in one of the early versions of Java 1.5 but to it was decided to not go that path). > > The rules for return types in overridden methods (?8.4.8.3) doesn?t refer to subtyping but to "return-type-substitutability? (?8.4.5) which, in turn, also doesn?t talk about subtyping but only about subtyping *in the case that the return type is a reference type*. So even though there is a subtyping relationship between int and long (though not between int and double), they are not return-type-substitutable, which places additional constraints beyond mere subtyping. It seems you missed a single line in the spec. `long` is also a direct subtype of `float` so `int` is in fact a subtype of `double` >> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand. > > First, a subtyping relationship for primitives does exist, though it doesn?t cover all of the possible conversions. Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn?t exist, because the draft doesn?t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are ?really? about the validity of such conversions rather than about the specific case of subtyping. I had a quick look over the spec and I couldn't find any place that actually used the subtyping relation between primitives. The case you seem to be claiming widening primitive conversion matches 100% with the rules about subtyping, it actually doesn't use subtyping at all and just lists all possible conversions. A interesting question that could be asked is: "What does subtype/supertype mean". Although it is used in the spec it isn't really explain apart from being a reflexive and transitive relationship between types. --- A few of the emails argue that we should see `instanceof` as a safe cast check, not like an "inheritance" check or a "reference subtype" check. If the operator was called `canbesafelyconvertedto` I might agree, but thats not the case. It feels very weird (to me) to not have an operator called `instanceof`, not check whether the lhs is an instance of the rhs. Some of you might be thinking: "I guess you want to argue that you can't have instances of an `byte` so `instanceof byte` doesn't make sense", which isn't true. Valhalla discussions have agreed that `byte` has instances. It has 256 different ones: the values from -128 to 127. Now this might seem I'm arguing in favour of `instanceof byte`. And on it's own that might look correct, but then you have justify the fact that the integer values/instances between -128 and 127 and the byte values/instances are the same. In my mind the way this would be justified is by using the fact that `byte` is a subtype of `int` which is why it's set of instances is a subset of the instances of `int`. But this raises the issue that the set of instances of `int` can't be a subset of the set of instances of `float` cause not all ints are valid floats. --- I feel like I spend too much time writing, rewriting and deleting this email so this is it (for now). TL; DR: I don't like `instanceof byte` and JLS chapter 4.10.1 Kind regards Robbe Pincket -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Feb 11 00:29:30 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 11 Feb 2023 00:29:30 +0000 Subject: Draft JEP on Primitive types in patterns, instanceof, and switch In-Reply-To: References: <99642744-6650-1918-c750-04a50c9d15e5@oracle.com> Message-ID: You?re right that ?4.10.1 is not essential to Java?s definition, but neither is it essential to the observation that a downcast (a narrowing reference conversion) is a special case of a cast, and instanceof can be generalised to pair nicely with more casts. I mainly brought it up in response to an email that stated categorically that no subtyping relationship exists among primitives as a way of showing that, as Brian then articulated better, that the way the language actually works is not necessarily equivalent with mental models of the language that each of us forms in our minds through interaction with the language (and those models are likely different from one person to another). There are other casts than downcasts, and the decision that instanceof is only related to downcasts but not other casts is just as arbitrary as the decision that it?s related to all casts, and both of them are consistent with the existing spec. Ultimately, the question of how instanceof is to be generalised ? to which casts it relates ? has different personal aesthetic answers, none of them philosophically right or wrong. But that?s not what drives the language decision. Rather, what drives the decision is which generalisation is most useful. Examples that show why the proposed generalisation is useful will follow. As to your point about not all ints being valid floats (regardless of the subtyping relationship in ?4.10.1), note that while it is a compile-time error to write `x instanceof String` when the compile-time type of `x` is `Integer`, it is not a compile-time error to write `x instanceof List` if the type of `x` is `Serializable`, or `x instanceof Serializable` when the type of `x` is `List`, even though not all Lists are Serializable and not all Serializables are Lists. As an approximation, we allow instanceof when there can be any intersection of instances between the type of the expression and the pattern. The generalisation of instanceof to pair with more kinds of casts is consistent with the language as well as with the mental models some of us have of it, and the relevant discussion about the feature isn?t about how it feels but what problems it solves (and/or creates). ? Ron On 10 Feb 2023, at 23:20, Robbe Pincket > wrote: This email was initially sent to amber-spec-observers by accident. Hi all I've long considered whether I should voice my opinion on the matter or not, given that I felt like some of my arguments had already been made before. Spoiler, I'm not a fan of `instanceof byte`. Every time I write this email, I recheck something in the archives to check something and realize that someone already said *something* about one of the arguments I'm trying to make. So here is just a list of things that have come up that I still felt like mentioning something. --- I asked a whether the following would be legal in an earlier email. The draft now explains that it is, but I still wonder what this snippet would get desugared to. ``` Number num = ...; if (num instanceof byte b) { ... } ``` --- On 2023-01-27 at 12:01 UTC, Ron Pressler wrote (as reaction to an email by Remi Forax on 2023-01-27 at 11:06 UTC): > ?4.10.1 of the JLS has stated that a subtyping relationship among primitives exists (byte <: short <: int <: long, float <: double) since at least Java 1.6 (possibly earlier). > >> By example, you can not override a method that returns a double with a method that returns an int because overriding is about subtyping relationship, not conversion (for the history, Neal Gafter had implemented method overriding that allow primitive conversions in javac in one of the early versions of Java 1.5 but to it was decided to not go that path). > > The rules for return types in overridden methods (?8.4.8.3) doesn?t refer to subtyping but to "return-type-substitutability? (?8.4.5) which, in turn, also doesn?t talk about subtyping but only about subtyping *in the case that the return type is a reference type*. So even though there is a subtyping relationship between int and long (though not between int and double), they are not return-type-substitutable, which places additional constraints beyond mere subtyping. It seems you missed a single line in the spec. `long` is also a direct subtype of `float` so `int` is in fact a subtype of `double` >> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand. > > First, a subtyping relationship for primitives does exist, though it doesn?t cover all of the possible conversions. Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn?t exist, because the draft doesn?t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are ?really? about the validity of such conversions rather than about the specific case of subtyping. I had a quick look over the spec and I couldn't find any place that actually used the subtyping relation between primitives. The case you seem to be claiming widening primitive conversion matches 100% with the rules about subtyping, it actually doesn't use subtyping at all and just lists all possible conversions. A interesting question that could be asked is: "What does subtype/supertype mean". Although it is used in the spec it isn't really explain apart from being a reflexive and transitive relationship between types. --- A few of the emails argue that we should see `instanceof` as a safe cast check, not like an "inheritance" check or a "reference subtype" check. If the operator was called `canbesafelyconvertedto` I might agree, but thats not the case. It feels very weird (to me) to not have an operator called `instanceof`, not check whether the lhs is an instance of the rhs. Some of you might be thinking: "I guess you want to argue that you can't have instances of an `byte` so `instanceof byte` doesn't make sense", which isn't true. Valhalla discussions have agreed that `byte` has instances. It has 256 different ones: the values from -128 to 127. Now this might seem I'm arguing in favour of `instanceof byte`. And on it's own that might look correct, but then you have justify the fact that the integer values/instances between -128 and 127 and the byte values/instances are the same. In my mind the way this would be justified is by using the fact that `byte` is a subtype of `int` which is why it's set of instances is a subset of the instances of `int`. But this raises the issue that the set of instances of `int` can't be a subset of the set of instances of `float` cause not all ints are valid floats. --- I feel like I spend too much time writing, rewriting and deleting this email so this is it (for now). TL; DR: I don't like `instanceof byte` and JLS chapter 4.10.1 Kind regards Robbe Pincket -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Feb 13 18:57:40 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Feb 2023 13:57:40 -0500 Subject: Draft JEP on Primitive types in patterns, instanceof, and switch In-Reply-To: References: <99642744-6650-1918-c750-04a50c9d15e5@oracle.com> Message-ID: <9b6deda1-ddb6-1385-5946-13e8a1612a17@oracle.com> > I asked a whether the following would be legal in an earlier email. > The draft now explains that it is, but I still wonder what this snippet > would get desugared to. > ``` > Number num = ...; > if (num instanceof byte b) { > ??? ... > } > ``` There are many choices of what the compiler could do.? If I had to guess, the most likely is an invocation of a library method like: ??? static boolean isSafeToCastFromIntToByte(n) { ... } followed by a cast to byte with `I2B` if this method returns true. This models the translation of the corresponding idiom with reference types; first check if the cast is safe with `INSTANCEOF` (which pushes a boolean on the stack), and then if that succeeds, use `CHECKCAST` to perform the casting.? Of course, the compiler could do the domain check inline as well; this is an implementation detail that the compiler has some latitude over.? Obviously there's also some latitude over where to put such helper methods and what to call them (as they may also be useful to other code, possibly because they capture snippets of language semantics that can be reused as as a method reference or method handle.) > >>/I agree that revisiting concepts is something we have to do, but > breaking the difference between subtyping and primitive conversions > for a corner case, in isolation, is a decision hard to understand./ > >// > >/First, a subtyping relationship for primitives does exist, though it > doesn?t cover all of the possible conversions./ > Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn?t exist, because the draft doesn?t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are ?really? about the validity of such conversions rather than about the specific case of subtyping. > I had a quick look over the spec and I couldn't find any place that > actually used the subtyping relation between primitives. The case > you seem to be claiming widening primitive conversion matches 100% > with the rules about subtyping, it actually doesn't use subtyping > at all and just lists all possible conversions. I don't think Ron is claiming that; the bit about "Well, there actually is subtyping here" was offered to rebut a spurious claim to the contrary.? But I don't think this is that important; whether int <: long or not is not that relevant to the language (personally I think the spec would be better without trying to define subtyping on primitives, for exactly the sorts of confusions that have come up in this thread, such as covariant overrides), and primitive widening conversions do not align with subtyping (because some widenings are not unconditionally exact.) But, all of this is a distraction.? The question is whether the sorts of unsafety you get from casting between reference types (it might throw NPE) and the sorts of unsafety you get from casting between primitives (it might succeed but give you a garbage value) are so radically different that attempting to unify them under the same rubric (check instanceof before you cast) is some sort of Lovecraftian horror.? The reality is, we have gotten used to them being separate, but they're not really that different. > A interesting question that could be asked is: > "What does subtype/supertype mean". Although it is used in the spec > it isn't really explain apart from being a reflexive and transitive > relationship between types. And if you pull on this string some more, you get to "what do types really mean."? Which is an excellent philosophical question, one which has been studied extensively with multiple overlapping theories (e.g., intensional vs extensional) that are useful in different situations.? Sometimes it is useful to think of types as sets of values, where subtyping is mere subsetting; in other situations, it is useful to think of them as objects in a category. But if you do pull on this string, you realize that it does not really offer much of an answer here, because people form their own theories about what types and subtyping are (which can be useful!) -- and then some language designer comes along and invalidates those personal theories by evolving the language in a way the theory didn't anticipate.? And this is where the strong emotional reaction of "but THATS not what instanceof (or whatever) means" comes from, which is mostly what we're dealing with here. And, I realize as a language designer, one of the things I should be aware of is how much we are asking users to change their mental models.? And this too is a balance; making the language more expressive or consistent always risks stepping on someone's mental model.? We do ask ourselves "how much will this freak people out" (and sometimes the answer is "way too much, we can't do that"), but this is but one input into the balance. > A few of the emails argue that we should see `instanceof` as a > safe cast check, not like an "inheritance" check or > a "reference subtype" check. If the operator was called > `canbesafelyconvertedto` I might agree, but thats not the case. Yes, past syntax decisions affect our mental models, and sometimes a past choice is so constraining that there is no room to extend an existing syntax, but this is surely a subjective business.? But I agree with you that this is at the heart of the most significant negative reactions to this JEP -- people have associated specific and personal feelings about the meaning of the term "instanceof". But we have to realize these are personal associations, and while they may work for us, we should be aware that these are our own personal associations. > Now this might seem I'm arguing in favour of `instanceof byte`. > And on it's own that might look correct, but then you have > justify the fact that the integer values/instances between -128 > and 127 and the byte values/instances are the same. In my mind > the way this would be justified is by using the fact that `byte` > is a subtype of `int` which is why it's set of instances is a > subset of the instances of `int`. But this raises the issue > that the set of instances of `int` can't be a subset of the set > of instances of `float` cause not all ints are valid floats. Again, you have developed a mental model of what a type is, and what instanceof means, that has been useful to you.? Yours is very much tied to subtyping, which is consistent with the current model. Which is fine -- but it's just a mental model.? I think you'll find that after you get over the frustration of "the world changed", snapping to this generalization of instanceof won't actually be that hard.? Give it some time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angelos.bimpoudis at oracle.com Tue Feb 14 22:43:39 2023 From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis) Date: Tue, 14 Feb 2023 22:43:39 +0000 Subject: Draft JEP on Primitive types in patterns, instanceof, and switch In-Reply-To: <9b6deda1-ddb6-1385-5946-13e8a1612a17@oracle.com> References: <99642744-6650-1918-c750-04a50c9d15e5@oracle.com> <9b6deda1-ddb6-1385-5946-13e8a1612a17@oracle.com> Message-ID: Hello all, A new version of the draft JEP on primitive types in patterns, instanceof, and switch is online: https://openjdk.org/jeps/8288476 Many thanks, Angelos ________________________________ From: amber-dev on behalf of Brian Goetz Sent: 13 February 2023 19:57 To: Robbe Pincket ; amber-dev Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch I asked a whether the following would be legal in an earlier email. The draft now explains that it is, but I still wonder what this snippet would get desugared to. ``` Number num = ...; if (num instanceof byte b) { ... } ``` There are many choices of what the compiler could do. If I had to guess, the most likely is an invocation of a library method like: static boolean isSafeToCastFromIntToByte(n) { ... } followed by a cast to byte with `I2B` if this method returns true. This models the translation of the corresponding idiom with reference types; first check if the cast is safe with `INSTANCEOF` (which pushes a boolean on the stack), and then if that succeeds, use `CHECKCAST` to perform the casting. Of course, the compiler could do the domain check inline as well; this is an implementation detail that the compiler has some latitude over. Obviously there's also some latitude over where to put such helper methods and what to call them (as they may also be useful to other code, possibly because they capture snippets of language semantics that can be reused as as a method reference or method handle.) >> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand. > > First, a subtyping relationship for primitives does exist, though it doesn?t cover all of the possible conversions. Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn?t exist, because the draft doesn?t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are ?really? about the validity of such conversions rather than about the specific case of subtyping. I had a quick look over the spec and I couldn't find any place that actually used the subtyping relation between primitives. The case you seem to be claiming widening primitive conversion matches 100% with the rules about subtyping, it actually doesn't use subtyping at all and just lists all possible conversions. I don't think Ron is claiming that; the bit about "Well, there actually is subtyping here" was offered to rebut a spurious claim to the contrary. But I don't think this is that important; whether int <: long or not is not that relevant to the language (personally I think the spec would be better without trying to define subtyping on primitives, for exactly the sorts of confusions that have come up in this thread, such as covariant overrides), and primitive widening conversions do not align with subtyping (because some widenings are not unconditionally exact.) But, all of this is a distraction. The question is whether the sorts of unsafety you get from casting between reference types (it might throw NPE) and the sorts of unsafety you get from casting between primitives (it might succeed but give you a garbage value) are so radically different that attempting to unify them under the same rubric (check instanceof before you cast) is some sort of Lovecraftian horror. The reality is, we have gotten used to them being separate, but they're not really that different. A interesting question that could be asked is: "What does subtype/supertype mean". Although it is used in the spec it isn't really explain apart from being a reflexive and transitive relationship between types. And if you pull on this string some more, you get to "what do types really mean." Which is an excellent philosophical question, one which has been studied extensively with multiple overlapping theories (e.g., intensional vs extensional) that are useful in different situations. Sometimes it is useful to think of types as sets of values, where subtyping is mere subsetting; in other situations, it is useful to think of them as objects in a category. But if you do pull on this string, you realize that it does not really offer much of an answer here, because people form their own theories about what types and subtyping are (which can be useful!) -- and then some language designer comes along and invalidates those personal theories by evolving the language in a way the theory didn't anticipate. And this is where the strong emotional reaction of "but THATS not what instanceof (or whatever) means" comes from, which is mostly what we're dealing with here. And, I realize as a language designer, one of the things I should be aware of is how much we are asking users to change their mental models. And this too is a balance; making the language more expressive or consistent always risks stepping on someone's mental model. We do ask ourselves "how much will this freak people out" (and sometimes the answer is "way too much, we can't do that"), but this is but one input into the balance. A few of the emails argue that we should see `instanceof` as a safe cast check, not like an "inheritance" check or a "reference subtype" check. If the operator was called `canbesafelyconvertedto` I might agree, but thats not the case. Yes, past syntax decisions affect our mental models, and sometimes a past choice is so constraining that there is no room to extend an existing syntax, but this is surely a subjective business. But I agree with you that this is at the heart of the most significant negative reactions to this JEP -- people have associated specific and personal feelings about the meaning of the term "instanceof". But we have to realize these are personal associations, and while they may work for us, we should be aware that these are our own personal associations. Now this might seem I'm arguing in favour of `instanceof byte`. And on it's own that might look correct, but then you have justify the fact that the integer values/instances between -128 and 127 and the byte values/instances are the same. In my mind the way this would be justified is by using the fact that `byte` is a subtype of `int` which is why it's set of instances is a subset of the instances of `int`. But this raises the issue that the set of instances of `int` can't be a subset of the set of instances of `float` cause not all ints are valid floats. Again, you have developed a mental model of what a type is, and what instanceof means, that has been useful to you. Yours is very much tied to subtyping, which is consistent with the current model. Which is fine -- but it's just a mental model. I think you'll find that after you get over the frustration of "the world changed", snapping to this generalization of instanceof won't actually be that hard. Give it some time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redio.development at gmail.com Sat Feb 18 05:35:48 2023 From: redio.development at gmail.com (Red IO) Date: Sat, 18 Feb 2023 06:35:48 +0100 Subject: Constructor Interfaces In-Reply-To: <0f801d76-aa07-a85d-2935-b0f245bc1e92@oracle.com> References: <1004124830.5064580.1674654700465.JavaMail.zimbra@u-pem.fr> <2130817602.5292556.1674671346470.JavaMail.zimbra@u-pem.fr> <12ef0967-607d-d644-44ef-6d049d1696c1@oracle.com> <0f801d76-aa07-a85d-2935-b0f245bc1e92@oracle.com> Message-ID: I took myself some time and reviewed all the points in this discussion. I dropped the idea of injecting a hidden argument since on second thought it would be messy and prone to leak the argument without extensive care which would be much work and it would cause weird and unexpected incompatibilities. My conclusion is that mandating static method / constructors to be present on a generic type opens many new concepts and coding strategies. The yield of the feature would probably be high and could be applied in unexpected places and in some cases move runtime checks/errors to compile time. But; there is just no good way to resolve these restrictions at runtime in the current implementation of java generics. The _only_ way to access static data of a type variable at runtime is to have the class instance available at runtime which requires the (planned) universal generics. Since this feature is like I explained directly dependent on universal generics now I will not spend any more time on this until/if universal generics are near completion. Great regards RedIODev On Tue, Jan 31, 2023, 04:18 Joseph D. Darcy wrote: > To add to what Brian and others have said on this thread, annotation > processors as first shipped in JDK 5.0 with apt and later standardized > through JSR 269 in Java SE 6 were intentionally designed to *not* allow > direct modification of ASTs to avoid language fragmentation, etc. > > However, it was acknowledged that at least some subset of the ability to > modify sources was useful so annotation processors supported the ability to > generate missing subclasses and *superclasses* during processing. Those > capabilities are sufficient to implement a properties-like scheme, as > sketched out in this blog entry: > > > https://web.archive.org/web/20100410203408/http://blogs.sun.com/darcy/entry/properties_via_annotation_processing > > and later productized in projects like: > > http://immutables.github.io/immutable.html > > HTH, > > -Joe > On 1/30/2023 6:36 AM, Brian Goetz wrote: > > Annotations are exactly as (not) powerful as they were designed to be. > JSR 175 (https://www.jcp.org/en/jsr/detail?id=175) -- the effort that > gave us annotations -- is called a _metadata facility for the Java > Language_, not a _metaprogramming facility_. This choice was not made > because the leaders of that effort were ignorant about metaprogramming; the > goal was to leave interpretation of annotations to things like service > containers, test frameworks, etc, because annotations are too weak a > mechanism for providing language semantics. > > As Ron pointed out, it is a very common mistake when imagining possible > language features to focus only on "if I had X, what cool code could I > write?", and ignore the "if everyone had X, what would be the effect on > readability, reliability, and maintainability of the global codebase?" But > understanding the latter is where much of the challenge lies in responsibly > evolving a language. > > > > > > On 1/30/2023 5:26 AM, Red IO wrote: > > After exploring the world of annotation processors trying to implement > test versions of the features, I discovered that annotation processors > can't officially edit the ast and Lombok uses undocumented hacks to achieve > this. This is a bit of a problem for implementing the test versions that > way. My question is why is this disallowed? It would be a really powerful > tool for compile time code execution/ generation. > Great regards > RedIODev > > On Wed, Jan 25, 2023, 20:19 Red IO wrote: > >> If the type information is an opt in feature it would not violate that >> rule. Adding an erasing parameter would still be a non breaking change. But >> if you opt in to request the type information and write logic depending on >> that information then this is a braking change to the code anyway since the >> logic wouldn't work with a raw type anyway. This could be another factor to >> push away from utilizing raw types. It could be a keyword you add to a >> parameterized thing to opt in (or implicitly opt in by utilizing the >> extended type information) and in the same act disable the raw version for >> it. Meaning that it would be a compile error to use the parameterized >> thing. >> >> Another option and preserve raw compatibility would be to exclude the >> hidden parameter in a raw instance. The downside to this approach would be >> that 2 signatures for every method/constructor that would otherwise include >> the hidden parameter would be required. Also for generic classes there >> would be 2 class layouts 1 with the hidden fields and 1 without. >> >> A completely different approach would be a static map of object instances >> to parameter lists. This would require 0 changes in the class itself. But >> in case of many generic objects loaded the performance of this approach is >> likely catastrophic. Should be tested if proving viable though. Another >> challenge is how a constructor would register the objects extended type >> information without an extra parameter. Also this would be difficult to >> implement for methods who are so short lived that the type parameter >> registration would likely take as long as the method itself needs to >> complete. >> >> Personally I would vote for braking with raw types (first approach) it >> wouldn't harm existing code (since opt in), would provide the simplest (and >> probably fastest) version and the only downside would be a harder and >> braking transition for api which still use raw types and want to utilize >> the extended type information (but as I already mentioned if an api wants >> to opt in to extended type information on a class; having raw instances of >> it would make absolutely no sense anyway). >> >> Great regards >> RedIODev >> >> On Wed, Jan 25, 2023, 19:29 wrote: >> >>> [private] >>> >>> ------------------------------ >>> >>> *From: *"Red IO" >>> *To: *"Remi Forax" >>> *Cc: *"amber-dev" >>> *Sent: *Wednesday, January 25, 2023 3:17:34 PM >>> *Subject: *Re: Constructor Interfaces >>> >>> I proposed an idea (to Valhalla) to overcome type erasure that used the >>> same idea of desugering and a hidden argument that carries the erased types >>> class variable inside the generic context, but it was rejected as a to >>> naive approach or something and they where "already working on different >>> solutions for some time". >>> >>> >>> What you have proposed is very similar to what Kotlin does, pass >>> supplementary type arguments as parameter arguments/fields. >>> This does not work, the Java spec explicitly says that adding type >>> parameters, if there were previously none, is a backward compatible change >>> but adding a supplementary parameter is not a backward compatible change >>> (especially not a binary backward compatible change). >>> >>> That why the current proposed design pass the type arguments as a side >>> channel not encoded in the type descriptor, see >>> https://cr.openjdk.java.net/~jrose/values/parametric-vm.pdf >>> >>> regards, >>> R?mi >>> >>> >>> Great regards RedIODev >>> >>> On Wed, Jan 25, 2023, 14:51 Remi Forax wrote: >>> >>>> We may need something like this for Valhalla, when we will revisit how >>>> to constraint the type arguments of universal generics. >>>> >>>> The kind of constraints you describe on type parameters already exist >>>> in C# or TypeScript and was more recently introduced in Go, and there is >>>> the type class of Haskell too. >>>> >>>> regards, >>>> R?mi >>>> >>>> ------------------------------ >>>> >>>> *From: *"Red IO" >>>> *To: *"amber-dev" >>>> *Sent: *Wednesday, January 25, 2023 8:03:14 AM >>>> *Subject: *Constructor Interfaces >>>> >>>> Summary >>>> ------- >>>> >>>> Enable a parameterized class to constrain the parameterized type to be >>>> constructible with a given list of parameters. >>>> >>>> >>>> >>>> Motivation >>>> ---------- >>>> >>>> It is possible since JDK 8 to get a constructor (method) reference of >>>> an object. This allowed for the creation of an unknown class with a known >>>> constructor reference. But currently the only way to obtain such reference >>>> is at call site like this: >>>> Box stringBox = new Box<>(String::new); >>>> >>>> It is inconvenient for the user to supply the the reference themselves >>>> and can confuse them as the type of the parameter is something like >>>> Supplier which doesn't require the pased reference to be a >>>> constructor. >>>> It also clutters api's like "toArray" which requires an IntFunction to >>>> be type safe. >>>> >>>> Description >>>> ----------- >>>> >>>> ConstructorInterface >>>> A ConstructorInterface is a special kind of interface similar to a >>>> FunctionalInterface. It also has similar constraints. It only allows >>>> abstract constructors and no other abstract methods. It can declare >>>> multiple constructors though. The definition of such interface would look >>>> similar to this: >>>> >>>> @ConstructorInterface //optional validation like FunctionalInterfaces >>>> public interface DefaultConstructible { >>>> new(); >>>> new(char[] chars); >>>> } >>>> >>>> A parameterized type could declare this interface as a type bound for >>>> its parameter and therefore enabling it to be constructed safely. Like this: >>>> public class Box { >>>> public Box() { >>>> E newElement = new E(); >>>> } >>>> } >>>> The containing type is not forced to implement the ContructorInterface >>>> explicitly. It is implicitly implemented if the required constructor(s) >>>> is(are) present. >>>> public static void main(String[] args) { >>>> Box stringBox = new Box<>(); //compiles because String has the >>>> required constructors. >>>> Box dateBox new Box<>(); error: java.sql.Data does not >>>> satisfy the type bound DefaultConstructible >>>> } >>>> The interface might not be implemented by any class, since it doesn't >>>> follow the inheritance rule that extending classes of those who implement >>>> it also implement it. This requirement comes from the fact that extending >>>> classes do not necessarily need to have the same constructor signature and >>>> therefore don't qualify the requirements for the interface. Another option >>>> would be that extending classes of classes that implement a constructor >>>> interface explicitly are also required to supply the necessary constructors. >>>> >>>> class Foo implements DefaultConstructable { >>>> //both required by the interface >>>> public Foo() {} >>>> public Foo(char[] chars) {} >>>> } >>>> >>>> class Bar extends Foo { >>>> //the requirement for the required constructors is passed down. >>>> public Bar() {} >>>> public Bar(char[] chars) {} >>>> } >>>> >>>> >>>> >>>> public static T createT() { >>>> return new T(); >>>> } >>>> >>>> public T wrapper() { >>>> return createT(); >>>> } >>>> This would technically work but would require a lot of static analysis >>>> to find the real type of T to call its constructor. >>>> Restricting the use of "new T()" to type parameters that specify a >>>> constructor interface directly and only allow those to be resolved with a >>>> concrete type rather than another type parameter. >>>> >>>> Alternatives >>>> ------------ >>>> An alternative would be to introduce new syntax to restrict the ability >>>> of certain constructors on a parameter type. Like c# does (but only for the >>>> default constructor) : >>>> public static T foo() where T: new() { >>>> return new T(); >>>> } >>>> In java: >>>> public static T foo() { >>>> return new T(); >>>> } >>>> The downside of this approach is obviously the introduction of new >>>> syntax rather than reusing the interface/inheritance syntax. >>>> >>>> Another alternative to this approach could be to implement static >>>> abstract methods. This would allow an interface to mandate a static Factory >>>> Method. The downside of this approach is that it requires the parameter >>>> class to actually implement the interface and the concept of type erasure >>>> would need to be addressed for static abstract methods to work. In contrast >>>> the ConstructorInterface enables every class that matches its contract to >>>> pass the type bound. >>>> >>>> >>>> >>>> Risks and Assumptions >>>> --------------------- >>>> >>>> As mentioned before the restriction the interface is giving on a type >>>> bound is different to normal interfaces, it restricts by its containing >>>> abstract constructors not by the type itself. It also makes use of the new >>>> operator on type variables. >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redio.development at gmail.com Mon Feb 20 17:59:43 2023 From: redio.development at gmail.com (Red IO) Date: Mon, 20 Feb 2023 18:59:43 +0100 Subject: Dependency Injection Message-ID: Reason/Background: I was building a server application (in java) designed around the mediator pattern and dependency injection inspired by a c# server application tutorial. So I was researching but every dependency injection framework was relying on bytecode manipulation to do the injection. For background I really dislike bytecode manipulation for production code. So I researched what the jdk provides and what not. I discovered that the jdk provides service loading capabilities in form of the ServiceLoader api. But it is pretty barebones only allowing creation of service implementations providing a no-args constructor. Idea: I thought that this could be expanded to allow loading of services that depend on other services (In form of constructor parameters) that can be loaded with associated ServiceLoaders. So I coded a small test wrapper for ServiceLoader that does the injection of known services. I used MethodHandles to create factory handles that use the associated loaders to fill in the constructor and in that way avoided bytecode manipulation. Suggestion: I was wondering if this concept would be interesting to incorporate into the jdk as an expansion of the ServiceLoader api. Great regards RedIODev -------------- next part -------------- An HTML attachment was scrubbed... URL: From kasperni at gmail.com Mon Feb 20 19:57:20 2023 From: kasperni at gmail.com (Kasper Nielsen) Date: Mon, 20 Feb 2023 19:57:20 +0000 Subject: Dependency Injection In-Reply-To: References: Message-ID: > Suggestion: > I was wondering if this concept would be interesting to incorporate into the jdk as an expansion of the ServiceLoader api. > I think the practical use cases for this are going to be very limited. ServiceLoader always creates a new service per request. So if both B and C depend on A. Two instances of A will be created. Which is rarely what you want when you are composing an application. /Kasper From forax at univ-mlv.fr Mon Feb 20 20:25:49 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 20 Feb 2023 21:25:49 +0100 (CET) Subject: Dependency Injection In-Reply-To: References: Message-ID: <1530321701.26503463.1676924749937.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Kasper Nielsen" > To: "Red IO" > Cc: "amber-dev" > Sent: Monday, February 20, 2023 8:57:20 PM > Subject: Re: Dependency Injection >> Suggestion: >> I was wondering if this concept would be interesting to incorporate into the jdk >> as an expansion of the ServiceLoader api. >> > > I think the practical use cases for this are going to be very limited. > ServiceLoader always creates a new service per request. So if both B and C > depend on A. Two instances of A will be created. Which is rarely what > you want when you are composing an application. It depends if you implement the static method provider or use the default constructor. > > /Kasper R?mi From forax at univ-mlv.fr Mon Feb 20 20:48:16 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 20 Feb 2023 21:48:16 +0100 (CET) Subject: Dependency Injection In-Reply-To: References: Message-ID: <1555333223.26506800.1676926096644.JavaMail.zimbra@u-pem.fr> > From: "Red IO" > To: "amber-dev" > Sent: Monday, February 20, 2023 6:59:43 PM > Subject: Dependency Injection > Reason/Background: > I was building a server application (in java) designed around the mediator > pattern and dependency injection inspired by a c# server application tutorial. > So I was researching but every dependency injection framework was relying on > bytecode manipulation to do the injection. Bytecode manipulation at compile-time (like Quarkus) or runtime (like Spring) ? And there are several DI libraries that leverage annotation processors without doing bytecode transformation, i think the most popular is Dagger 2. > For background I really dislike bytecode manipulation for production code. > So I researched what the jdk provides and what not. I discovered that the jdk > provides service loading capabilities in form of the ServiceLoader api. But it > is pretty barebones only allowing creation of service implementations providing > a no-args constructor. > Idea: > I thought that this could be expanded to allow loading of services that depend > on other services (In form of constructor parameters) that can be loaded with > associated ServiceLoaders. > So I coded a small test wrapper for ServiceLoader that does the injection of > known services. > I used MethodHandles to create factory handles that use the associated loaders > to fill in the constructor and in that way avoided bytecode manipulation. I do not understand, once a method handle becomes hot, the JDK will generate the corresponding bytecodes, so how it is different from a DI that generate bytecodes ? And usually it's harder to get good performance from method handles if the JIT does not see them as a constant. > Suggestion: > I was wondering if this concept would be interesting to incorporate into the jdk > as an expansion of the ServiceLoader api. There was a jlink plugin doing the ServiceLoader resolution at link time if the service was specified in the module-info, i do not know if it still exist or not, but it looks like a good condenser for the project Leyden. > Great regards > RedIODev R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kasperni at gmail.com Mon Feb 20 20:56:14 2023 From: kasperni at gmail.com (Kasper Nielsen) Date: Mon, 20 Feb 2023 20:56:14 +0000 Subject: Dependency Injection In-Reply-To: <1530321701.26503463.1676924749937.JavaMail.zimbra@u-pem.fr> References: <1530321701.26503463.1676924749937.JavaMail.zimbra@u-pem.fr> Message-ID: On Mon, 20 Feb 2023 at 20:25, Remi Forax wrote: > > ----- Original Message ----- > > From: "Kasper Nielsen" > > To: "Red IO" > > Cc: "amber-dev" > > Sent: Monday, February 20, 2023 8:57:20 PM > > Subject: Re: Dependency Injection > > >> Suggestion: > >> I was wondering if this concept would be interesting to incorporate into the jdk > >> as an expansion of the ServiceLoader api. > >> > > > > I think the practical use cases for this are going to be very limited. > > ServiceLoader always creates a new service per request. So if both B and C > > depend on A. Two instances of A will be created. Which is rarely what > > you want when you are composing an application. > > It depends if you implement the static method provider or use the default constructor. Of course, you could cache the instance in the static method provider. But that is even more code. On top of all the managing of individual services in META-INF/services or module-info.java you also need to do. /Kasper /Kasper From forax at univ-mlv.fr Mon Feb 20 21:41:53 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 20 Feb 2023 22:41:53 +0100 (CET) Subject: Dependency Injection In-Reply-To: References: <1530321701.26503463.1676924749937.JavaMail.zimbra@u-pem.fr> Message-ID: <436093287.26511289.1676929313188.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Kasper Nielsen" > To: "Remi Forax" > Cc: "Red IO" , "amber-dev" > Sent: Monday, February 20, 2023 9:56:14 PM > Subject: Re: Dependency Injection > On Mon, 20 Feb 2023 at 20:25, Remi Forax wrote: >> >> ----- Original Message ----- >> > From: "Kasper Nielsen" >> > To: "Red IO" >> > Cc: "amber-dev" >> > Sent: Monday, February 20, 2023 8:57:20 PM >> > Subject: Re: Dependency Injection >> >> >> Suggestion: >> >> I was wondering if this concept would be interesting to incorporate into the jdk >> >> as an expansion of the ServiceLoader api. >> >> >> > >> > I think the practical use cases for this are going to be very limited. >> > ServiceLoader always creates a new service per request. So if both B and C >> > depend on A. Two instances of A will be created. Which is rarely what >> > you want when you are composing an application. >> >> It depends if you implement the static method provider or use the default >> constructor. > > Of course, you could cache the instance in the static method provider. > But that is even more code. On top of all the managing of individual services > in META-INF/services or module-info.java you also need to do. Sadly it's not even "or", it's "and" because you can always put a modular jar into the classpath (not with Maven but it's too easy with Gradle) and in that case only the META-INF/services will be read, the module-info.class will be ignored. > > > /Kasper R?mi From hjohn at xs4all.nl Tue Feb 21 17:21:39 2023 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 21 Feb 2023 17:21:39 +0000 Subject: Dependency Injection In-Reply-To: References: Message-ID: Hi, I wrote my own DI framework, and byte code manipulation is not a requirement to do DI. The basic functionality is provided with reflection only. Most frameworks should be doing exactly that. Byte code manipulation is only a requirement when the same can't be achieved by using a JDK interface based proxy. If there is no suitable interface that can be proxied in such a way, then the only option left is to create a dynamic subclass. This is often done for injecting scoped dependencies in a dependency with a different scope (ie, a request scoped dependency injected into a singleton requires the request scoped dependency to be proxied). Other features that may require byte code manipulation are assisted injection, wrappers, AOP, etc. --John ------ Original Message ------ >From "Red IO" To "amber-dev" Date 20/02/2023 18:59:43 Subject Dependency Injection >Reason/Background: >I was building a server application (in java) designed around the >mediator pattern and dependency injection inspired by a c# server >application tutorial. So I was researching but every dependency >injection framework was relying on bytecode manipulation to do the >injection. >For background I really dislike bytecode manipulation for production >code. >So I researched what the jdk provides and what not. I discovered that >the jdk provides service loading capabilities in form of the >ServiceLoader api. But it is pretty barebones only allowing creation of >service implementations providing a no-args constructor. > >Idea: >I thought that this could be expanded to allow loading of services that >depend on other services (In form of constructor parameters) that can >be loaded with associated ServiceLoaders. >So I coded a small test wrapper for ServiceLoader that does the >injection of known services. >I used MethodHandles to create factory handles that use the associated >loaders to fill in the constructor and in that way avoided bytecode >manipulation. > >Suggestion: >I was wondering if this concept would be interesting to incorporate >into the jdk as an expansion of the ServiceLoader api. > >Great regards >RedIODev -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Tue Feb 21 21:28:51 2023 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 21 Feb 2023 16:28:51 -0500 Subject: CFV: New amber Committer: Archie Cobbs In-Reply-To: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> References: <1367c114-a2b7-d2f9-a608-3d35ace0e612@oracle.com> Message-ID: <4f5e1c53-b76a-78ed-ead6-6eeb711d8ba2@oracle.com> Voting for Archie Cobbs [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.org/pipermail/amber-dev/2023-February/007810.html On 2/7/23 18:38, Vicente Romero wrote: > I hereby nominate Archie Cobbs [acobbs] as a committer in the amber > Project. > > Archie Cobbs [1] is an author of the jdk project; he has been working > on javac, fixing bugs and implementing enhancements in different areas > of the compiler. > One of these bugs have entity enough to be considered a JEP that would > initially be implemented in the amber repo, see [2]. > > He has made about 13 changes [3] to the OpenJDK repository. > Votes are due by 20:00 UTC February 21, 2023. > > Only current committers and reviewers of the amber Project [4] are > eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > Vicente Romero > > [1] https://openjdk.org/census#acobbs > [2]https://bugs.openjdk.org/browse/JDK-8300786 > [3] > https://github.com/openjdk/jdk/search?q=author-name%3A%22Cobbs%22&type=commits > [4] https://openjdk.org/census#amber > [5] https://openjdk.org/groups/#member-vote From ice1000kotlin at foxmail.com Thu Feb 23 07:54:25 2023 From: ice1000kotlin at foxmail.com (=?utf-8?B?VGVzbGEgWmhhbmc=?=) Date: Thu, 23 Feb 2023 02:54:25 -0500 Subject: Small question regarding Java generics & sealed interfaces Message-ID: Hi all, I am experimenting with Java generics and I have the following question (all the code in this email can be found at https://gist.github.com/ice1000/e376089438dd115c369329d00ee27779). Here's some simple prelude definitions (the gist is more informative): sealed interface Nat From gavin.bierman at oracle.com Tue Feb 28 16:21:42 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 28 Feb 2023 16:21:42 +0000 Subject: Draft JEPs for Patterns in switch and Record Patterns Message-ID: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> Hello, We are planning to finalize the two pattern matching JEPs in JDK 21. Drafts of these final JEPs are available here: Pattern matching for switch: https://openjdk.org/jeps/8300542 Record patterns: https://openjdk.org/jeps/8300541 We're proposing some small changes from the preview versions about to appear in JDK 20. These include: - We're dropping parenthesized patterns. They were leftover from a previous version of patterns, and they weren't used very much. They complicate the spec for not a lot of gain. - We're going to support case labels that are the qualified name of enum constants, and allow switches over non-enum types to have enum case labels provided they use the qualified names of the enum constants and these labels are assignment compatible with the switch type. - We're dropping the support for record patterns in the header of enhanced for statements. These will re-appear in a separate forthcoming JEP. Please take a look at these new JEPs and give us your feedback (either on this list or directly to me). Thanks, Gavin From forax at univ-mlv.fr Tue Feb 28 17:09:04 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 Feb 2023 18:09:04 +0100 (CET) Subject: Draft JEPs for Patterns in switch and Record Patterns In-Reply-To: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> References: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> Message-ID: <6918508.521390.1677604144441.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Gavin Bierman" > To: "amber-dev" > Cc: "amber-spec-experts" > Sent: Tuesday, February 28, 2023 5:21:42 PM > Subject: Draft JEPs for Patterns in switch and Record Patterns > Hello, > > We are planning to finalize the two pattern matching JEPs in JDK 21. Drafts of > these final JEPs are available here: > > Pattern matching for switch: https://openjdk.org/jeps/8300542 > Record patterns: https://openjdk.org/jeps/8300541 > > We're proposing some small changes from the preview versions about to appear in > JDK 20. These include: > > - We're dropping parenthesized patterns. They were leftover from a previous > version of patterns, and they weren't used very much. They complicate the spec > for not a lot of gain. And reuse parenthesis as the syntax for tuple patterns (whatever it is exactly). > > - We're going to support case labels that are the qualified name of enum > constants, and allow switches over non-enum types to have enum case labels > provided they use the qualified names of the enum constants and these labels > are assignment compatible with the switch type. I wonder if we can not extends the unqualified enum value syntax to any sealed hierarchy that contains an enum with that constant. By example, sealed interface HList permits Cons, Nil {} enum Nil implements HList { NIL } record Cons(int val, HList next) implements HList {} HList list = ... switch(list) { case NIL -> ... // the compiler can replace it by Nil.NIL if there is only one enum value named NIL in the hierarchy ... } Perhaps it's a step too far ? > > - We're dropping the support for record patterns in the header of enhanced for > statements. These will re-appear in a separate forthcoming JEP. I hope that enhanced for and destructuring assignment will have the same semantics. > > Please take a look at these new JEPs and give us your feedback (either on this > list or directly to me). > > Thanks, > Gavin Thanks, R?mi From brian.goetz at oracle.com Tue Feb 28 20:29:05 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 28 Feb 2023 15:29:05 -0500 Subject: Draft JEPs for Patterns in switch and Record Patterns In-Reply-To: <6918508.521390.1677604144441.JavaMail.zimbra@u-pem.fr> References: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> <6918508.521390.1677604144441.JavaMail.zimbra@u-pem.fr> Message-ID: In fact, the plan is to move destructuring-for into the destructuring-assignment JEP. On 2/28/2023 12:09 PM, Remi Forax wrote: > I hope that enhanced for and destructuring assignment will have the same semantics. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjohn at xs4all.nl Tue Feb 28 21:11:39 2023 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 28 Feb 2023 21:11:39 +0000 Subject: Draft JEPs for Patterns in switch and Record Patterns In-Reply-To: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> References: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> Message-ID: In https://openjdk.org/jeps/8300542, the example in "Improved support for enum constant case labels" seems to be incorrect. I think the `goodEnumSwitch2`: static void goodEnumSwitch2(Currency c) { Should use `Coin` as parameter: static void goodEnumSwitch2(Coin c) { Also, the enum is called `Coin`, but `Coins` is used a qualifier in several places. --John ------ Original Message ------ >From "Gavin Bierman" To "amber-dev at openjdk.org" Cc "amber-spec-experts" Date 28/02/2023 17:21:42 Subject Draft JEPs for Patterns in switch and Record Patterns >Hello, > >We are planning to finalize the two pattern matching JEPs in JDK 21. Drafts of >these final JEPs are available here: > >Pattern matching for switch: https://openjdk.org/jeps/8300542 >Record patterns: https://openjdk.org/jeps/8300541 > >We're proposing some small changes from the preview versions about to appear in >JDK 20. These include: > >- We're dropping parenthesized patterns. They were leftover from a previous >version of patterns, and they weren't used very much. They complicate the spec >for not a lot of gain. > >- We're going to support case labels that are the qualified name of enum >constants, and allow switches over non-enum types to have enum case labels >provided they use the qualified names of the enum constants and these labels >are assignment compatible with the switch type. > >- We're dropping the support for record patterns in the header of enhanced for >statements. These will re-appear in a separate forthcoming JEP. > >Please take a look at these new JEPs and give us your feedback (either on this >list or directly to me). > >Thanks, >Gavin > From forax at univ-mlv.fr Tue Feb 28 21:30:05 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 Feb 2023 22:30:05 +0100 (CET) Subject: Draft JEPs for Patterns in switch and Record Patterns In-Reply-To: References: <322686D2-BD86-4F05-BA33-C4017C772DB5@oracle.com> Message-ID: <1668423924.590526.1677619805010.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John Hendrikx" > To: "Gavin Bierman" , "amber-dev" > Cc: "amber-spec-experts" > Sent: Tuesday, February 28, 2023 10:11:39 PM > Subject: Re: Draft JEPs for Patterns in switch and Record Patterns > In https://openjdk.org/jeps/8300542, the example in "Improved support > for enum constant case labels" seems to be incorrect. > > I think the `goodEnumSwitch2`: > > static void goodEnumSwitch2(Currency c) { > > Should use `Coin` as parameter: > > static void goodEnumSwitch2(Coin c) { > > Also, the enum is called `Coin`, but `Coins` is used a qualifier in > several places. > > --John Also s.equalsIgnoreCase("YES") is better than s.toUpperCase().equals("YES") R?mi > > ------ Original Message ------ > From "Gavin Bierman" > To "amber-dev at openjdk.org" > Cc "amber-spec-experts" > Date 28/02/2023 17:21:42 > Subject Draft JEPs for Patterns in switch and Record Patterns > >>Hello, >> >>We are planning to finalize the two pattern matching JEPs in JDK 21. Drafts of >>these final JEPs are available here: >> >>Pattern matching for switch: https://openjdk.org/jeps/8300542 >>Record patterns: https://openjdk.org/jeps/8300541 >> >>We're proposing some small changes from the preview versions about to appear in >>JDK 20. These include: >> >>- We're dropping parenthesized patterns. They were leftover from a previous >>version of patterns, and they weren't used very much. They complicate the spec >>for not a lot of gain. >> >>- We're going to support case labels that are the qualified name of enum >>constants, and allow switches over non-enum types to have enum case labels >>provided they use the qualified names of the enum constants and these labels >>are assignment compatible with the switch type. >> >>- We're dropping the support for record patterns in the header of enhanced for >>statements. These will re-appear in a separate forthcoming JEP. >> >>Please take a look at these new JEPs and give us your feedback (either on this >>list or directly to me). >> >>Thanks, >>Gavin