Re: RFR: 8213478: Reduce rebinds when applying repeated filters and conversions

On 2018-11-10 01:02, Vladimir Ivanov wrote: Nice work, Claes! Looks good. Thanks, Vladimir! Webrev: http://cr.openjdk.java.net/~redestad/8213478/jdk.00/ Synced up and running some extra testing before push. /Claes

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

On 11/9/18 2:04 PM, Brian Burkhalter wrote: An updated patch is at http://cr.openjdk.java.net/~bpb/6516099/webrev.06/ including a revision of the implementation to align with the words. The tests are not updated yet. I think this looks

Re: RFR: 8213478: Reduce rebinds when applying repeated filters and conversions

Nice work, Claes! Looks good. Best regards, Vladimir Ivanov On 07/11/2018 06:57, Claes Redestad wrote: Hi, by providing a LambdaFormEditor transform which applies the same filter repeatedly on some selected arguments, we can optimize for cases where there are repeated conversions. This

Re: RFR 8185496: Improve performance of system properties initialization in initPhase1

Hi, Roger The changes look good to me (FWIW - I know it was already pushed :). -Brent On 11/8/18 7:41 AM, Roger Riggs wrote: Webrev updated in place:  (Only System.java is modified) http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

On 09/11/2018 14:04, Brian Burkhalter wrote: Attached is a patch on top of your webrev with my attempt at separating normative text and reducing the complexity in the @implSpec. I like the verbiage the way you modified it. An updated patch is at

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This is an update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This refresh renames the packages used to jdk.jpackager and jdk.jpackager.runtime, removes the

Re: RFR: JDK-8213480: update internal ASM version to 7.0

It's not the simplest solution but you can use a classloader or an agent to patch the bytecode of ASM with ASM at runtime :) Rémi - Mail original - > De: "Igor Ignatyev" > À: "Remi Forax" > Cc: "Vicente Romero" , "Alan Bateman" > , "hotspot-dev" > , "core-libs-dev" > > Envoyé:

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Roger, > On Nov 9, 2018, at 11:48 AM, Roger Riggs wrote: > > Thanks for taking the suggestions. Suggestions always welcome! > I think some of the statements should be normative for all implementations and > we're trying too hard to work with a possibly broken skip() implementation. > > I

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Sergey, What do you think of the version updated with Roger’s suggested change to the verbiage? Thanks, Brian > On Nov 9, 2018, at 12:10 PM, Sergey Bylokhov > wrote: > > it may be better to burn "skip()" in the fire of deprecation? and > implement the "newSkip()" which by default will

Re: RFR: JDK-8213480: update internal ASM version to 7.0

Hi Remi, w/ SymbolTable::get being private method _and_ SymbolTable being final class, it doesn't sound like the easiest way ;) w/ that being said, I haven't looked at the latest version of ASM, so there might be ways to get that we need. Thanks, -- Igor > On Nov 9, 2018, at 11:33 AM, Remi

Re: RFR: JDK-8213480: update internal ASM version to 7.0

Hi David, On 11/8/18 11:00 PM, David Holmes wrote: Hi Vicente, On 9/11/2018 2:39 AM, Vicente Romero wrote: Hi David, Igor On 11/7/18 10:03 PM, David Holmes wrote: Hi Vicente, All of the javadoc comment reformatting makes it nearly impossible to see the actual substantive changes :( ASM

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi, All. it may be better to burn "skip()" in the fire of deprecation? and implement the "newSkip()" which by default will call the "read()", and then subclasses will provide its own fast/optimized implementation? Or we still tries to take care about all corner cases for "skip()"? On 08/11/2018

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, Thanks for taking the suggestions. I think some of the statements should be normative for all implementations and we're trying too hard to work with a possibly broken skip() implementation. I would recommend that if skip does not do what is expected, then an IOException is

Re: RFR: JDK-8213480: update internal ASM version to 7.0

Hi Igor, sorry to have not answered to your mail :( I believe that the easiest way to disable the caching of the entries of the constant pool in ASM is to change SymbolTable.get() [1] to always return null. regards, Rémi [1]

Stream Method Proposal: long count(Predicate predicate)

Hello! I see myself having to often call count() as a terminal operation on a Stream immediately after performing a filter operation. How feasible would it be to add an overloaded count() method that accepts a Predicate, which it uses as a filter before returning the count of elements in the

Re: From JDK12 it is not possible to drop 'final' modifier

Il mer 7 nov 2018, 19:10 Alan Bateman ha scritto: > On 07/11/2018 16:42, Enrico Olivelli wrote: > > Hi, > > I am investigating this case about PowerMock, which is not able to > > remove the 'final' modifier from a Field > > https://github.com/powermock/powermock/issues/939 > > > > Is there any

Re: From JDK12 it is not possible to drop 'final' modifier

Il mer 7 nov 2018, 19:57 Andrew Luo ha scritto: > Also, you might want to take a look at JLS 13.4.9 "final Fields and > Constants". Primitive static final constants can be folded at compile > time, so even if you were able to change it at runtime, it wouldn't have > any effect... > Andrew,

RE: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Thanks Andrew, looks great! - Derek > -Original Message- > From: Andrew Dinn > Sent: Thursday, November 08, 2018 11:01 AM > To: White, Derek ; Vladimir Kozlov > ; Alan Bateman > Cc: Jonathan Halliday ; hotspot-compiler- > d...@openjdk.java.net; core-libs-dev@openjdk.java.net >

RE: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Andrew, Given that there is platform-specific code, it would be good to be clear which platforms you are intending to implement as part of this JEP, and which platforms will need others to step in to support. I'm quite happy with your plan, but I'd like to see more JEPs being clear about

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

On 11/9/18 9:01 AM, Andrew Dinn wrote: Hi Vladimir, On 08/11/18 18:07, Vladimir Kozlov wrote: Thank you, Andrew, for sending changes I am fine with intrinsics general wording in JEP. I 'reviewed' JEP. Excellent. Thank you very much. On to the next step . . . I have several questions and

Re: RFR 8185496: Improve performance of system properties initialization in initPhase1

On 11/9/18 7:25 AM, Roger Riggs wrote: Hi Mandy On 11/08/2018 04:55 PM, Mandy Chung wrote: On 11/8/18 7:41 AM, Roger Riggs wrote: Webrev updated in place:  (Only System.java is modified) http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html Just notice this... I

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Vladimir, On 08/11/18 18:07, Vladimir Kozlov wrote: > Thank you, Andrew, for sending changes > > I am fine with intrinsics general wording in JEP. I 'reviewed' JEP. Excellent. Thank you very much. On to the next step . . . > I have several questions and issues with proposed changes in

Re: RFR: JDK-8213480: update internal ASM version to 7.0

Vicente, Alan, back when we 1st bumped into this problem w/ ClassWriterExt (about 1y ago), it was my AI to discuss it w/ Remi. I sent him an email, didn't get a replay, and as it usually goes, had to switch to something else, completely forgot about that and didn't follow up. Thanks, -- Igor

Re: RFR 8185496: Improve performance of system properties initialization in initPhase1

Hi Mandy On 11/08/2018 04:55 PM, Mandy Chung wrote: On 11/8/18 7:41 AM, Roger Riggs wrote: Webrev updated in place:  (Only System.java is modified) http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html Just notice this... I wonder if System.setProperties(null)

Reflection, TYPE_USE annotation on THROWS on inner class constructor, Java 9+

Hi When adding a TYPE_USE annotation with runtime retention to the throws exception clause of a constructor of an inner class, these annotations are not found via Constructor.getAnnotatedExceptionType().getDeclaredAnnotations() on Java 9+, but present when running on Java 8. For static nested

RFR: 8213618 IBM970 charset has missing entry and remove unexpected entries

Hello. Could you review the fix ? Bug:https://bugs.openjdk.java.net/browse/JDK-8213618 Change: http://cr.openjdk.java.net/~itakiguchi/8213618/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd.

Re: RFR: 8148188: Enhance the security libraries to record events of interest

Erik, comments inline.. On 08/11/18 15:12, Erik Gahlin wrote: Hi Sean, I think we could still call the event "jdk.SecurityPropertyModification", but add a @Description that explains that events are only emitted for the JDK due to security concerns. If we at a later stage want to include

Re: Re[2]: The new optimized version of Dual-Pivot Quicksort

Hi Vladimir, Thank you for your attention, you are the Sort Master. Le ven. 9 nov. 2018 à 09:02, Vladimir Yaroslavskiy a écrit : > Hi Laurent, > > The new version is still under review, there were a lot of suggestions and > ideas from Doug Lea. > I needed time to apply and check them. I'm

Re: The new optimized version of Dual-Pivot Quicksort

Hi, One more thing: if you have any advice on my code, datasets, or algorithmic approach, please give me your feedback/comments. Here is the Marlin MergeSort: http://hg.openjdk.java.net/jdk/jdk/file/190b77982361/src/java.desktop/share/classes/sun/java2d/marlin/MergeSort.java Laurent Le ven. 9

Re[2]: The new optimized version of Dual-Pivot Quicksort

Hi Laurent, The new version is still under review, there were a lot of suggestions and ideas from Doug Lea. I needed time to apply and check them. I'm going to send final version in few days. As to new method sort(a[], low, high, indices): do you mean this method in Arrays class? Are you