Re: RFR 8143404: Remove apple script engine code in jdk repository

I'm only removing applescript code. Not all of jdk.deploy.osx code (collection etc). Not sure if jdk.deploy.osx dependencies can be completely removed (yet). Removal of the other stuff has to be another bug. I'll update for other stuff you mentioned. -Sundar On 12/4/2015 9:01 AM, Mandy Chung

Re: RFR 8143404: Remove apple script engine code in jdk repository

> On Dec 3, 2015, at 5:41 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Thanks. Updated: > > http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ > http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ >

Re: RFR 8143404: Remove apple script engine code in jdk repository

Right. Run this on your repo after removing applescript $ jdeps $BUILD_OUTPUTDIR/jdk/modules/jdk.deploy.os You will see the dependency. It’s okay to remain the qualified exports. But you should remove the dependency on java.desktop and java.scripting. >>

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Hi Kim, On 2015-12-02 19:37, Kim Barrett wrote: Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the work involved in keeping the otherwise inaccessible

Re: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232)

It may be discussed already but based on the definition as you just changed, would it make sense to have a way to create such a Set/List/Map based on a existing mutable implementation? We use a the builder pattern a lot to create immutable objects that get serialized later. At the moment we

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On 3 Dec 2015, at 5:24 a.m., Amy Lu wrote: > > (I'm not a reviewer) Thanks for looking at this Amy, all eyes are welcome. > Just a minor question. > > jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and > BASE64Decoder, but is not included in this

Re: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections

On 03/12/15 12:35, Alan Bateman wrote: > On 03/12/2015 11:56, Matthias-Christian Ott wrote: >> : >> >> Suggested fix: >> >> sun.nio.ch.PipeImpl should use anonymous pipe. It seems that supported >> versions of Microsoft Windows can create millions of handles and is not >> limited to the dynamic

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

On 12/3/15 6:43 PM, Chris Hegarty wrote: >Just a minor question. > >jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and BASE64Decoder, but is not included in this fix. >Missed? or justbecause this test will be totally removed soon in a separate bugid? Since this test is

[bug] sun.nio.ch.PipeImpl uses local TCP/IP connections

Expected behaviour: sun.nio.ch.PipeImpl uses anonymous pipes, i.e. CreatePipe and related functions, to create pipes on Microsoft Windows. Actual behaviour: sun.nio.ch.PipeImpl loopback TCP/IP connections to create pipes. Therefore the number of pipes is less or equal to the size of the dynamic

Re: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections

On 03/12/2015 11:56, Matthias-Christian Ott wrote: : Suggested fix: sun.nio.ch.PipeImpl should use anonymous pipe. It seems that supported versions of Microsoft Windows can create millions of handles and is not limited to the dynamic port range. That was the original proposal back in JDK 1.4

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Looks good -Sundar On 12/3/2015 3:35 PM, Michael Haupt wrote: Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 Thanks, Michael

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Hi Kim, Thanks for pushing this through! Looks good. Bengt On 2015-12-02 19:37, Kim Barrett wrote: Please review this change to PhantomReference processing, changing the GC-based notification to automatically clear the referent. This change provides performance benefits by eliminating the

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Looks good! There seem to be quite a bit more that could be fixed to avoid going through the signature string, either here or as follow-ups, e.g.: LambdaForm prep = getPreparedForm(basicTypeSignature()); private static LambdaForm getPreparedForm(String sig) { MethodType mtype

Re: RFE Pre-review: Support for cloning exceptions

Hi Martin, I see this is a controversial topic and I would really not like to delay changes to CompletableFuture because of that. Anyway I feel I should answer to some of your concerns... On 12/02/2015 07:39 PM, Martin Buchholz wrote: On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart

[bug] sun.nio.ch.WindowsSelectorImpl uses Pipe.open

Expected behaviour: sun.nio.ch.WindowsSelectorImpl#wakeup works if sun.nio.ch.WindowsSelectorProvider is not the provider for java.nio.channels.Pipe#open. Actual behaviour: sun.nio.ch.WindowsSelectorImpl#WindowsSelectorImpl uses java.nio.channels.Pipe#open to create a pipe for

RE: RFR: jsr166 jdk9 integration wave 2

Hi, Following the single-threaded try-with-resources semantics very closely might not give the most useful result because there is at least one aspect that’s fundamentally different between these cases. That is, in the case where the “try”-stage (or block) completes normally but the

RFR(XS): 8072844: Use more efficient LambdaForm type representation

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8072844 Webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.00 Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331

Re: RFR: jsr166 jdk9 integration wave 2

Hi Martin, On 12/03/2015 01:51 AM, Martin Buchholz wrote: We're stuck. Peter wants to make Throwables cloneable, I want to reverse the order of throwables and add the past Throwable as a suppressed exception to the exception of a dependent action, and Doug wants the current webrev behavior of

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

All fixed. Thank you Dan. Fred On 02/12/2015 19:22, Daniel D. Daugherty wrote: On 12/1/15 9:21 AM, Frederic Parain wrote: Hi Dan, Thank you for your detailed review. My answers are in-lined below. New webrev: http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ Re-reviewed by

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

On 2015-12-03 15:08, Michael Haupt wrote: Dear all, thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 Excellent! The string signature is now only used in tracing and assertions, which is why caching it is not necessary. Caching

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Dear all, thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 The string signature is now only used in tracing and assertions, which is why caching it is not necessary. Caching the method type might be worthwhile, but this requires

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Looks good -Sundar On 12/3/2015 7:38 PM, Michael Haupt wrote: Dear all, thank you, Claes, Sundar, and Ulf - here's a new webrev: http://cr.openjdk.java.net/~mhaupt/8072844/webrev.01 The string signature is now only used in tracing and assertions, which is why caching it is not necessary.

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Hi Michael, since arity, result and names[] are final values, both - methodType() and basicTypeSignature() - values could be precomputed at instantiation or at least lazily cached. For the first, both values could be computed with the same for loop, for the latter, basicTypeSignature() could

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

Hi Kim, Kudos for finding an observable change in behavior. Although the specification could also be read in a way so that this would not be observable. Originally it states: "Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they

Re: RFR(S): 8143343: add JEP 274 Javadoc tests to JavaDocExamplesTest

Looks good http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037130.html -Sundar

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 2 Dec 2015, at 20:23, Roger Riggs wrote: > Please review the java.lang.ref.Cleaner and tests following the > recommendation to simplify the public > interface to support only phantom cleanup. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Hi again, why not simply? : 1282 MethodType type = mt.changeParameterType(0, MethodHandle.class); In any case, the state of the external mt becomes changed, so better clone mt. Additional suggestion to save the in and out packing with MethodType: 1279 static MemberName

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

> On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: > > I would only rephrase this statement in package-info.java a bit: > > 96 * Soft and weak references are automatically cleared by the collector > 97 * before being added to the queues with which they are

Re: [bug] sun.nio.ch.PipeImpl uses local TCP/IP connections

On Dec 3, 2015, at 4:45 AM, Matthias-Christian Ott wrote: >> So best to create an issue for it and >> bring a patch to nio-dev to discuss. > > Should I forward the bug reports to nio-dev@ then? Bugs should be filed via [1]. Contributions including fixes may then be submitted

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

> On Dec 3, 2015, at 2:43 AM, Chris Hegarty wrote: > >> Just a minor question. >> >> jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder and >> BASE64Decoder, but is not included in this fix. >> Missed? or justbecause this test will be totally

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Chris, Thanks for the review and comments: The webrev and javadoc have been updated. On 12/03/2015 08:55 AM, Chris Hegarty wrote: On 2 Dec 2015, at 20:23, Roger Riggs wrote: Please review the java.lang.ref.Cleaner and tests following the recommendation to

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

+1 on the change as a whole. Editorially, I agree that paragraph in the package-info obscures the point its trying to make. Your suggestion is clearer. Roger On 12/03/2015 08:01 AM, Peter Levart wrote: Hi Kim, Kudos for finding an observable change in behavior. Although the

RFR 8143404: Remove apple script engine code in jdk repository

Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8143404 Webrev: http://cr.openjdk.java.net/~sundar/8143404/webrev.00/ Apple script engine implementing javax.script engine API is being removed. AppleScript engine has flip flopped between working and broken many times.The services

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, I now think that this is the right move. The simplified API is really only useful for PhantomReference(s). Since Cleaner.Cleanable interface does not provide access to the referent, it would be tempting for users to do two things at once for the same referent with Weak or Soft

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Hi Ulf, the change (as of webrev.01) is pushed. Nevertheless, thanks for your comments - responses below. > Am 03.12.2015 um 15:40 schrieb Ulf : > why not simply? : > 1282 MethodType type = mt.changeParameterType(0, MethodHandle.class); > > In any case, the state

Re: RFR(XS): 8072844: Use more efficient LambdaForm type representation

Hi Michael, Am 03.12.2015 um 16:21 schrieb Michael Haupt: Cloning mt here is not necessary, as changeParameterType() will create a new MT instance. If that's what you mean. A MethodType is an apt abstraction for what is needed here; I don't think breaking it up into its components would help

Re: RFR 8143404: Remove apple script engine code in jdk repository

On 03/12/2015 15:06, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8143404 Webrev: http://cr.openjdk.java.net/~sundar/8143404/webrev.00/ Apple script engine implementing javax.script engine API is being removed. AppleScript engine has flip

Re: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

Thanks Lance! Joe On 12/3/2015 11:16 AM, Lance Andersen wrote: Hi Joe, Looks OK… Best Lance On Dec 3, 2015, at 2:06 PM, huizhe wang > wrote: Hi, This is a clean-up of the code in jaxp that had depended on Java version string. This

Re: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

> On Dec 3, 2015, at 11:06 AM, huizhe wang wrote: > > Hi, > > This is a clean-up of the code in jaxp that had depended on Java version > string. This code came from JAXP standalone that no longer exists. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 >

RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

Hi, This is a clean-up of the code in jaxp that had depended on Java version string. This code came from JAXP standalone that no longer exists. jbs: https://bugs.openjdk.java.net/browse/JDK-8132091 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8132091/webrev/ Thanks, Joe

Re: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

Hi Joe, Looks OK… Best Lance On Dec 3, 2015, at 2:06 PM, huizhe wang wrote: > Hi, > > This is a clean-up of the code in jaxp that had depended on Java version > string. This code came from JAXP standalone that no longer exists. > > jbs:

Re: Reference.reachabilityFence

> On Nov 26, 2015, at 8:22 AM, Paul Sandoz wrote: > > Hi, > > I have updated the patches: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fence-jdk/webrev/ > >

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: > > On 12/03/2015 06:01 PM, Mandy Chung wrote: >>> On Dec 3, 2015, at 5:01 AM, Peter Levart >>> wrote: >>> >>> I would only rephrase this statement in package-info.java a bit: >>> >>> 96 * Soft

Re: RFR:8143413:add toEpochSecond methods for efficient access

Hi Sherman, It makes sense to me to provide the missing time/date as an explicit parameter for toEpochSeconds instead of assuming some constant. localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC); localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC);

Re: RFR:8143413:add toEpochSecond methods for efficient access

In the interests of harmony and getting something in, I'll accept that. I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY Stephen On 3 December 2015 at 22:09, Roger Riggs wrote: > Hi Sherman, > > It makes sense to me to provide the missing time/date

Re: [bug] sun.nio.ch.PipeImpl uses IPv4

I think this is somewhat intentional: potential broken localhost resolve or resolve of 127.0.0.1 vs. ::1 are just a bunch of causes for problems (and delays) which are all avoided by hardcoding the address family and address. However it causes now problems when systems are migrating to v6only.

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On Dec 3, 2015, at 8:01 AM, Peter Levart wrote: > > Hi Kim, > > Kudos for finding an observable change in behavior. Although the > specification could also be read in a way so that this would not be > observable. Originally it states: > > "Unlike soft and weak

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On 12/ 3/15 02:33 PM, Kim Barrett wrote: On Dec 3, 2015, at 1:14 PM, Peter Levart wrote: On 12/03/2015 06:01 PM, Mandy Chung wrote: On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: I would only rephrase this statement in package-info.java

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

> On Dec 3, 2015, at 2:33 PM, Kim Barrett wrote: > > I prefer the explicit list in the opening sentence, rather than > collapsing that to just "References", to avoid any possible confusion > that this might apply to (the internal and undocumented, but visible > in the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 3, 2015, at 4:19 PM, Roger Riggs wrote: > >> src/java.base/share/classes/jdk/internal/misc/CleanerImpl.java >> 199 PhantomCleanable(CleanerImpl cleanerImpl) { >> 200 super(null, null); >> >> This feels mildly icky, passing a null referent to

Re: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

On 12/3/2015 12:55 PM, Iris Clark wrote: Hi, Joe. This looks great. Thanks. Thanks for removing this Java version-dependent code. Yes, together with your previous change to those jaxp tests, we are clear of all dependency on java.version from jaxp related code. Regards, Joe Regards,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Kim, Thanks for the comments: I updated the webrev[2] and javadoc[1] with the editorial improvements. On 12/02/2015 06:20 PM, Kim Barrett wrote: On Dec 2, 2015, at 3:23 PM, Roger Riggs wrote: Please review the java.lang.ref.Cleaner and tests following the

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

2015/11/25 3:42 -0800, a...@redhat.com: > On 11/24/2015 05:47 PM, Roger Riggs wrote: >> Memory is an increasingly critical resource, we should be giving >> developers more tools to manage their use of memory. The Weak and >> Soft reference forms of the cleaner make it easier to be aware of >> and

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Looks good -- thanks for the further simplification. Minor editorial comments, to add what Kim and Chris noted: - In many places you write, e.g., "Cleaner" rather than "{@code Cleaner}". For consistency with the rest of the package it'd be better in most cases just to write "cleaner"

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On Dec 3, 2015, at 1:35 PM, mark.reinh...@oracle.com wrote: > >> I'm very tempted to take a bite at this, but the above text is rather >> forbidding. I think I know how to do it. (Famous last words?) > > As the author of the above-quoted paragraph, I wish you luck. It's > a tough problem. > >

RE: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on Java version string

Hi, Joe. This looks great. Thanks for removing this Java version-dependent code. Regards, iris -Original Message- From: huizhe wang Sent: Thursday, December 03, 2015 11:07 AM To: core-libs-dev@openjdk.java.net Subject: RFR (JAXP): 8132091: Clean up JAXP code that has dependency on

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi Nadeesh, Thanks for the update, sorry I missed some editorial comments last time. toSeconds method missing a final period '.' "* This returns the total number of seconds in the duration" toMinutesPart method: Extra text: + * @return the number of minutes parts in the duration, may be

[8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518

Hi, Please, help to review and approve JDK-8133924 backport to JDK8. The source fix is identical to JDK9 changes, but there was no test added for this issue in JDK9. The existing jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test was modified to test the reported problem

[9] RFR of 8143394: PushbackReader throws NullPointerException

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8143394 Patch: http://cr.openjdk.java.net/~bpb/8143394/webrev.00/ The NPE apparently occurred in PushbackReader because a call to close() was made after the conditional at line 72 was evaluated to ‘false’ but

Re: RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232)

/reviews/jep269/api.20151203/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/ Thanks, s'marks On 12/1/15 6:35 PM, Stuart Marks wrote: Hi all, Thanks

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

On 3 Dec 2015, at 15:58, Roger Riggs wrote: > Hi Chris, > > Thanks for the review and comments: > > The webrev and javadoc have been updated. > > On 12/03/2015 08:55 AM, Chris Hegarty wrote: >> On 2 Dec 2015, at 20:23, Roger Riggs wrote: >>

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi all, Please see the updated webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.03/ - changes - Modified the dataprovider as suggested by Roger Thanks and regards, Nadeesh On 12/1/2015 2:39 AM, Stephen Colebourne wrote: This is all about fixing a messy API that was created in

Re: RFR 8143404: Remove apple script engine code in jdk repository

Hi, Thanks. Updated: http://cr.openjdk.java.net/~sundar/8143404/jdk/webrev.00/ http://cr.openjdk.java.net/~sundar/8143404/top/webrev.00/ http://cr.openjdk.java.net/~sundar/8143404/langtools/webrev.00/ Thanks, -Sundar On 12/3/2015 9:12 PM, Alan Bateman wrote: On 03/12/2015 15:06,

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Dec 3, 2015, at 1:19 PM, Roger Riggs wrote: > > [1] http://cr.openjdk.java.net/~rriggs/cleaner-doc/ > [2] http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/ The implementation looks good. I’ll wait for an updated javadoc and re-review that incorporates

8144660: VersionCheck.java fails when it tries to run jaccess*.exe -J-version on windows

Hello, This is a change to ignore these binaries in the bin directory, which causes the test to fail, as these are GUI applications. Appreciate a quick reviewn. Please review. Thanks # HG changeset patch # Parent 8ef2bf79539ca446bd14505705cdf208dc2644cc diff --git

Re: RFR: jsr166 jdk9 integration wave 2

Hi Peter, I've done this trick before to perform Throwable cloning. You have to hunt for the constructors in this order: 1. Walk the type of the cause and super types by calling getConstructor(String, type of cause). (java.io.WriteAbortedException and javax.mail.MessagingException) 2. Walk

Re: RFR: 8071507: (ref) Clear phantom reference as soft and weak references do

On 12/03/2015 06:01 PM, Mandy Chung wrote: On Dec 3, 2015, at 5:01 AM, Peter Levart wrote: I would only rephrase this statement in package-info.java a bit: 96 * Soft and weak references are automatically cleared by the collector 97 * before being added to the