Re: [10] RFR: 8175233: Remove LambdaForm.debugName

2017-02-21 Thread John Rose
On Feb 20, 2017, at 6:24 AM, Claes Redestad wrote: > > the LambdaForm.debugName field is useful for debugging, but names > are generated and retained in this field also for production code, which > is then used to name generated methods and classes. Reviewed. This is

Re: [10] RFR: 8175233: Remove LambdaForm.debugName

2017-02-21 Thread Paul Sandoz
> On 21 Feb 2017, at 16:19, Claes Redestad wrote: >> >> LambdaForm >> — >> >> You might wanna consider colocating "lambdaName” with “generateDebugName”, >> then it’s easier to see that the latter is called from within a synchronized >> block of the former. >> > >

Re: [10] RFR: 8175233: Remove LambdaForm.debugName

2017-02-21 Thread Claes Redestad
Hi Paul, On 2017-02-21 23:46, Paul Sandoz wrote: On 20 Feb 2017, at 06:24, Claes Redestad wrote: Hi, the LambdaForm.debugName field is useful for debugging, but names are generated and retained in this field also for production code, which is then used to name

Re: [10] RFR: 8175233: Remove LambdaForm.debugName

2017-02-21 Thread Paul Sandoz
> On 20 Feb 2017, at 06:24, Claes Redestad wrote: > > Hi, > > the LambdaForm.debugName field is useful for debugging, but names > are generated and retained in this field also for production code, which > is then used to name generated methods and classes. > > This

[10] RFR: 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

2017-02-21 Thread Langer, Christoph
Hi Joe, please finally review this fix for JDK10: http://cr.openjdk.java.net/~clanger/webrevs/8168664-10.1/ This version contains the Java property "jdk.xml.generatePrefix" which we should have no matter on which default we decide. In my customer base I have customers that need it either way

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Bucek
Thanks for all responses. I understand how it works and it makes sense, but I believe the javadoc is not exact; SubsmissionPublisher#close doesn't mention any condition for the Subscriber#onComplete() invocation, but there obviously is one. Thanks again, Pavel On 21/02/2017 12:49, Doug Lea

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Michael McMahon
Maybe the spec could be tighter around this, but it's not unreasonable that there is a delay in receiving onComplete() notification because of the subscriber controlled flow control. Notifying onError() is not subject to flow control; so you might expect that it would be triggered immediately.

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Doug Lea
On 02/21/2017 06:36 AM, Pavel Rappo wrote: Only if you want an answer from the concurrency uber geeks :-) There seems to be no need for a further answer anyway! Thanks for pointing out that Subscription.request must be called to receive any items, and given this, the example works as

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Michael McMahon
On 21/02/2017, 11:15, Pavel Rappo wrote: I believe, the most appropriate place for concurrency-related questions is http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest As for the question itself. I don't think this behaviour is a bug. SubmissionPublisher.close() seems to

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Rappo
Only if you want an answer from the concurrency uber geeks :-) > On 21 Feb 2017, at 11:32, Pavel Bucek wrote: > > Thanks for the link to the other mailing list - do I understand it correctly > that I should move this thread there?

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Bucek
SubmissionPublisher#closeExceptionally does trigger Subscriber#onError, but based on javadoc, I cannot really be sure that it will be called, since it contains exactly the same wording as SubmissionPublisher#close /** * Unless already closed, issues {@link * Flow.Subscriber#onError(Throwable)

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Rappo
I believe, the most appropriate place for concurrency-related questions is http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest As for the question itself. I don't think this behaviour is a bug. SubmissionPublisher.close() seems to be a graceful way of shutting down (in contrast

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Michael McMahon
Sounds like a bug. It seems like the fact there isn't a call to Subscription.request() is what causes the problem. But by my reading of the spec, Subscriber.onComplete() should still be called, as it is known that " no additional Subscriber method invocations will occur". - Michael. On

Re: SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Bucek
there is a formatting issue in the code snippet, publisher.close() should be on the new line: { SubmissionPublisher publisher =new SubmissionPublisher<>(); publisher.subscribe(new Flow.Subscriber() { @Override public void onSubscribe(Flow.Subscription subscription) { }

SubmissionPublisher - Subscriber#onComplete() not invoked when publisher is closed

2017-02-21 Thread Pavel Bucek
Hi all, firstly - please let me know if this is is a wrong place to send this; I wasn't able to find list specific to concurrency. Consider following example: { SubmissionPublisher publisher =new SubmissionPublisher<>(); publisher.subscribe(new Flow.Subscriber() { @Override