2016/6/13 5:13:20 -0700, coleen.phillim...@oracle.com:
> Hi Mark, Thank you for replying. Yes, I understand below.
>
> I have to explain that my exposure to this started with the code
> review. That is, working backwards from this design. So it led me to
> question the design and I hope tha
I've updated JEP 261 (http://openjdk.java.net/jeps/261). Major changes
include:
- The special ALL-DEFAULT module name, which represents the default
set of root modules for use with the -addmods option [1];
- A more thorough explanation of how the built-in class loaders have
changed,
> On Jun 15, 2016, at 1:32 PM, Mandy Chung wrote:
>
>
>> On Jun 14, 2016, at 4:00 PM, Mandy Chung wrote:
>>
>>
>>> On Jun 14, 2016, at 3:53 PM, Alexandre (Shura) Iline
>>> wrote:
>>>
>>> Hi.
>>>
>>> After some offline conversations it was decided to leave the tests which
>>> depend on a
> On Jun 14, 2016, at 4:00 PM, Mandy Chung wrote:
>
>
>> On Jun 14, 2016, at 3:53 PM, Alexandre (Shura) Iline
>> wrote:
>>
>> Hi.
>>
>> After some offline conversations it was decided to leave the tests which
>> depend on absence of “-limitmods” in VM options for later. I have created a
>
> On Jun 15, 2016, at 9:34 AM, Jim Laskey (Oracle)
> wrote:
>
> Webrev updated in place.
Looks good.
Mandy
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155955/webrev.02
With further discussion with Chris Bensen and others, we agree that the
packager would require the presence of the packaged module of jdk.packager to
be present matching the runtime version of the image being created. The
packag
Webrev updated in place.
> On Jun 15, 2016, at 9:50 AM, Jim Laskey (Oracle)
> wrote:
>
>
>> On Jun 14, 2016, at 11:51 PM, Mandy Chung wrote:
>>
>> I reviewed http://cr.openjdk.java.net/~jlaskey/8159206/webrev
>>
>> Looks much cleaner. Thanks for the update
>>
>> 342 StringSharingPlugi
2016/6/15 8:48:57 -0700, pbened...@apache.org:
> If a JAR, properly built as a module, is dropped onto the classpath at
> runtime, does it function as a module or does it get treated as part of the
> unnamed module with all types exported?
The latter.
- Mark
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.
cheers,
Rémi
Le 15 juin 2016 17:48:57 CEST, Paul Benedict a écrit :
>If a JAR, properly built as a module, is dropped onto the classpath at
>runtim
If a JAR, properly built as a module, is dropped onto the classpath at
runtime, does it function as a module or does it get treated as part of the
unnamed module with all types exported?
Cheers,
Paul
Hi Gunnar,
I don't recall a significant change recently regarding the errors, javac
(should) currently produce either the "cannot find" or "not visible"
error depending on exact circumstances ("not visible" should be produced
if javac have already seen the given class). We are currently lookin
> On Jun 14, 2016, at 11:51 PM, Mandy Chung wrote:
>
> I reviewed http://cr.openjdk.java.net/~jlaskey/8159206/webrev
>
> Looks much cleaner. Thanks for the update
>
> 342 StringSharingPlugin(String[] patterns) throws IOException {
> 343 this(ResourceFilter.includeFilter(Arrays.asL
Hi,
When referring to a not-exported type from another module, I'm getting this
rather generic compilation error:
package someprivate.pakkage does not exist
import someprivate.pakkage.SomeType;
^
error: cannot find symbol SomeType
As if the t
13 matches
Mail list logo
