Hi Serguei,
1s of all, thank you for your review.
since these tests have dependencies on more modules than corresponding
TEST.properties file declares, we have to specify @modules tag in them, and
because @modules in a test overrides modules from TEST.properties, jdk.jdi
module should be
Hi Igor,
This looks good to me.
A couple of questions below.
http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/test/com/sun/jdi/InvokeHangTest.java.udiff.html
- * @modules jdk.jdi
* @library /test/lib
+ * @modules java.management
+ * jdk.jdiShould the jdk.jdi be removed from
Shura,
Thank you for your review. I have update
test/java/lang/management/PlatformLoggingMXBean/TEST.properties[1] and checked
that there are no similar things in other TEST.properties files.
Still looking for a review from a Reviewer.
[1]
> ---
On 15 March 2017 at 17:47, Alan Bateman wrote:
> This is the consumer choosing a module name for a library that they don't
> maintain and renaming that library to match (you are writing the `requires
> X` before X exists). All I'm saying is that the library maintainer
On 15/03/2017 17:09, Stephen Colebourne wrote:
:
The proposal above only applies at runtime, not when authoring. Given a module:
module foo {
requires bar;
}
Then the proposal says the requires clause can be satisfied in one of
three ways.
1) a real module on the module path named "bar"
2)
> On Mar 15, 2017, at 10:12 AM, Chris Hegarty wrote:
>
>>
>> Is there any reason why this option does not print the synthesized
>> descriptor? I understand that the issue is specific to show the derived
>> module name. But it’d be nice for this option to print the
> On 15 Mar 2017, at 16:54, Mandy Chung wrote:
>
>>
>> On Mar 15, 2017, at 8:31 AM, Chris Hegarty wrote:
>>
>>
>>> On 15 Mar 2017, at 14:42, Alan Bateman wrote:
>>>
>>> On 15/03/2017 14:21, Chris Hegarty wrote:
>>>
Igor,
I have looked through a bunch of tests where @modules is changed - that looks
good.
One minor thing I noticed is that, in
test/java/lang/management/PlatformLoggingMXBean/TEST.properties you are
explicitly calling out java.management. You do not have to do that because
“modules”
> On Mar 15, 2017, at 8:31 AM, Chris Hegarty wrote:
>
>
>> On 15 Mar 2017, at 14:42, Alan Bateman wrote:
>>
>> On 15/03/2017 14:21, Chris Hegarty wrote:
>>
>>> :
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~chegar/8176772.00/
>>>
> On 15 Mar 2017, at 14:42, Alan Bateman wrote:
>
> On 15/03/2017 14:21, Chris Hegarty wrote:
>
>> :
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~chegar/8176772.00/
>> https://bugs.openjdk.java.net/browse/JDK-8176772
>>
> If findAll returns an empty set then
On 15/03/2017 14:21, Chris Hegarty wrote:
:
Webrev:
http://cr.openjdk.java.net/~chegar/8176772.00/
https://bugs.openjdk.java.net/browse/JDK-8176772
If findAll returns an empty set then the error.unable.derive.automodule
message might be more appropriate. Otherwise looks good to me.
On 15/03/2017 10:13, Stephen Colebourne wrote:
Automatic modules must either contain the
Module-Name MANIFEST entry, or have a file name that exactly matches
the desired module name. ie. the standard jar files downloaded from
Maven Central, eg foo-bar-1.2 must be renamed to be used as an
+1
I have been planning to write a similar comment. I understand that the
main desire is to discourage version numbers to creep into module names,
but no rule can prevent that entirely. We can only advise against it,
not police it. If one wants to do it otherwise, let him do it. He'll
soon
Responding to the discussion on the EG list.
I am now strongly of the opinion that using the language to restrict
module names to not end in a number is a mistake. The two clear cases
show two reasons why it is a mistake.
commons-lang3 is the third version of commons-lang. It was named this
way
Changeset: fb9bb5851e88
Author:alanb
Date: 2017-03-15 10:00 +
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fb9bb5851e88
Tempoarily exclude tools/javac/platform/PlatformProviderTest.java
! test/ProblemList.txt
15 matches
Mail list logo