On 18/05/2016 22:47, David M. Lloyd wrote:
I mean in *our* current concept of a module, we can add/remove/modify
the contents of a module (its "class path") at run time. It is up to
the user to ensure that doing so makes sense.
I don't think I can relate to the use case. As you probably know
> On 20 May 2016, at 15:12, Alan Bateman wrote:
>
> On 18/05/2016 22:47, David M. Lloyd wrote:
>>
>> I mean in *our* current concept of a module, we can add/remove/modify the
>> contents of a module (its "class path") at run time. It is up to the user
>> to ensure that doing so makes sense.
On 05/20/2016 09:12 AM, Alan Bateman wrote:
On 18/05/2016 22:47, David M. Lloyd wrote:
I mean in *our* current concept of a module, we can add/remove/modify
the contents of a module (its "class path") at run time. It is up to
the user to ensure that doing so makes sense.
I don't think I can r
I had one last follow-up thought, see below:
On 05/20/2016 10:20 AM, David M. Lloyd wrote:
You can't, on one hand, define a universal namespace and syntax for
modules and their versions in the JDK or establish hard constraints on
layer and module graph structure, and on the other hand expect oth
I was on a project using OSGi where some of the applications relied on removing
and replacing modules.
Generally they replaced applications modules at the top with no dependencies
into the module.
For example, in one application that dealt with RFID, it was common for new
RFID clients to be intr
Hi,
I have a weird use case in jcstress around @Contended.
In order to support both JDK 8 and JDK 9 we build against *our own*
sun.misc.Contended and jdk.internal.annotations.Contended. This works
arguably well for both compiling and running with both JDK 8 and JDK 9:
the real annotation gets pic
What do you get if you mix JEP 261 [1] with JEP 238 [2]?
A Multi-release modular JAR.
This issue proposes to add support to the jar tool for creating and
updating modular JAR files with an optional module-info.class in the
versioned section.
MRJARs are intended to target multiple releases of the
It would be good if (eventually) there were test cases involving the use
of MRM jars, both via the JarFile API and jar-fs file system, perhaps
extending to the use of MRM jars in javac as well.
-- Jon
On 05/20/2016 08:55 AM, Chris Hegarty wrote:
What do you get if you mix JEP 261 [1] with JEP 2
Chris,
Does the test need to use @modules for jdk.jartool and java.compiler?
Shura
> On May 20, 2016, at 8:55 AM, Chris Hegarty wrote:
>
> What do you get if you mix JEP 261 [1] with JEP 238 [2]?
> A Multi-release modular JAR.
>
> This issue proposes to add support to the jar tool for creatin
On 20/05/2016 16:55, Aleksey Shipilev wrote:
Hi,
I have a weird use case in jcstress around @Contended.
In order to support both JDK 8 and JDK 9 we build against *our own*
sun.misc.Contended and jdk.internal.annotations.Contended. This works
arguably well for both compiling and running with bot
If you have your own sun.misc.FOO on the classpath, then you DON'T want
a module exporting sun.misc to be readable, because that module is where
javac and the runtime will get sun.misc.* types from. So, no need to add
readability of the jdk.unsupported module which is not read by default
on JDK
On 5/20/2016 9:13 AM, Alex Buckley wrote:
If you have your own sun.misc.FOO on the classpath, then you DON'T want
a module exporting sun.misc to be readable, because that module is where
javac and the runtime will get sun.misc.* types from. So, no need to add
readability of the jdk.unsupported mo
On 20 May 2016, at 17:10, Alexandre (Shura) Iline
wrote:
>
> Chris,
>
> Does the test need to use @modules for jdk.jartool and java.compiler?
Yes, of course. Added, and updated in-place.
http://cr.openjdk.java.net/~chegar/8156497.00/
-Chris.
>
> Shura
>
>> On May 20, 2016, at 8:55 AM, Ch
> On 20 May 2016, at 17:01, Jonathan Gibbons
> wrote:
>
> It would be good if (eventually) there were test cases involving the use
> of MRM jars, both via the JarFile API and jar-fs file system, perhaps
> extending to the use of MRM jars in javac as well.
I agree.
Just to note, the updated te
On 05/20/2016 07:13 PM, Alan Bateman wrote:
> On 20/05/2016 16:55, Aleksey Shipilev wrote:
> jcstress is boot loader so I assume multi-release JARs are out of the
> question?
Yes, a simple workaround would be better than doing MR JARs at this
point. We have >50 Mb JARs as it is, MR JARs would be a
On 20/05/2016 18:02, Aleksey Shipilev wrote:
:
-Xmodule:jdk.unsupported definitely works, thanks!
What are the drawbacks for enabling this? I can easily enable that
globally for the entire project, but that would compile all project
files as if in the jdk.unsupported module? I guess that does
There are several patches that didn't go in with the last update, the
change to ModuleFinder.compose to use varargs was one of them. The other
part to this is removing the empty() method as it is redundant. The
changes are straight-forward:
http://cr.openjdk.java.net/~alanb/8152650/webrev/
On 20/05/2016 16:55, Chris Hegarty wrote:
:
http://cr.openjdk.java.net/~chegar/8156497.00/
Note: while there are some new test scenarios added, which give
reasonable coverage, further tests will be added later. Steve has some
additional jar tools support coming for easier creation of MRJARS.
On 19/05/2016 13:08, Uwe Schindler wrote:
:
FYI, this also explains why we did not see a compile failure about the
java.xml.bind issue (see previous mails)! This only failed at runtime, because
with Jigsaw, the java.xml.bind is not exposed by the root modules. But while
compiling it seems to
Hi,
> > FYI, this also explains why we did not see a compile failure about the
> java.xml.bind issue (see previous mails)! This only failed at runtime, because
> with Jigsaw, the java.xml.bind is not exposed by the root modules. But while
> compiling it seems to see all those classes, as its compi
Hi Alan,
Look here:
import javax.xml.bind.DatatypeConverter;
public class Test {
public static void main(String... args) throws Exception {
DatatypeConverter.parseBoolean("true");
}
}
$ javac Test.java
Test.java:1: error: package javax.xml.bind does not exist
import javax.xml.bind.Data
> On May 20, 2016, at 1:57 PM, Alan Bateman wrote:
>
>
> There are several patches that didn't go in with the last update, the change
> to ModuleFinder.compose to use varargs was one of them. The other part to
> this is removing the empty() method as it is redundant. The changes are
> straig
On 5/16/16 1:18 AM, Felix Yang wrote:
please review the updated webrev, which remove not-suggested filesystem
modification and codebase stuff:
http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/
Hi Felix,
OK, this is looking much better and simpler. The big improvement is, as we had
d
Stuart,
While I would agree on the use of one type, not two, for file paths, I
would question the choice to use String instead of Path. If something
is a file path, use the type system to say so, and use a Path.
-- Jon
On 05/20/2016 04:52 PM, Stuart Marks wrote:
On 5/16/16 1:18 AM, Felix Y
24 matches
Mail list logo
