Re: RFR: 8268113: Re-use Long.hashCode() where possible [v9]

On Wed, 2 Jun 2021 14:11:07 GMT, Сергей Цыпанов wrote: >> Сергей Цыпанов has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains ten additional >>

Re: JDK Dynalink only works with unconditionally exported packages

On 2021. May 11., at 1:51, Thiago Henrique Hupner wrote: > > Hi all. > > I've been testing the JDK Dynalink recently and > I think I've found a bug. > > The class jdk.dynalink.beans.CheckRestrictedPackage checks > if a package is restricted. > > So, I have a class that has some static

Re: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

I'm fine with the removal, although if you remember we use it in Nashorn too[0], and when I tried to replace it with the hidden classes facility the issue we run into was that hidden classes' methods didn't show up in stack traces the way anonymous classes' methods did[1]. Since Nashorn uses

Integrated: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation

On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi wrote: > I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods > had a lot of code duplication among themselves, and even within each method. > I refactored them into a modern unified implementation. While the

Re: RFR: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation [v2]

On Tue, 30 Mar 2021 12:43:18 GMT, Athijegannathan Sundararajan wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR

Integrated: 8262503: Support records in Dynalink

On Sun, 28 Feb 2021 16:46:31 GMT, Attila Szegedi wrote: > 8262503: Support records in Dynalink This pull request has now been integrated. Changeset: b08d6383 Author: Attila Szegedi URL: https://git.openjdk.java.net/jdk/commit/b08d6383 Stats: 165 lines in 8 files changed: 153

Re: RFR: 8262503: Support records in Dynalink

On Tue, 30 Mar 2021 12:38:41 GMT, Athijegannathan Sundararajan wrote: >> 8262503: Support records in Dynalink > > Looks good Thank you for the review, @sundararajana! - PR: https://git.openjdk.java.net/jdk/pull/2767

Re: RFR: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation [v2]

quireNonNull` in place of null > checks followed by NPE throws, mark private fields final where possible, use > lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where > possible, and generally sanitize/deduplicate. Attila Szegedi has refreshed the contents of this pull

Re: RFR: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation [v2]

On Sat, 27 Mar 2021 15:46:36 GMT, Alan Bateman wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. The pull reque

RFR: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation

I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place

Re: RFR: 8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation

On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi wrote: > I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods > had a lot of code duplication among themselves, and even within each method. > I refactored them into a modern unified implementation. While the

Re: Class.getRecordComponents security checks

> On 2021. Feb 21., at 21:57, Remi Forax wrote: > > - Mail original - >> De: "Attila Szegedi" >> À: "core-libs-dev" >> Envoyé: Dimanche 21 Février 2021 21:14:48 >> Objet: Class.getRecordComponents security c

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v4]

On Mon, 1 Mar 2021 11:09:31 GMT, Peter Levart wrote: >> Attila Szegedi has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains one add

Integrated: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

On Wed, 17 Feb 2021 19:44:35 GMT, Attila Szegedi wrote: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with > "AssertionError: Should have GCd a method handle by now" This pull request has now been integrated. Changeset: d185a6c5 Author: Att

RFR: 8262503: Support records in Dynalink

8262503: Support records in Dynalink - Commit messages: - Document behavior changes - Add support for records to Dynalink - Test the desired functionality Changes: https://git.openjdk.java.net/jdk/pull/2767/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2767=00

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v3]

On Sun, 28 Feb 2021 07:20:19 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > &g

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v4]

> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with > "AssertionError: Should have GCd a method handle by now" Attila Szegedi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 82

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]

On Fri, 26 Feb 2021 08:03:26 GMT, Peter Levart wrote: >> The good test would be trying with all current GCs (Serial, Parallel, G1, >> Shenandoah, ZGC): >> >> make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC >> >> Also, make sure that GH actions are able to run this test. You

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]

On Thu, 25 Feb 2021 15:34:10 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > &g

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]

On Thu, 25 Feb 2021 15:34:30 GMT, Aleksey Shipilev wrote: >> Attila Szegedi has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > &g

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v3]

> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with > "AssertionError: Should have GCd a method handle by now" Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show diff

Class.getRecordComponents security checks

Hey folks, Why are security checks for Class.getRecordComponents as strict as those for e.g. getDeclaredMethods? I would’ve expected they’d be as strict as those for e.g. getMethods. Specifically, the difference is the: > “the caller's class loader is not the same as the class loader of this

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

On Fri, 19 Feb 2021 11:22:57 GMT, Peter Levart wrote: >I would like 1st to understand why the MH created in the >TestLinker.convertToType is actually GCed at all. The whole original issue was about allowing these objects to be GCd . Short story: because all data is scoped to objects created

Re: RFR: 8261290: Improve error message for NumberFormatException on null input

On Sat, 20 Feb 2021 21:44:12 GMT, Joe Darcy wrote: > In Integer and Long, several of the parsing methods are specified to throw > NumberFormatException on a null input rather than an NPE. That behavior is > not proposed to be modified. However, I think it is reasonable for the >

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

On Wed, 17 Feb 2021 19:44:35 GMT, Attila Szegedi wrote: > 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with > "AssertionError: Should have GCd a method handle by now" @plevart can I bother you for a follow-up review of my original issue? (Alternat

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]

> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with > "AssertionError: Should have GCd a method handle by now" Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show diff

RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" - Commit messages: - 8261483: Try to eliminate flakiness of the test by extending its allowed runtime and reducing the memory Changes:

Integrated: 8198540: Dynalink leaks memory when generating type converters

On Sat, 2 Jan 2021 14:45:51 GMT, Attila Szegedi wrote: > _(NB: For this leak to occur, an application needs to be either creating and > discarding linkers frequently, or creating and discarding class loaders > frequently while creating Dynalink type converters for classes in them.

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v7]

On Tue, 9 Feb 2021 10:57:05 GMT, Hannes Wallnöfer wrote: >> Attila Szegedi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Rename ClassLoaderRelation to RetentionDirection; it is better >> self-docum

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v7]

On Sun, 10 Jan 2021 23:30:58 GMT, Peter Levart wrote: >>> How frequent are situations where the two classloaders are unrelated? >> >> I think they'd be extremely unlikely. The only user of these right now is >> Dynalink's type converter factory. I _can imagine_ a situation where there's >> a

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]

On Mon, 11 Jan 2021 05:12:11 GMT, Johannes Kuhn wrote: >> Simple fix - one line change: >> https://openjdk.github.io/cr/?repo=jdk=2000=00#sdiff-0. >> >> Most of the changes come from an additional test that fails without this fix: >> >> Error: Unable to load main class

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v2]

On Sun, 10 Jan 2021 16:35:17 GMT, Johannes Kuhn wrote: >> Simple fix - one line change: >> https://openjdk.github.io/cr/?repo=jdk=2000=00#sdiff-0. >> >> Most of the changes come from an additional test that fails without this fix: >> >> Error: Unable to load main class

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v7]

On Sun, 10 Jan 2021 17:18:37 GMT, Peter Levart wrote: > How frequent are situations where the two classloaders are unrelated? I think they'd be extremely unlikely. The only user of these right now is Dynalink's type converter factory. I _can imagine_ a situation where there's a conversion

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v7]

On Fri, 8 Jan 2021 18:58:03 GMT, Peter Levart wrote: >> So, are you saying the solution where I kept the fields volatile and >> initialized them with `Map.of()` is safe? If so, that'd be good news; I'm >> inclined these days to write as much null-free code as possible :-) > > Yes, the

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v7]

mes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v6]

mes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila Szegedi has

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v5]

On Fri, 8 Jan 2021 13:32:08 GMT, Peter Levart wrote: >>> IIUC, your changes mostly all flow from the decision to declare the fields >>> as non-volatile; if they were still declared as volatile then it'd be >>> impossible to observe null in them, I think (correct me if I'm wrong; it >>> seems

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v5]

mes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila Szegedi has up

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v4]

On Fri, 8 Jan 2021 11:06:17 GMT, Peter Levart wrote: > So what do you think of this variant: I like it. I originally kept the fields volatile so that we don't observe stale values on `getForward`/`getReverse`, but you're right in that even if we do, the correct value will be observed when

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v4]

mes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila Szege

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v4]

On Mon, 4 Jan 2021 13:31:41 GMT, Peter Levart wrote: >> Just a small suggestion using `MethodHandles.empty` instead of >> `MethodHandles.constant().asType().dropArguments()`. > > Hi Attila, > > This looks good. > > If I understand correctly, your `BiClassValue` is a holder for a `BiFunction`

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v3]

nce becomes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila Szegedi

Re: RFR: 8198540: Dynalink leaks memory when generating type converters [v2]

nce becomes unreachable, all method handles it created also become > eligible for collection. `TypeConverterFactoryRetentionTests` on the other > hand test that the factory itself won't prevent class loaders from being > collected by virtue of creating converters for them. Attila Szege

RFR: 8198540: Dynalink leaks memory when generating type converters

_(NB: For this leak to occur, an application needs to be either creating and discarding linkers frequently, or creating and discarding class loaders frequently while creating Dynalink type converters for classes in them. Neither is typical usage, although they can occur in dynamic code loading

Re: Review request for JDK-8252124: Restore Dynalink tests

ate copyright year on tests - > especially because there have been changes like package removal (flat). > > -Sundar > > >> On 2020. Aug 20., at 22:20, Attila Szegedi wrote: >> >> Hi folks, >> >> long time since I actively popped up here

Re: Review request for JDK-8251538: Modernize and lint Dynalink code

On 2020. Aug 20., at 23:43, Remi Forax wrote: > > - Mail original - >> De: "Attila Szegedi" >> À: "core-libs-dev" >> Envoyé: Jeudi 20 Août 2020 22:40:53 >> Objet: Review request for JDK-8251538: Modernize and lint Dynalink code

Review request for JDK-8251538: Modernize and lint Dynalink code

Following up on the previous e-mail, here’s the modernization and linting work on the existing Dynalink codebase: Please review JDK-8251538 "Modernize and lint Dynalink code" at for

Review request for JDK-8252124: Restore Dynalink tests

Hi folks, long time since I actively popped up here. I’m taking some time to maintain Dynalink, eyeing Java 16 for the changes. Since the nashorn-dev list is (presumably? I haven’t bother checking) defunct, I asked around and Sundar suggested core-libs-dev is the right list to post review

Comparator.reversed() type inference issue

Hi folks, I'm teaching Java lately, and while teaching streams I use that good old chestnut, the word count example. I'm baffled with some type inference woes, though… trying to specify a reverse comparator using Comparator.reversed() makes javac sad, e.g. this does not compile[1]: Map

Re: java.util.Pair

In application code I agree that semantics-free tuples are a code smell, but if you're developing a library of generally usable algorithms a need for a type that is a product of two types can naturally arise, without further semantics provided (or required) by the context. In a sense the

Re: RFR: 8166365: Small immutable collections should provide optimized implementations when possible

Collections.java: 4987 @Override 4988 public int hashCode() { 4989 return (k == null ? 0 : k.hashCode()) ^ 4990(v == null ? 0 : v.hashCode()); Why not use Objects.hashCode here too, that is return Objects.hashCode(k) ^ Objects.hashCode(v) ?

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Not at all, you could just have a call to cancel() block until the future completes. *ducks* Attila. > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > If that truely is the case then the only way of implementing a readonly > Future is by throwing an exception from

Re: MethodHandle for array length

Hi Uwe, If you’re targetting JDK 9 only, you could also consider basing your language’s dynamic operations on Dynalink; it’s integrated into JDK 9 and is specifically meant as a way to ease implementation of languages that have dynamic types. It happens to have a predefined GET_LENGTH[1]

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

On Thu, Apr 28, 2016 at 3:52 PM, Aleksey Shipilev < aleksey.shipi...@oracle.com> wrote: > *) next(): Missing braces in throw new NSEE() block; > *) next(): Why loading this.a into local? I agree with Aleksey but I'd go as far as to say that not only this.a is unnecessary, but i as well. The

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

I can think of several differences. For one, you can’t presume the availability of a filesystem (Java doesn’t require that the host system give it access to a filesystem), nor the ability of the filesystem to expose all desired kinds of memory as files. Next, every such solution is OS specific

Re: Code Review Request, 8152237 Support BigInteger.TWO

Sorry for beating the dead horse of ObjectIdentifier.java change, but I’d suggest that if that code is later revisited, it be changed to "first.compareTo(BigInteger.TWO) > 0" instead of “… == 1”. Comparing the return value of compareTo to zero (instead of relying on specific set of return

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

> On Nov 23, 2015, at 4:40 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build >> related) changes: >> jdk9

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

d enough to verify that JDK9 builds fine with these changes. Thanks, Attila. > On Nov 20, 2015, at 4:41 PM, Attila Szegedi <szege...@gmail.com> wrote: > > Thanks for pointing out these, Mandy; I will make the changes you suggested. > > Attila. > >> On Nov 20, 2015, at 6:1

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

e moved too. They are not sole service >> providers. Since you are on this file, can you move jdk.scripting.nashorn >> to MAIN_MODULES as well? >> >> Mandy >> >>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi <szege...@gmail.com> wrote: >&

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On Nov 20, 2015, at 4:10 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 19/11/2015 23:15, Attila Szegedi wrote: >> Please review JDK-8141338 "Move jdk.internal.dynalink package to >> jdk.dynalink" for <https://bugs.openjdk.java.net/brows

Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

Folks, here’s some updates on this JEP, mostly making the code and docs available to the community for evaluation. Where’s the code? = The JDK 9 sandbox repo now has a branch named “JEP-276-branch” where the work is ongoing. If you aren’t familiar with the JDK 9 sandbox, you

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

> On Oct 20, 2015, at 10:17 AM, Jochen Theodorou <blackd...@gmx.org> wrote: > > On 19.10.2015 12:56, Attila Szegedi wrote: >> On Oct 19, 2015, at 10:46 AM, Jochen Theodorou <blackd...@gmx.org >> <mailto:blackd...@gmx.org>> wrote: >> >>>

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

On Oct 19, 2015, at 10:46 AM, Jochen Theodorou wrote: > since it is dynalink there is I guess only one master linker in the end. Can > you point me to some code showing how the composition of linkers is done to > refresh my memory on that? Sure, here’s how Nashorn does it:

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

Sure. For what’s it worth, this is for all practical purposes Dynalink, in the form I’ve been developing for years as a standalone library on GitHub and presenting about it at JVM Language Summits over several years, so I’d expect a significant amount of awareness is there. The primary

Re: JEP 276: Dynamic Linking of Language-Defined Object Models

> On Oct 18, 2015, at 10:49 AM, Jochen Theodorou wrote: > > On 17.10.2015 13:30, Martijn Verburg wrote: >> This looks very, very promising. Would it help to get the language >> maintainers of the most popular scripting/dynamic JVM languages involved >> ASAP? Happy to

Re: RFR: 8098547: (tz) Support tzdata2015e

FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -95400 1969-12-20T23:00:00.000Z'

Re: RFR: 8098547: (tz) Support tzdata2015e

tzdata changes haven't been pushed to jdk9-dev forest yet. Where the 1969 date coming from ? Is there some rollover calculation happening ? Regards, Sean. On 25/06/2015 09:05, Attila Szegedi wrote: FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm

Re: RFR: 8098547: (tz) Support tzdata2015e

it's a regression caused by the fix to 8008577, where the default locale data switched to Unicode Consortium's CLDR. Would you please file an issue? Naoto On 6/25/15 5:49 AM, Attila Szegedi wrote: Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10

Re: RFR 8068978: All versions of javax.script.ScriptEngine.eval(...) method may clarify ScriptException throwing

+1 On May 25, 2015, at 2:54 PM, A. Sundararajan sundararajan.athijegannat...@oracle.com wrote: Please review http://cr.openjdk.java.net/~sundar/8068978/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8068978 Thanks, -Sundar

AbstractList etc. functionality as interfaces with default methods?

So I’m in a position where I’d need to have a class implement List, but it already extends something else, so I can’t have it extend AbstractList, which leaves me with a lot of boilerplate methods to implement. Would it seem like a good idea to reimagine AbstractList and friends as interfaces

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

Well then those would obviously be left out, documenting that it’s the responsibility of the implementor to provide them. This would be true in general for other interfaces as well that have a specification for expected meaning of equals/hashCode. There’s still a lot of boilerplate code that

Re: Add Predicate.of(), Consumer.of(), etc.

On May 6, 2015, at 12:37 PM, Paul Sandoz paul.san...@oracle.com wrote: On May 2, 2015, at 11:31 PM, Remi Forax fo...@univ-mlv.fr wrote: Hi all, today, I stubble on a variant of JDK-8050818 [1], trying to call negate() on a lambda which is not yet a Predicate (due to target typing)

Re: [9] RFR (XS): 8060483: NPE with explicitCastArguments unboxing null

Thanks for fixing this. Can we expect a backport to 8u-dev soon? On Oct 15, 2014, at 4:46 PM, Attila Szegedi szege...@gmail.com wrote: +1 On Wed, Oct 15, 2014 at 2:12 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8060483/webrev.00/ https

Re: [9] RFR (XS): 8060483: NPE with explicitCastArguments unboxing null

+1 On Wed, Oct 15, 2014 at 2:12 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8060483/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8060483 Recent changes broke MHs.explicitCastArguments for null values when unboxing taking place. The