Random access in ArrayDeque

I noticed recently that the javac scanner is making use of ArrayList.remove(0) when it consumes a buffer. Obviously this is an inefficient way to implement a buffer, so I thought I'd try to fix it [1]. ArrayDeque seems to provide just the behavior I need, with one fatal flaw: despite encoding

Re: please review draft JEP: Convenience Factory Methods for Collections

The motivation section ought to more directly survey what we have now: - Collections.emptyList/emptySet/emptyMap - Collections.singletonList/singleton/singletonMap - Arrays.asList - EnumSet.of (varargs, plus some overloads) - Stream.empty and Stream.of (singleton plus varargs) - Constructors that,

Re: Use of super in type parameters

On Apr 17, 2013, at 6:11 PM, Zhong Yu zhong.j...@gmail.com wrote: On Wed, Apr 17, 2013 at 4:53 PM, Martin Buchholz marti...@google.com wrote: With the coming of lambda, it is more likely that people will be creating APIs with not quite correct generic types, as we are doing in I believe

Re: Code Review Request: More tests for 7184826: (reflect) Add support for Project Lambda concepts in core reflection

Hi. Per a request from Joel, I've taken a look at DefaultStaticTestData. I don't really have the full context here, but I'm assuming that the annotations get translated into tests that guarantee 1) the result of Class.getMethods is exactly (no more -- excepting Object methods -- and no less)

RFR JDK-8022442: Fix unchecked warnings in HashMap

Please review this warnings cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00/ —Dan

Re: RFR JDK-8022442: Fix unchecked warnings in HashMap

Update: some minor changes are necessary to LinkedHashMap to be compatible with the HashMap changes (HashMap is unchanged). Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.01/ I confirmed that the jdk_util tests pass. —Dan On Aug 6, 2013, at 2:11 PM, Dan Smith daniel.sm

Re: RFR JDK-8022442: Fix unchecked warnings in HashMap

was enext added?: 1249 EntryK,V enext = (EntryK,V) newTable[i]; 1250 e.next = enext; Thanks, -Brent On 8/6/13 2:11 PM, Dan Smith wrote: Please review this warnings cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) Webrev: http

Re: RFR JDK-8022442: Fix unchecked warnings in HashMap

On Aug 6, 2013, at 2:43 PM, Remi Forax fo...@univ-mlv.fr wrote: On 08/06/2013 11:11 PM, Dan Smith wrote: Please review this warnings cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022442 (not yet visible) Webrev: http://cr.openjdk.java.net/~dlsmith/8022442/webrev.00

Enumeration adapters in SE 8

I was pointed to some comments on core-libs about adapting Enumerations to for loops in SE 8. (Sorry for the new thread -- I wasn't subscribed.) It turns out lambdas + extension methods will make this very easy. In the API: interface EnumerationE extends IteratorE { boolean

Lambda-fied pattern matching

Working with the pattern matching API, I noticed that it could be made a lot less clumsy with some lambdafication. Here's the status quo: Pattern p = Pattern.compile((\w)*, (\d)*, (\w)*); for (String s : lines) { Matcher m = p.matcher(str); if (m.match(s)) {

Stream optimization suggestions

I've submitted a couple of RFEs to support some simple optimizations on Streams. I noticed both issues while writing some code that forced me to choose between cluttering up my straightforward, uniform Stream logic and eating the cost of linear operations that should be O(1). JDK-8067969

Re: Lambda-fied pattern matching

On Nov 19, 2014, at 4:10 PM, Remi Forax fo...@univ-mlv.fr wrote: and yes, please log a RFE. RFE is here: https://bugs.openjdk.java.net/browse/JDK-8067973

Re: AbstractList etc. functionality as interfaces with default methods?

On May 14, 2015, at 7:24 AM, Remi Forax fo...@univ-mlv.fr wrote: On 05/14/2015 03:05 PM, Brian Goetz wrote: Not only is there a problem with modCount, but also with equals/hashCode/toString. You can’t define these Object methods in an interface. They could be defined as static methods

RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

Hi, making a change to serialization's computation of UID in order to avoid taking ACC_FINAL into account for anonymous inner classes. Will also change the Serialization Specification. https://bugs.openjdk.java.net/browse/JDK-8159751 The patch is small, inline below. Not sure about the best

Re: RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

> On Jun 23, 2016, at 11:37 AM, Roger Riggs wrote: > > Hi Dan, > > I was concerned about inter-operation between versions because serialized > objects > are passed between Java runtimes with different versions and both need to > compute > the same serial version uid

Re: RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

> On Jun 23, 2016, at 8:51 AM, Roger Riggs wrote: > > Hi Dan, > > Is setting ACC_FINAL for anonymous inner classes a unique feature of the > latest bytecode version? > (javac -target 9) > > Was it always clear in class files with earlier bytecode versions? This is a

Re: RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

> On Jun 23, 2016, at 3:21 PM, Roger Riggs wrote: >>> I would suggest javac to produce the same ACC_FINAL bits as it did before >>> for each -target version. >>> (I know it looks like a hack, but a compatible one). >>> Correct it for 9 and leave the SUID computation

Re: RFR 8159751: ObjectStreamClass: hide 'final' flag for anonymous classes

> On Jun 23, 2016, at 2:04 PM, Roger Riggs <roger.ri...@oracle.com> wrote: > > Hi Dan, > > On 6/23/2016 2:53 PM, Dan Smith wrote: >>> On Jun 23, 2016, at 11:37 AM, Roger Riggs <roger.ri...@oracle.com> >>> wrote: >>> >>> Hi Dan,

Re: JEP 293: Guidelines for JDK Command-Line Tool Options

> On Jul 8, 2016, at 8:01 AM, Jonathan Gibbons <jonathan.gibb...@oracle.com> > wrote: > > On 07/07/2016 11:07 PM, Dan Smith wrote: >> A suggestion for clarifying the text: I was confused about whether "may" >> refers to choices that the tool

Re: JEP 293: Guidelines for JDK Command-Line Tool Options

A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. For example: "Options can require an argument to be provided. For a long-form options, the argument may be

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

I noticed that something like the following doesn't behave how you'd probably expect. "int x = 23;".entab(4) --> "\tint\tx =\t23;" For other strings, the intent is ambiguous (are the first and last name two fields, or only one?): "Dan Smith daniel.smith".ent

RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ Please review this update to java.lang.invoke.LambdaMetafactory. Adds some argument validation with tests; improves documentation; renames some variables. JBS: https://bugs.openjdk.java.net/browse/JDK-8174222 —Dan

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

> On Mar 21, 2019, at 8:58 AM, Brian Goetz wrote: > > +1 from me. > > >> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ >> >> > > AbstractValidatingLMF > - > > I see you renamed most of the fields and params. Most of these are > improvements, but it may be

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

> On Mar 20, 2019, at 11:22 PM, Mandy Chung wrote: > > On 3/20/19 9:03 PM, Dan Smith wrote: >> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/ > > AbstractValidatingLambdaMetafactory.java > +throw new LambdaConversionException("implementati

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal > - Revise "value-

RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

Integration of JEP 390, addressing the following issues: 8252180: [JEP 390] Deprecate wrapper class constructors for removal 8254047: [JEP 390] Revise "value-based class" & apply to wrappers 8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased 8252183: [JEP 390] Add 'lint' warning

Integrated: 8257845: Integrate JEP 390

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecat

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

On Wed, 2 Dec 2020 17:57:22 GMT, Mandy Chung wrote: > I suggest `Class::getPermittedSubclasses` to return a `non-null` array if > this `Class` is sealed, i.e. this class is derived from a `class` file with > the presence of `PermittedSubclasses` attribute regardless of its content > (the

RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError

Small bug fix. - Commit messages: - Fix merge markup - Merge branch 'master' into 8268192 - Merge branch '8174222' into 8268192 - Fix stray renaming - Apply renamings to LambdaProxyClassArchive - Address reviewer comments - Turn back on test case that was failing - Merge

Integrated: 8174222: LambdaMetafactory: validate inputs and improve documentation

On Thu, 3 Jun 2021 20:03:53 GMT, Dan Smith wrote: > Standardizes and better specifies the errors thrown by LambdaMetafactory, > including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect t

Re: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2]

On Tue, 8 Jun 2021 15:17:44 GMT, Dan Smith wrote: >> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java >> line 191: >> >>> 189: useImplMethodHandle = >>> (Modifier.isProtected

Re: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2]

On Tue, 8 Jun 2021 02:23:09 GMT, liach wrote: >> Dan Smith has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Clean up validation of implKind REF_invokeSpecial > > src/java.base/

Re: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2]

> Small bug fix. Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Clean up validation of implKind REF_invokeSpecial - Changes: - all: https://git.openjdk.java.net/jdk/pull/4403/files - new: https://git.openjdk.java.

Re: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2]

On Tue, 8 Jun 2021 15:27:04 GMT, Dan Smith wrote: >> Small bug fix. > > Dan Smith has updated the pull request incrementally with one additional > commit since the last revision: > > Clean up validation of implKind REF_invokeSpecial src/java.base/share/cla

Integrated: 8268192: LambdaMetafactory with invokespecial causes VerificationError

On Mon, 7 Jun 2021 23:58:44 GMT, Dan Smith wrote: > Small bug fix. This pull request has now been integrated. Changeset: 58ba48b7 Author: Dan Smith URL: https://git.openjdk.java.net/jdk/commit/58ba48b7b88eff359683aa3271c48b18f1973282 Stats: 27 lines in 3 files changed: 7 ins;

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v4]

any methods, which is not a > good fit for what these methods do (they don't delegate to each other, but > all invoke the same implementation method). Dan Smith has updated the pull request incrementally with two additional commits since the last revision: - Fix stray ren

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2]

On Fri, 4 Jun 2021 01:22:05 GMT, liach wrote: >> Dan Smith has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/share/classes/java/lang/invoke/L

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3]

any methods, which is not a > good fit for what these methods do (they don't delegate to each other, but > all invoke the same implementation method). Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Address reviewer comments ---

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2]

On Fri, 4 Jun 2021 00:08:41 GMT, Mandy Chung wrote: >> Dan Smith has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/share/classes/java/lang/invo

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2]

On Fri, 4 Jun 2021 06:16:45 GMT, Peter Levart wrote: >> Dan Smith has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3]

On Fri, 4 Jun 2021 22:06:49 GMT, Mandy Chung wrote: >> Dan Smith has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address reviewer comments > > src/java.base/share/classes/java/lang/invoke/LambdaMetafa

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3]

On Fri, 4 Jun 2021 22:09:39 GMT, Mandy Chung wrote: > Can you also rename the parameter names in > `java.lang.invoke.LambdaProxyClassArchive` methods to match the new ones? Hmm, that expands the reach of the patch a bit—into native HotSpot code—but I've given it a try. Let me know if it looks

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

On Thu, 3 Jun 2021 20:03:53 GMT, Dan Smith wrote: > Standardizes and better specifies the errors thrown by LambdaMetafactory, > including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect t

RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. Does some renaming of core parameters/fields to better reflect their purpose. In the implementation, stops using ACC_BRIDGE for any methods, which is not a good

Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2]

any methods, which is not a > good fit for what these methods do (they don't delegate to each other, but > all invoke the same implementation method). Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Fix accidentally com

Re: Proposal for Decimal64 and Decimal128 value-based classes

> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore > wrote: > > What I'd be curious though, is if the @ValueBased annotation could be > enhanced to say _which_ primitive class default you want (and then javac > could enforce extra checks if you pick the "val" default). If something like >

Re: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v4]

On Thu, 28 Oct 2021 20:26:47 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate >> `REF_invokeSpecial` if the implementation method is a private instance >> method. Since a lambda proxy class is a hidden class, a nestmate of the >> host class, it can

Re: RFR: JDK-8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior [v2]

On Tue, 12 Oct 2021 16:21:33 GMT, Mandy Chung wrote: >> Classes compiled prior to the nestmate support will generate >> `REF_invokeSpecial` if the implementation method is a private instance >> method. Since a lambda proxy class is a hidden class, a nestmate of the >> host class, it can