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

[Martin Buchholz]

On Sun, Sep 25, 2016 at 2:22 PM, David Holmes 
wrote:

>
> Yet we somehow added the clarification with no regard as to whether cancel
> returned true or not. That seems wrong.
>

Yikes!  I had always assumed that cancel was not permitted to leave the
Future incomplete, perhaps influenced by the wording,

"""After this method returns, subsequent calls to {@link #isDone} will
always return {@code true}."""

It's much more in the spirit of Java to throw an exception if the future
cannot be completed.  It's never come up, I think.

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

[Lance Andersen]

Hi Aleks,

I still would suggest not pointing at jaxb.java.net for the specification given 
these projects are going to have to migrate elsewhere.

Best
Lance
> On Sep 25, 2016, at 7:41 PM, Aleks Efimov  wrote:
> 
> Hi Alan, Joe, Mandy, Roman,
> 
> Suggested changes to the comment section (will bring this change to 
> standalone JAXB) and to the exported internal API were made:
> com.sun.xml.internal.stream.writers, 
> com.sun.org.apache.xml.internal.resolver, 
> com.sun.org.apache.xml.internal.resolver.tools dependencies were removed.
> 
> The updated webrev:
> http://cr.openjdk.java.net/~aefimov/8164479/01
> 
> Best Regards,
> Aleksej
> 
> 
> On 25/09/16 17:49, Alan Bateman wrote:
>> On 24/09/2016 18:57, Mandy Chung wrote:
>> 
>>> You can run jdeps --check java.xml.ws on your local build with this change.
>>> 
>>> This will analyze the dependences and any unused qualified exports.
>>> 
>> Good idea. I think java.activation's module-info.java will need updating too 
>> as it no longer requires java.desktop (we can decide at a later time whether 
>> to change this to `requires static` and change this code to use a reflection 
>> guard + static reference).
>> 
>> -Alan
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

[Aleks Efimov]

Hi Alan, Joe, Mandy, Roman,

Suggested changes to the comment section (will bring this change to 
standalone JAXB) and to the exported internal API were made:
com.sun.xml.internal.stream.writers, 
com.sun.org.apache.xml.internal.resolver, 
com.sun.org.apache.xml.internal.resolver.tools dependencies were removed.


The updated webrev:
http://cr.openjdk.java.net/~aefimov/8164479/01

Best Regards,
Aleksej


On 25/09/16 17:49, Alan Bateman wrote:

On 24/09/2016 18:57, Mandy Chung wrote:

You can run jdeps --check java.xml.ws on your local build with this 
change.


This will analyze the dependences and any unused qualified exports.

Good idea. I think java.activation's module-info.java will need 
updating too as it no longer requires java.desktop (we can decide at a 
later time whether to change this to `requires static` and change this 
code to use a reflection guard + static reference).


-Alan

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

[Martin Buchholz]

On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang 
wrote:

> If that truely is the case then the only way of implementing a readonly
> Future is by throwing an exception from cancel...
>
We the maintainers of j.u.c.Future have always thought that canceling a
Future will surely leave it completed.  Of course, implementers of any Java
interface can choose to throw UOE for any method, but this is not intended
for Future.cancel.  An interface without cancel probably should not be
extending Future.

---

Here's another way to think of the range of functionality between current
CompletionStage and current CompletableFuture:

- Add Polling methods from scala Future such as isCompleted

These are also discouraged, but less so than Await methods
"""Note: using this method yields nondeterministic dataflow programs."""
Will adding these to CompletionStage be less controversial?

- Add Await blocking methods (that in scala cannot be called directly,
using the CanAwait mechanism)

- Add cancellation

- Add other methods to complete the future ("Promise")

- Add the full CompletableFuture API, including the obtrude methods

Cancellation is interesting, because it's a mutating method, and so cannot
be used with a future shared with other users, but it also seems very
reasonable as a "client" operation.  One can think of obtaining a
non-shared future as a subscription to a one-time event, and that
subscription takes up resources in the form of an object.  If the client is
no longer interested in the event, then cancellation of the future can free
up resources.  I'm still thinking of what Process.onExit

should return.  There's a tension between the various roles that
CompletableFuture serves - as a container to write a value, as a possibly
cancellable subscription to that value, and as a way to chain async
computations together.

On Wed, Sep 21, 2016 at 2:25 PM, Benjamin Manes  wrote:

> I've gradually come to terms using CF as part of an API and haven't
> experienced a downside yet.
>

H I seem to be moving in that direction as well...

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Sergei Kovalev]

If I've drop jdk.jartool, I faced with ClassNotFound error as I showed in #3

 java.lang.ClassNotFoundException: jdk.security.jarsigner.JarSigner$Builder

As you can see TEST.properties contains both: jdk.compiler and jdk.jartool


25.09.16 18:13, Alan Bateman wrote:

On 25/09/2016 16:05, Sergei Kovalev wrote:


Hi Alan,

Here is the result of one of the tests run in initial state (no fix 
applied)
For #2 and #3 then jtreg should ignore the test because they require 
jdk.compiler and jdk.jartool (declared in TEST.properties). This is 
why I'm wondering if we have a jtreg issue here. As I said, I don't 
have any issue working around this with the @modules that you propose 
but you can drop "/javax.tools" as it is not needed.


-Alan


--
With best regards,
Sergei

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Alan Bateman]

On 25/09/2016 16:05, Sergei Kovalev wrote:


Hi Alan,

Here is the result of one of the tests run in initial state (no fix 
applied)
For #2 and #3 then jtreg should ignore the test because they require 
jdk.compiler and jdk.jartool (declared in TEST.properties). This is why 
I'm wondering if we have a jtreg issue here. As I said, I don't have any 
issue working around this with the @modules that you propose but you can 
drop "/javax.tools" as it is not needed.


-Alan

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Sergei Kovalev]

Hi Alan,

Here is the result of one of the tests run in initial state (no fix applied)

1) no module limitation

jtreg -jdk:/home/skovalev/TRASH/jdk-9 -verbose:all 
/home/skovalev/repos/jake/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java


TEST RESULT: Passed. Execution successful

2) limit modules java.base

jtreg -jdk:/home/skovalev/jdk-9 -verbose:all 
-javaoptions:"--limit-modules java.base" 
/home/skovalev/repos/jake/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java


STDOUT:
Error occurred during initialization of VM
java.lang.module.ResolutionException: Module java.compiler not found, 
required by jdk.compiler

at java.lang.module.Resolver.fail(java.base@9-ea/Resolver.java:790)
at 
java.lang.module.Resolver.resolve(java.base@9-ea/Resolver.java:138)
at 
java.lang.module.Resolver.resolveRequires(java.base@9-ea/Resolver.java:108)
at 
java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea/Configuration.java:370)
at 
java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea/ModuleDescriptor.java:1986)
at 
jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:263)

at java.lang.System.initPhase2(java.base@9-ea/System.java:1927)

3) In case I limiting modules java.base and jdk.compiler only (with 
modified TEST.prioperties)


jtreg -jdk:/home/skovalev/jdk-9 -verbose:all 
-javaoptions:"--limit-modules java.base,jdk.compiler" 
/home/skovalev/repos/jdk9-dev/jdk/test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java


config MultiReleaseJarAPI.initialize(): failure
java.lang.NoClassDefFoundError: jdk/security/jarsigner/JarSigner$Builder
at 
CreateMultiReleaseTestJars.buildSignedMultiReleaseJar(CreateMultiReleaseTestJars.java:147)

at MultiReleaseJarAPI.initialize(MultiReleaseJarAPI.java:74)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
at 
org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:515)
at 
org.testng.internal.Invoker.invokeConfigurations(Invoker.java:216)
at 
org.testng.internal.Invoker.invokeConfigurations(Invoker.java:143)
at 
org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:178)
at 
org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)

at org.testng.TestRunner.privateRun(TestRunner.java:778)
at org.testng.TestRunner.run(TestRunner.java:632)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1147)
at org.testng.TestNG.runSuites(TestNG.java:1072)
at org.testng.TestNG.run(TestNG.java:1044)
at 
com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:220)
at 
com.sun.javatest.regtest.TestNGAction$TestNGRunner.main(TestNGAction.java:184)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)

at java.lang.Thread.run(java.base@9-ea/Thread.java:843)



25.09.16 17:48, Alan Bateman wrote:

On 25/09/2016 13:53, Sergei Kovalev wrote:


Hi Alan,

The modules list in mrar/TEST.properties guarantee that jtreg add 
"--add-module @modules" command line option during test execution. If 
you create custom JRE that does not contains the modules, the tests 
fails. The proposed fix guarantee that jtreg skips the tests if no 
listed modules found.
Are you sure about this? I believe the original intent was that jtreg 
would select the test to run when the runtime has the required modules 
(@modules just overrides the value of "modules" that is read from 
TEST.properties).


In any case, it should be "@modules java.compiler", 

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

[Alan Bateman]

On 24/09/2016 18:57, Mandy Chung wrote:


You can run jdeps --check java.xml.ws on your local build with this change.

This will analyze the dependences and any unused qualified exports.

Good idea. I think java.activation's module-info.java will need updating 
too as it no longer requires java.desktop (we can decide at a later time 
whether to change this to `requires static` and change this code to use 
a reflection guard + static reference).


-Alan

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Alan Bateman]

On 25/09/2016 13:53, Sergei Kovalev wrote:


Hi Alan,

The modules list in mrar/TEST.properties guarantee that jtreg add 
"--add-module @modules" command line option during test execution. If 
you create custom JRE that does not contains the modules, the tests 
fails. The proposed fix guarantee that jtreg skips the tests if no 
listed modules found.
Are you sure about this? I believe the original intent was that jtreg 
would select the test to run when the runtime has the required modules 
(@modules just overrides the value of "modules" that is read from 
TEST.properties).


In any case, it should be "@modules java.compiler", no need to include 
/javax.tools because that package is exported.


-Alan

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

[Viktor Klang]

If that truely is the case then the only way of implementing a readonly
Future is by throwing an exception from cancel...

-- 
Cheers,
√

On Sep 25, 2016 4:20 PM, "Joe Bowbeer"  wrote:

> This statement regarding what happens after cancel is called is correct:
>
> "*After this method returns, subsequent calls to **isDone**() will always
> return true*. Subsequent calls to isCancelled() will always return true
> if this method returned true."
>
> After cancel returns, the future is completed, hence isDone. If cancel
> returns true, i.e. it was cancelled, then  isCancelled returns true. But,
> for example if the future is already completed when cancel is called, then
> cancel will return false and isCancelled will return false.
>
> On Sep 25, 2016 6:49 AM, "David Holmes"  wrote:
>
>> I think that was meant to read “After this method returns _*true*_,
>> subsequent calls …”
>>
>>
>>
>> David
>>
>>
>>
>> *From:* Concurrency-interest [mailto:concurrency-interest-b
>> oun...@cs.oswego.edu] *On Behalf Of *Viktor Klang
>> *Sent:* Sunday, September 25, 2016 9:03 PM
>> *To:* Martin Buchholz 
>> *Cc:* concurrency-interest ;
>> core-libs-dev 
>> *Subject:* Re: [concurrency-interest] We need to add blocking methods to
>> CompletionStage!
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang 
>> wrote:
>>
>>
>>
>>
>>
>> On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz 
>> wrote:
>>
>> No one is suggesting we add cancel to CompletionStage - I agree that
>> would break users, by making an immutable interface mutable.
>>
>>
>>
>> +1
>>
>>
>>
>> This also means that CompletionStage cannot extend Future.
>>
>>
>>
>> +1
>>
>>
>>
>> I also would not want to have a toFuture method that would return a
>> j.u.c.Future, because of misfit Future.cancel.
>>
>>
>>
>> Would you mind elaborating here? According to the cancel method spec on
>> Future it is completely fine for it to be a no-op which always returns
>> false:
>>
>>
>>
>> "This attempt will fail if the task has already completed, has already
>> been cancelled, *or could not be cancelled for some other reason.*"
>>
>>
>>
>> Source: https://docs.oracle.com/javase/8/docs/api/java/util/concurre
>> nt/Future.html
>>
>>
>>
>> There's an interesting (read: weird) spec clause in cancel:
>>
>>
>>
>> "*After this method returns, subsequent calls to isDone() will always
>> return true*. Subsequent calls to isCancelled() will always return true
>> if this method returned true."
>>
>>
>>
>> That clause is in contradiction with the previously quoted line.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   If we are adding cancel, then it will be to make a new interface, such
>> as the suggested CancellableCompletionStage.
>>
>>
>>
>> I also agree that CompletionStage does *not* represent "a running task of
>> sorts", j.u.c. Future specs are still confusing in that way due to
>> FutureTask heritage.
>>
>>
>>
>> +1
>>
>>
>>
>>
>>
>> On Thu, Sep 22, 2016 at 7:51 PM, James Roper  wrote:
>>
>> For example, we often cache futures and return them from a libraries API,
>> if a client could cancel a future, that would break everything else that
>> received that future.
>>
>>
>>
>> On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang 
>> wrote:
>>
>> PPS: A misunderstanding is that CompletionStage represents a running task
>> of sorts, one that can be cancelled etc. This is not the case.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Cheers,
>>
>> √
>>
>>
>>
>>
>>
>> --
>>
>> Cheers,
>>
>> √
>>
>> ___
>> Concurrency-interest mailing list
>> concurrency-inter...@cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

[Sergei Kovalev]

Hi Alan,

The modules list in mrar/TEST.properties guarantee that jtreg add 
"--add-module @modules" command line option during test execution. If 
you create custom JRE that does not contains the modules, the tests 
fails. The proposed fix guarantee that jtreg skips the tests if no 
listed modules found.



24.09.16 13:02, Alan Bateman wrote:

On 23/09/2016 14:54, Sergei Kovalev wrote:


Hello team,

Could you please review a very small fix that relates to tests only.

BugID: https://bugs.openjdk.java.net/browse/JDK-8166624
Webrev: http://cr.openjdk.java.net/~skovalev/8166624/webrev.00/
"@modules java.compiler/javax.tools" looks odd, should this be simply 
"@modules java.compiler"?


In any case, I would have thought that the modules list in 
mrjar/TEST.properties was enough to ensure these tests don't run when 
the runtime under test doesn't have jdk.jartool or jdk.compiler. But 
perhaps the motivation of the change is to make it more fine grained?


-Alan


--
With best regards,
Sergei