On 15/06/16 17:12, Rémi Forax wrote:
> It is considered as a classical jar not a modular one. It's important
> because it enable backward compatibility without having to provide
> two jars.
Ok, so now the bonus question:
Does that mean that it is not possible to implement a Java JVMTI agent
as Ji
On 16/06/2016 10:11, Andrew Dinn wrote:
:
Ok, so now the bonus question:
Does that mean that it is not possible to implement a Java JVMTI agent
as Jigsaw modularised code?
I'll add the following to render the question more specific: Clearly,
you can deploy an agent that links to related code d
On 16/06/16 12:46, Alan Bateman wrote:
>
> On 16/06/2016 10:11, Andrew Dinn wrote:
>> :
>> Ok, so now the bonus question:
>>
>> Does that mean that it is not possible to implement a Java JVMTI agent
>> as Jigsaw modularised code?
>>
>> I'll add the following to render the question more specific: C
I need a Reviewer for a patch is to address two conformance issues.
One is that the ModuleFinder.of(Path...) javadoc doesn't make it clear
that an exception is thrown when a module descriptor cannot be created
for an automatic module. As part of this I've changed the implementation
to not sile
> On 16 Jun 2016, at 16:33, Alan Bateman wrote:
>
> I need a Reviewer for a patch is to address two conformance issues.
>
> One is that the ModuleFinder.of(Path...) javadoc doesn't make it clear that
> an exception is thrown when a module descriptor cannot be created for an
> automatic module
> On Jun 16, 2016, at 8:33 AM, Alan Bateman wrote:
>
> I need a Reviewer for a patch is to address two conformance issues.
>
> One is that the ModuleFinder.of(Path...) javadoc doesn't make it clear that
> an exception is thrown when a module descriptor cannot be created for an
> automatic mod
On 16/06/2016 17:31, Mandy Chung wrote:
:
ModuleFinder.of spec describes the possible cases where FindException may be
thrown by a module finder’s find or findAll methods.
It would be useful to have the @throws FindException if an error occurs finding
all modules in find and findAll methods t
Please definitely list all such possible exceptions. The knowledge
outweighs concern for clutter, IMO. I'd rather know the full number of ways
an API can fail rather than receive a failure that wasn't documented.
Cheers,
Paul
On Thu, Jun 16, 2016 at 11:44 AM, Alan Bateman
wrote:
> On 16/06/2016
On 16/06/2016 17:47, Paul Benedict wrote:
Please definitely list all such possible exceptions. The knowledge
outweighs concern for clutter, IMO. I'd rather know the full number of
ways an API can fail rather than receive a failure that wasn't documented.
There is one exception and all the cases
> On Jun 16, 2016, at 9:44 AM, Alan Bateman wrote:
>
> On 16/06/2016 17:31, Mandy Chung wrote:
>
>> :
>> ModuleFinder.of spec describes the possible cases where FindException may be
>> thrown by a module finder’s find or findAll methods.
>>
>> It would be useful to have the @throws FindExcept
On 16/06/2016 19:11, Mandy Chung wrote:
On Jun 16, 2016, at 9:44 AM, Alan Bateman wrote:
On 16/06/2016 17:31, Mandy Chung wrote:
:
ModuleFinder.of spec describes the possible cases where FindException may be
thrown by a module finder’s find or findAll methods.
It would be useful to have t
Please review this simple fix for two related aspects of the same problem:
Export the "standard doclet" used by javadoc, such that it is possible
to derive alternative doclets, either by delegation or subtyping.
In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old one
remains
> On Jun 16, 2016, at 7:28 PM, Jonathan Gibbons
> wrote:
>
> Please review this simple fix for two related aspects of the same problem:
>
> Export the "standard doclet" used by javadoc, such that it is possible to
> derive alternative doclets, either by delegation or subtyping.
>
> In JDK 9,
Would you please review the following patch for some minor test bug?
bug: https://bugs.openjdk.java.net/browse/JDK-8159762
webrev: http://cr.openjdk.java.net/~mli/8159762/webrev.00/
Thank you
-Hamlin
below comments in dif
14 matches
Mail list logo
