Re: Getting a live view of environment variables (Gradle and JDK 9)

Hi Jonathan, Bazel is a cathedral when Gradle is a bazaar, Bazel uses a controlled subset of Python as build language, and a strictly defined API that do not let you extend Bazel in an arbitrary way. Those two approaches, a strict DSL or a general purpose languages retargeted to be used as a

Re: Accessing UNIX FileDescriptor id without reflection

er Peter is right, i'm wrong :) > > Roger Rémi > > > On 5/8/2017 10:14 AM, Remi Forax wrote: >> I agree that a method getFd should be great, we will need this kind of value >> if >> we want to use Panama. >> >> Did you try to serial

Re: Accessing UNIX FileDescriptor id without reflection

I agree that a method getFd should be great, we will need this kind of value if we want to use Panama. Did you try to serializing the FileDescriptor in memory and extract the int corresponding to the file descriptor ? cheers, Rémi - Mail original - > De: "Enrico Olivelli"

Re: Accessing module internals from bytecode rewriting agent

Hi Kirk, --patch-module both at compile time and at runtime is what your are looking for. cheers, Rémi - Mail original - > De: "Kirk Pepperdine" > À: "Alan Bateman" > Cc: "jigsaw-dev" ,

Re: Accessing module internals from bytecode rewriting agent

[...] > > Meanwhile, Mandy Chung has kindly offered to look into the security > considerations that are at play and come up with a less restrictive > policy which enforces the security needs more accurately. At that point > I will probably remove the fallback -- in part because I hope that by >

Re: RFR 9: JDK-8178012: Finish removal of -Xmodule:

Yes, please hide -Xmodule, currently people get confused by -Xmodule vs --patch-module, i had several questions related to that at DevoxxFR. Rémi - Mail original - > De: "Jan Lahoda" > À: "compiler-dev" , "Java Core Libs" >

Re: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers

/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java#l556 [2] http://parrt.cs.usfca.edu/doc/impl-parsers-in-java.pdf - Mail original - > De: "Claes Redestad" <claes.redes...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>,

Re: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers

Currently playing with a pattern matching representation for Amber, if think we need a form of array constant that does not require a bootstrap method. Afaik, an array of any existing constants does not need a Java code to construct itself. Rémi On April 10, 2017 6:18:07 PM GMT+02:00, Paul

Re: Java 9 and IntSummaryStatistics et al.

Seems a nice Math exercise. if you have the min, the max, the count and the sum, how to re-create an IntSummaryStatistics knowing you can only uses accept ? What about calling accept() with the min, the max and (count - 2) times the (sum - min - max) / (count - 2) ? Obviously, if the remainder

Re: RFR 8175013: Add @Generated Annotation

And deprecate the old. Maybe it will be done as a part of another commit given javax.annotation.Generated is in another workspace. so i've added compiler-dev, since this will be commited to langtools. Rémi - Mail original - > De: "Alan Bateman" > À: "Lance

Re: Is @deprecated javadoc comment still useful?

Mail original - > De: "Weijun Wang" > À: "Stuart Marks" > Cc: "Java Core Libs" > Envoyé: Mercredi 8 Mars 2017 01:15:10 > Objet: Is @deprecated javadoc comment still useful? > Hi, Mr Deprecator I'm not Dr

Re: Proposal: java.lang.reflect.Proxy and default methods

Alan, i think we should update the doc section of j.l.r.Proxy to add a sentence about default methods ? Rémi - Mail original - > De: "Alan Bateman" > À: "mp911de" , core-libs-dev@openjdk.java.net > Envoyé: Jeudi 2 Mars 2017 09:28:35 > Objet:

Re: Forcing initialization of string concat INDY expressions

The worst thing here is that conceptually, for an invokedynamic, the implementation do not use the fact that MethodTypes are interned. Only a direct call to a method handle (with invokeExact/invoke) needs MethodTypes to be interned to speedup the test that verifies that the parameter types are

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)

Hi Brent, in LiveStackFrame, PrimitiveSlot.size() should be public. The other solution is to see PrimitiveValue as a technical factorisation of code, not something users should know, so it should be a public class but a package-private abstract class and PrimitiveSlot32/PrimitiveSlot64 should be

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

> De: "Luke Hutchison" <luke.hu...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "David Holmes" <david.hol...@oracle.com>, core-libs-dev@openjdk.java.net > Envoyé: Mardi 24 Janvier 2017 09:13:17 > Objet: Re: Calling a lambda

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

- Mail original - > De: "Luke Hutchison" > À: "David Holmes" > Cc: core-libs-dev@openjdk.java.net > Envoyé: Mardi 24 Janvier 2017 08:21:39 > Objet: Re: Calling a lambda expression from a new thread before the main > method is run

Re: Stream based API for tree like structures

https://gist.github.com/forax/bca6877e019d134f87c4cb1e8efae9cd Rémi - Mail original - > De: "Kasper Nielsen" <kaspe...@gmail.com> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Vendredi 20 Janvier 2017 11:03:41 > Objet: Str

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

Note that the bimorphic rule is per callsite, it's fine to have several implementations if for a specific method call there are only two possibles implementations. cheers, Rémi - Mail original - > De: "Stuart Marks" > À: "Louis Wasserman"

ASM6 going native

Hi all, i've played a little with jaotc [1] and i can confirm it works well with ASM :) If the library code is stripped, ASM6 full is 13 megs in tiered mode and 10 megs in non tiered mode. --module doesn't seems to work with non-system module but it seems it already has been already reported.

Re: Need info regarding Java Source Code

Hi Prakhar, Java is the name of the spec but if you look for the source of the OpenJDK, everything is here http://hg.openjdk.java.net/ How to download the source http://openjdk.java.net/install/index.html Remi On December 26, 2016 1:23:53 PM GMT+01:00, Prakhar Makhija

Re: Alternatives for Unsafe field access

- Mail original - > De: "Nathan Mittler" > À: "Uwe Schindler" > Cc: "Daniel Weis" , core-libs-dev@openjdk.java.net, "Louis > Ryan" > Envoyé: Jeudi 8 Décembre 2016 23:16:36 > Objet: Re: Alternatives for

Re: JShell doesn't provide a ToolProvider

- Mail original - > De: "Robert Field" > À: fo...@univ-mlv.fr, "Alan Bateman" > Cc: "core-libs-dev" > Envoyé: Jeudi 17 Novembre 2016 02:57:55 > Objet: Re: JShell doesn't provide a ToolProvider > On

Re: RFR: jsr166 jdk9 integration wave 12

Martin, for ArrayDeque, when you start to have methods like @SuppressWarnings("unchecked") static final E elementAt(Object[] es, int i) { return (E) es[i]; } I think it's a better idea to type the field elements as a E[] instead of Object[]. Historically, using Object(] instead

Re: RFR: jsr166 jdk9 integration wave 12

- Mail original - > De: "Martin Buchholz" > À: "Paul Sandoz" > Cc: "core-libs-dev" > Envoyé: Vendredi 18 Novembre 2016 05:29:12 > Objet: Re: RFR: jsr166 jdk9 integration wave 12 [..] >> 317

Re: JShell doesn't provide a ToolProvider

inside the package jdk.internal.shell.tool, it can start JShellTool with exacly the same arguments as the main() does. Rémi - Mail original - > De: "Alan Bateman" <alan.bate...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev&qu

Re: JShell doesn't provide a ToolProvider

- Mail original - > De: "Patrick Reinhart" <patr...@reini.net> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Mercredi 16 Novembre 2016 11:29:55 > Objet: Re: JShel

JShell doesn't provide a ToolProvider

Hi all, hi Robert, currently, unlike javac or javadoc, there is no way to directly invoke jshell (JShellTool) because it lies in an internal package (which is a good idea). I think the module jdk.jshell should provide a java.util.spi.ToolProvider so i can embed jshell, like i can embed any

Re: Java is too limited when dealing with the Console

Hi Brunoais, Java is not and will never be only what comes with the OpenJDK, it's a big (really big) community full of libraries for whatever you wish and even sometimes what you don't wish. So beside readline, you can also take a look at Jansi https://github.com/fusesource/jansi it's the

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

that this method exist. regards, Rémi - Mail original - > De: "Mandy Chung" <mandy.ch...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "David M. Lloyd" <david.ll...@redhat.com>, "core-libs-dev" > <core-libs-dev

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

Hi David, you can not override a static method :) but there is still a corner case, you can have a conflict when you have a method reference over an instance method and you introduce a static method that have the same functional signature. Given that i prefer to have a compile time error than a

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

- Mail original - > De: "Paul Sandoz" > Cc: "Core-Libs-Dev" > Envoyé: Mercredi 9 Novembre 2016 17:47:34 > Objet: Re: 8169425: Values computed by a ClassValue should not strongly > reference the ClassValue > Hi Peter, > >

Re: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue

We should really lock Doug Lea and a GC guy in a room and only release them when they have produce a java.util.EphemeronHashMap (or maybe something which doesn't implement the whole Map contract but only put and get), using a WeakHashMap with the value strongly referencing the key is way too

Re: RFR 8164934: Optional.map() javadoc code example is incorrect

Looks good. At some point we should provide a way to de-activate checked exception in Java ! I vote for 10. I know it's a bold move but seriously checked exception are fine as feature until you try to compose it with another feature. This is a perfect example of why checked exceptions are a bad

Re: RFR 8132097: Stream.generate should use a covariant Supplier as parameter

Good for me ! Remi On November 9, 2016 1:43:52 AM GMT+01:00, Paul Sandoz wrote: >Hi > >Please review this compatible fix to Stream.generate to accept a >covariant Supplier. > >Paul. > >diff -r 3e3ca9800322 >src/java.base/share/classes/java/util/stream/Stream.java >---

Re: RFR(s): 8156079: make empty instances singletons

Looks good, the static methods in ImmutableCollections do not need to be final there are already static. Rémi On November 4, 2016 3:08:58 AM GMT+01:00, Stuart Marks wrote: >Hi all, > >Please review this small set of changes to the immutable collections to >make the

Re: RFR(s): 8152617 add missing wildcards to Optional or() andflatMap()

Hi Timo, - Mail original - > De: "timo kinnunen" > À: "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mercredi 12 Octobre 2016 09:33:54 > Objet: RE: RFR(s): 8152617 add missing wildcards to Optional or()

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

- Mail original - > De: "Stuart Marks" > À: "Paul Sandoz" > Cc: "core-libs-dev" > Envoyé: Vendredi 7 Octobre 2016 21:22:09 > Objet: Re: RFR(s): 8152617 add missing wildcards to Optional or() and >

Re: Deprecate all java.util.concurrent.*FieldUpdater

ubiquitous for 10 years? The right answer is the one from Andrew but i can not resisrt, here is my answer: when you hope that it will not take 10 years to be ubiquitous. regards, Remi > >On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > >> Given that Java

Re: RFR: 8159855

It seems to be a little to JDK centric to me. Rémi - Mail original - > De: "Alan Bateman" <alan.bate...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "Jonathan Gibbons" > <jonathan.gibb...@oracle.com> > Cc: compile

Re: RFR: 8159855

Very nice, it will greatly help gradle, maven, etc. in com/sun/tools/javac/main/Main.java, the other constructor should delegate its initialization to the constructor you just add, public Main(String name, PrintWriter out) { this(name, out, out); } I wonder if findFirst() in

Deprecate all java.util.concurrent.*FieldUpdater

Given that Java 9 introduces a faster way to emit things like compareAndSet by using the VarHandke API and that AtomiReference (and likes) are now rewritten to use VarHandles directly, i think it's time to deprecate all *FieldUpdater with something saying that they have been superseded by the

Re: Proposal to introduce method "Instrumentation.getInstance()" to instrument the current VM

On September 29, 2016 9:06:12 PM GMT+02:00, Alan Bateman wrote: >On 29/09/2016 18:50, Rafael Winterhalter wrote: > >> : >> >> Therefore I want to propose adding a static method to the >Instrumentation >> interface: >> >> interface Instrumentation { >>static

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

yes, thumb up. Rémi On September 28, 2016 1:51:18 PM GMT+02:00, Michael Haupt wrote: >Hi Claes, > >yes please. Thumbs up. :-) > >Best, > >Michael > >> Am 28.09.2016 um 13:48 schrieb Claes Redestad >: >> >> Hi, >> >> as discussed recently

Re: Collection Design FAQ

On September 23, 2016 8:13:36 AM GMT+02:00, Kasper Nielsen wrote: >Hi, > >I accidently bumped into an old friend today >https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html >There are couple of questions that might need an update after Java 8.

MethodHandle loop body parameters and Stream.reduce accumulator parameters are not in the same order

Hi everybody, i've just found that the parameters of the body (a MethodHandle) of MethodHandles.countedLoop (both overloads) and iteratedLoop are not in the same order as the accumulator in methods Stream.reduce, given that they conceptually represent the same thing, i think the first two

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Hi Krys, why do you need a public API to send the profile to the JIT compiler ? Rémi - Mail original - > De: "Krystal Mok" > À: "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mercredi 14 Septembre 2016

Re: Make iterators cloneable?

Hi, digging a little bit in the bug database, there is a bug from 1999 https://bugs.openjdk.java.net/browse/JDK-4244952 answers seems to be - having different iterators on the same collection is error prone because iterators are failfast, the proposed workaround to use an array or a List

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Yes, i like this patch :) Aleksey, It's worst than what you think because for a lot of people Compiler == java compiler and not JIT compiler so they try to compile a .java file with the method compileClasses(String). I'm glad this class will disappear soon. Rémi - Mail original - >

Re: A bit of sugar for j.u.c.locks with try-with-resources?

> De: "Dr Heinz M. Kabutz" <he...@javaspecialists.eu> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Ivan Gerasimov" <ivan.gerasi...@oracle.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Samedi

Re: A bit of sugar for j.u.c.locks with try-with-resources?

- Mail original - > De: "Ivan Gerasimov" > À: "Krystal Mok" , "core-libs-dev" > > Envoyé: Samedi 3 Septembre 2016 12:23:28 > Objet: Re: A bit of sugar for j.u.c.locks with try-with-resources? > Hi

Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

- Mail original - > De: "harold seigel" <harold.sei...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Alan Bateman" <alan.bate...@oracle.com>, "Hotspot dev runtime" > <hotspot-runtime-...@openjdk.java.net&

Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

Harold, disallowing array classes as host classes seems unrelated and knowing that jdk 10 or 11 will certainly add default methods to arrays, we will want to have anonymous classes with arrays as host class in order to acts as bridges/mixins. regards, Rémi - Mail original - > De:

Re: RFR: 8164525: Re-examine zero form link time pre-generation

Hi Claes, it seems you have not generated the webrev from the right patch set, what the purpose of debugCompilation in LambdaForm ? cheers, Rémi - Mail original - > De: "Claes Redestad" > À: "core-libs-dev Libs" > Envoyé:

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

String method, but > >> (perhaps!) not the dangerous methods. > >> > > Right, and even synchronise on it :-) since they are methods on Object. > > Access control will block reflective invocation on the Unsafe methods for > > unqualified exports. > > >

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Hi Paul, - Mail original - > De: "Paul Sandoz" > À: "Core-Libs-Dev" > Envoyé: Lundi 18 Juillet 2016 18:06:44 > Objet: 8161129 Unsafe::getUnsafe should allow the platform class loader to > access it > > Hi, > > Please review

Re: RFR: JDK-8160829 - Remove ASMPool support from jlink

Hi jim, This code had a dependency of the private copy of ASM, so +1 to remove it. Rémi - Mail original - > De: "Jim Laskey (Oracle)" > À: "jigsaw-dev" , "core-libs-dev" > > Envoyé: Mardi 5 Juillet

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

gt; > Envoyé: Lundi 27 Juin 2016 16:41:02 > Objet: Re: RFR: 816: Runtime.version() cause startup regressions in 9+119 > > > > On 27 Jun 2016, at 16:36, Remi Forax <fo...@univ-mlv.fr> wrote: > > > > Hi Claes, > > > > Change loo

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

Hi Claes, Change looks good to me :) just a minor nit Optional buildNumber = build.isPresent() ? Optional.of(Integer.valueOf(build.get())) : Optional.empty(); can be re-written Optional buildNumber = build.map(Integer::parseInt); BTW, i don't know why you're using

Re: A new helper method Arrays.asArray

o...@univ-mlv.fr > Sent: Wednesday, June 15, 2016 00:38 > To: timo kinnunen > Cc: core-libs-dev ; Louis Wasserman > Subject: Re: A new helper method Arrays.asArray > > De: "timo kinnunen" <timo.kinnu...@gmail.com> > > > À: "Remi Forax" <

Re: A new helper method Arrays.asArray

- Mail original - > De: "timo kinnunen" <timo.kinnu...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "Louis Wasserman" > <lowas...@google.com> > Envo

Re: A new helper method Arrays.asArray

Hi Timo, your implementation can not use @SafeVarargs because you leak the array (you return it) so you're code is not safe because you can not be sure that the resulting array will not be modified after the call to asArray. Louis, because you can not create an array of parametrized type in

Re: Math.round optimization, and round to int

or use r = r * (longBits < 0)? -1: 1; which should be compiled to a conditional move. cheers, Rémi - Mail original - > De: "Jeff Hain" > À: core-libs-dev@openjdk.java.net > Envoyé: Dimanche 5 Juin 2016 20:17:49 > Objet: Math.round optimization, and round to

Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi Iris, is there a way to avoid to use regex when parsing the version ? java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Also instead of MethodVisitor mv = cw.visitMethod(ACC_PRIVATE | ACC_STATIC, "invoke_V", "(Ljava/lang/invoke/MethodHandle;[Ljava/lang/Object;)Ljava/lang/Object;", null, new String[] { "java/lang/Throwable" }); because the code is never read by

Re: MethodHandle for array length

Hi Uwe, I was planning to add a bug for this feature but it seems that Michael was faster than me, https://bugs.openjdk.java.net/browse/JDK-8156915 regards, Rémi - Mail original - > De: "Uwe Schindler" > À: "Michael Haupt" ,

Re: MethodHandle for array length

- Mail original - > De: "Uwe Schindler" > À: "Core-Libs-Dev" > Envoyé: Mercredi 11 Mai 2016 21:35:32 > Objet: MethodHandle for array length > > Hi, > Hi Uwe, > while working and trying the new JDK9 MethodHandles features like >

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

iginal - >>> De: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com> >>> À: "Remi Forax" <fo...@univ-mlv.fr>, "shilpi rastogi" ><shilpi.rast...@oracle.com> >>> Cc: core-libs-dev@openjdk.java.net, "John Rose" >&l

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

- Mail original - > De: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "shilpi rastogi" > <shilpi.rast...@oracle.com> > Cc: core-libs-dev@openjdk.java.net, "John Rose" <john.r

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

nvoke", Nashorn or JRuby do that too. I can modify the code to use the new StackWalking API if all the method handle form artifact are marked with an interface or something like this. - generate proxy in an existing package see https://github.com/forax/proxy2 - generate code specializa

Re: RFR(m): 8139233u1 add initial compact immutable collection implementations

ection > implementations > > On 9 May 2016 at 15:25, Remi Forax <fo...@univ-mlv.fr> wrote: > > CollSer implementation can be improved to avoid the ugly switch/case by > > replacing the constant list by an enum, > > CollSer is modelled on JSR-310 code which uses an int. An enum would > be a huge overkill for this use case. > > Stephen >

Re: RFR(m): 8139233u1 add initial compact immutable collection implementations

Hi Stuart, I still think that the code of hasNext of the iterator of SetN and MapN should not do any side effect. otherwise, in the constructor of MapN, you can declare k and v as Object (the table is an array of Object and probe() now takes an Object) also instead of InternalError, i

Re: RFR(m): 8139233 add initial compact immutable collection implementations

- Mail original - > De: "Stuart Marks" <stuart.ma...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Jeudi 5 Mai 2016 08:32:08 > Objet: Re: RFR(m): 8139

Re: RFR(m): 8139233 add initial compact immutable collection implementations

- Mail original - > De: "Peter Levart" > À: "Stephen Colebourne" , "core-libs-dev" > > Envoyé: Mercredi 4 Mai 2016 23:58:13 > Objet: Re: RFR(m): 8139233 add initial compact immutable collection >

Re: RFR(m): 8139233 add initial compact immutable collection implementations

Hi Stuart, nice work ! first, all classes should be final otherwise, they are not truly immutable and all arrays should be marked as @Stable. List0, List1, why not using Collections.emptyList(), Collections.singletonList() here ? ListN: - i don't think that extending AbstractList is a

Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package

t: Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods > to an internal package > > > > On 3 May 2016, at 07:05, Remi Forax <fo...@univ-mlv.fr> wrote: > > > > Looks good to me. > > minor nitpick, neither checkFromToIndex() nor checkFrom

Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package

Looks good to me. minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later. Rémi - Mail

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

Hi all, Just nitpicking, i wonder if it's not better to use the Doug Lea's convention in next() i.e. rename i to cursor to shadow the field cursor public E next() { int cursor = this.cursor; if (cursor >= a.length) { throw new

Re: RFR(m): 8140281 deprecate Optional.get()

>From my experience, devs in general only read the doc when an exception is >thrown so i agree with you. And in the wake of deprecating Optional.get(), I propose to rename RuntimeException to RTFMException :) Remi Le 26 avril 2016 20:05:22 CEST, Peter Levart a écrit

Re: Fwd: RFR(m): 8140281 deprecate Optional.get()

I agree with Jon, Vitaly and Ali, get is good candidate to @Bikeshed not for @Deprecated. Rémi Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi a écrit : >Hi, >I agree with Jon, Vitaly, >I think the name Optional completely describe its intents and semantics >so >I

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

I wanted to reply that if you have a perf sensitive code that uses newInstance you should use a MethodHandle instead to avoid to do the security checks multiple times but i remember that they was an issue with MethodHandle attached to a constructor and i don't know if it was resolved. Rémi

Re: RFR: 8151056: ASM enable original deprecated methods. (simple fix)

Thumb up ! Rémi - Mail original - > De: "Sundararajan Athijegannathan" > À: core-libs-dev@openjdk.java.net > Envoyé: Lundi 18 Avril 2016 06:18:37 > Objet: Re: RFR: 8151056: ASM enable original deprecated methods. (simple fix) > > Looks good > >

Re: RFR(m): 8145468 deprecations for java.lang

Hi Heinz, i think we should go nuclear on this, deprecate the Integer constructor *and* remove the line in the spec that says that Integer.valueOf (and Byte, Short, Character, Long) uses a cache and admit that the Java spec should not have a premature optimization carved in it. About your

Re: RFR(m): 8145468 deprecations for java.lang

- Mail original - > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Rémi Forax" <fo...@univ-mlv.fr> > Cc: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> >

Re: RFR(m): 8145468 deprecations for java.lang

CEST, Brian Goetz <brian.go...@oracle.com> a écrit : >Or, better, don’t do that in ASM, and instead use .equals()? > >> On Apr 14, 2016, at 9:21 AM, Remi Forax <fo...@univ-mlv.fr> wrote: >> >> Hi Stuart, >> you are not the first

Re: RFR(m): 8145468 deprecations for java.lang

Hi Stuart, you are not the first one to try to change the integers defined in org.objectweb.asm.Opcodes, those values are compared by ref (not by value) inside ASM. You're patch will change the behavior of any Interpreters that also use some Integers created by Integer.valueOf() because valueOf

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Hi Mandy, I really don't like this patch. Being forced to call toStackElement to get the line number is counter intuitive. I would prefer the two methods to not return Optional but an int and a String with the same convention as StackElement if the point of this patch is to remove the

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoyé: Mercredi 6 Avril 2016 16:09:14 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > On 6

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Vitaly Davidovich" <vita...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev Libs" > <core-libs-dev@openjdk.java.net>

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

enceFieldUpdater with Unsafe > > > > On 6 Apr 2016, at 12:10, Remi Forax <fo...@univ-mlv.fr> wrote: > > > > - Mail original - > >> De: "Paul Sandoz" <paul.san...@oracle.com> > >> Cc: "core-libs-dev Libs

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Paul Sandoz" > Cc: "core-libs-dev Libs" > Envoyé: Mercredi 6 Avril 2016 09:37:00 > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of > AtomicReferenceFieldUpdater with Unsafe > > > > On 5 Apr

Re: RFR: jsr166 jdk9 integration wave 6

- Mail original - > De: "Martin Buchholz" <marti...@google.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "Doug Lea" > <d...@cs.oswego.edu>, "Paul Sando

Re: RFR: jsr166 jdk9 integration wave 6

Hi Martin, Dequeue doc change is fine, ParkLoops test is fine too, i suppose it's related to the recent change in the code of TimeUnit to test with different units. For the CompletableFuture change, i don't understand the consequence of the patch so i declare myself incompetent on that subject

Re: RFR: jsr166 jdk9 integration wave 6

Hi Martin, for http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ aka introducing a new constructor seems to be a regression to me, the less overloads we have the better i understand the code. Rémi - Mail original - > De: "Martin Buchholz"

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

- Mail original - > De: "Claes Redestad" <claes.redes...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "core-libs-dev Libs" <core-libs-dev@openjdk.java.net> > Envoyé: Dimanche 3 Avril 2016 14:19:52

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Patch looks Ok to me. Rémi - Mail original - > De: "Claes Redestad" <claes.redes...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Peter Levart" <peter.lev...@gmail.com>, "Mandy Chung" > <mandy.ch...@

Re: RFR: 8152641: Plugin to generate BMH$Species classes ahead-of-time

Hi Claes, Did you considere to use return c.asSubclass(BoundMethodHandle.class); instead of return (Class)c; to avoid the @SupressWarnings, like in generateConcreteBMHClass ? cheers, Rémi - Mail original - > De: "Claes Redestad" > À: "Peter Levart"

Re: JDK 9 build 109 -> Lucene's Ant build works again; still missing Hotspot patches

It's not a bug, it's a feature :) com.sun.management.HotSpotDiagnosticMXBean is a com.sun classes, so maybe not available anymore. see https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool Rémi - Mail original - > De: "Uwe Schindler" > À:

Re: JDK 9 build 109 -> Lucene's Ant build works again; still missing Hotspot patches

my bad, i've crawle the file to see if this API was supported or not and it seems my eyes fail me :) Rémi - Mail original - > De: "Mandy Chung" <mandy.ch...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Mandy Chung" &l

Re: RFR: 8152074: Avoid lambda usage in StringConcatFactory initializer

patch is good for me, another problem with an anonymous class, is that it's a new class that need to be loaded, the corresponding metadata in the VM has to be created, this adds an extra cost compared to use GetPropertyAction which is already loaded at that point. Rémi - Mail original

Re: RFR: 8151858: update ASM 5.1 to accept V53.0 classfiles

After this patch, the version of ASM internally used by OpenJDK will accept V53 class files but not understand module-info.class specific file format, so that version of ASM will be able to read module-info.class, but will see it as a class with a bunch of custom attributes and will not be able

<    1   2   3   4   5   6   7   8   9   10   >