hg: jigsaw/jake/jdk: 8078813: Test JAAS with modules

[vincent . x . ryan]

Changeset: 9418361408f3
Author:vinnie
Date:  2015-11-07 00:15 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9418361408f3

8078813: Test JAAS with modules
Summary: Test JAAS LoginContext with different combination of module type.
Reviewed-by: weijun
Contributed-by: sibabrata.sa...@oracle.com

+ test/java/security/modules/JigsawSecurityUtils.java
+ test/javax/security/auth/login/modules/JaasModularClientTest.java
+ test/javax/security/auth/login/modules/TEST.properties
+ 
test/javax/security/auth/login/modules/src/jaasclientmodule/client/JaasClient.java
+ test/javax/security/auth/login/modules/src/jaasclientmodule/client/jaas.conf
+ 
test/javax/security/auth/login/modules/src/jaasloginmodule/login/TestLoginModule.java
! test/jdk/jigsaw/lib/JarUtils.java

Re: Implied readability + layers

[Alan Bateman]

On 06/11/2015 10:59, Ali Ebrahimi wrote:

:

module com.foo {
 requires com.baz;

 exports com.foo;

}
In this example then com.foo will also need to require com.bar as 
otherwise com.foo will not compile (I assume you've deliberately removed 
the requires public for this example).


In any case, I think what you have here is:

layer1:
com.bar@1
com.baz reads com.bar@1

The (library) module com.baz has com.bar types in its API.

layer2
com.bar@2
com.foo reads com.baz
com.foo reads com.bar@2



:


Result:

bar1
bar2

As you can see com.foo reads com.bar@2 without reflection.
Yes, because when creating the configuration for this layer then you are 
resolving com.bar and have arranged that it be found with the 
before-finder. You would get the same thing if you just resolved com.foo 
because resolving com.foo's dependences would require finding com.bar.


In any case, I think you will start to see some of the issues that Alex 
warns about when you change com.foo.Main to do more than invoke 
toString.  If you change it to create Bar and Baz objects for example 
then it's easy to provoke this example to fail with a loader constraint 
violation.


-Alan

Re: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw

[Rahman USTA]

Thank you Kevin, I'll move on openjfx-dev.

2015-11-05 23:41 GMT+02:00 Kevin Rushforth :

> Yes, this is case of your using internal classes and unsupported methods,
> so let's discuss on openjfx-dev to see if there is another way to do what
> you want to do. I note that in addition to the two internal classes, you
> are also accessing a non-supported (and not documented) impl_* method which
> may or may not continue to work.
>
> -- Kevin
>
>
> Rahman USTA wrote:
>
> I'm using ContextMenuContent to add new menu items to webview's default
> context menu. I can set a new ContextMenu for Webviews but, I want to use
> actions of default menuitems as well. Code
> 
>
> I'm doing something when application focus-out, but when an JavaFX Alert
> is shown, it acts as focus-out, to avoid this circumstances I'm using
> StageHelper Code
> 
>
> Note: I can also ask the question to openjfx-dev
>
> 2015-11-05 21:51 GMT+02:00 Kevin Rushforth :
>
>> The StageHelper class is deliberately not exposed for good reasons, since
>> it's purpose is to provide internal access to non-public state.
>>
>> We moved most of the skin classes to a publicly exported
>> javafx.scene.control.skin package as part of JEP 253, but that didn't
>> include ContextMenuContent.
>>
>> Can you explain what you are trying to do with these classes? Perhaps
>> there is an alternative? If this is a detailed JavaFX question, then I
>> suggest asking it on openjfx-dev rather than jigsaw-dev.
>>
>> -- Kevin
>>
>>
>>
>> Rahman USTA wrote:
>>
>>> Hi all;
>>>
>>> I'm trying Jigsaw build with my JavaFX project, everything is fine but
>>> with
>>> two exception.
>>>
>>> javac could not find/access
>>> com.sun.javafx.scene.control.skin.ContextMenuContent
>>> and com.sun.javafx.stage.StageHelper classes.
>>>
>>> Is it possible to use them or are there any alternatives for these
>>> classes.
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta 
>
>


-- 
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta 

Re: Implied readability + layers

[Ali Ebrahimi]

Hi,

On Fri, Nov 6, 2015 at 4:09 AM, Alex Buckley 
wrote:
>
>
> com.foo in layer2 requires com.baz in layer1, right? Yes.
>
> com.baz in layer1 uses types from com.bar in layer1, and NOT from com.bar
> in layer2, right? Yes.
>
> Therefore, com.foo uses types from com.bar in layer1 (as required by
> com.baz in layer1), right? Yes.
>
> I don't know what it means to say "we use com.bar@2 for layer2's
> modules". com.foo is in layer2, and you can make it read com.bar@2 via
> reflection, but otherwise com.bar@2 is not read by com.foo because
> com.baz doesn't know about it.

There is no need for reflection:
Please follow this sample and test it:

layer 1: com.baz and com.bar@1
---

module com.bar {//version1
exports com.bar;
}

--

//Bar.java

package com.bar;
public class Bar {
public String bar(){ return "bar1";}
}

module com.baz {
requires com.bar;
exports com.baz;
}

-

//Baz.java

package com.baz;

import com.bar.Bar;
public class Baz {
public String baz(){ return new Bar().bar();}
public Bar bar(){
return new Bar();
}
}

layer 2: com.foo and com.bar@2

 module com.bar {//version2

exports com.bar;
}

-

//Bar.java

package com.bar;

public class Bar {
public String bar(){ return "bar2";}
}

-

module com.foo {
requires com.baz;

exports com.foo;

}

-

Foo.java

package com.foo;

import com.bar.Bar;
import com.baz.Baz;

public class Main {
public static void main(String[] args) {
System.out.println(new Baz().baz());
System.out.println(new Bar().bar());
}
}


-

test code

public class Test {
public static void main(String[] args) throws Exception {
ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1"));
Configuration cfg1 = Configuration.resolve(finder1,
Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz");

ModuleClassLoader cl1 = new ModuleClassLoader(cfg1);
Layer layer1 = Layer.create(cfg1, m -> cl1);

ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2"));
Configuration cfg2 = Configuration.resolve(finder2,
layer1,ModuleFinder.empty(),"com.bar","com.foo");

ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2);
Layer layer2 = Layer.create(cfg2, m -> cl2);



Module foo = layer2.findModule("com.foo").get();
Module bar2 = layer2.findModule("com.bar").get();

Module bar1 = layer1.findModule("com.bar").get();

ClassLoader fooModuleLoader = layer2.findLoader("com.foo");
Class mainClass = fooModuleLoader.loadClass("com.foo.Main");

Test.class.getModule().addReads(mainClass.getModule());
Method mainMethod = mainClass.getMethod("main", String[].class);

mainMethod.invoke(null, (Object)new String[0]);
}

}

Result:

bar1
bar2

As you can see com.foo reads com.bar@2 without reflection.

I say this is puzzling since with almost the equivalent code I get
another result. If you want I can show for you in another post.

If you want I can send all test files to your mail?


-- 

Best Regards,
Ali Ebrahimi

Re: Avoiding same-package conflicts

[Jochen Theodorou]

On 03.11.2015 22:28, Alex Buckley wrote:
[...]

groovy-compiler will obviously have a hard dependency on groovy-base,
but you can avoid groovy-base having a hard dependency on
groovy-compiler by using services. Of course this assumes a suitable
split between the interface of your compiler and its implementation.


and of course that split does not exist ;) It is a difference of not 
including something and referring to it by reflection, to have it 
optional; and to have it as a service. The first we can do without 
bigger changes, the later requires the definition of a whole "new" API.


[...]

One option for the Groovy runtime is to special case its meta class
package hierarchy by arranging for g.r.m.** classes to be defined by,
and exported from, a special module that the runtime generates; the
runtime would set up readability between this module and the user
modules that "thought" they were defining and exporting g.r.m.**.

You can see a flavor of this technique in the "dynamic module" created
by Java's Core Reflection when you proxy certain interfaces -- see
"Package and Module Membership of Proxy Class" in
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html.


will have a look soon, thanks.

bye Jochen

Re: Implied readability + layers

[Alan Bateman]

On 06/11/2015 19:18, Ali Ebrahimi wrote:


This is my bad, I emitted requires public when typing mail.
The is correct version:

module com.baz{
  requires public  com.baz;
  exports com.bar;
}

Stil result is:

foo.canRead(bar2) -> true
foo.canRead(bar1) -> false
baz.canRead(bar1) -> true
baz.canRead(bar2) -> false
bar1
bar2


But:
I figure out what is problem here:
If you try this sample once with exploded modules and then with 
modular jars you will found.


Right, I think you are running into issue again where the two versions 
of com.bar have equal ModuleDescriptors. When you create modular JAR 
then I'm guessing you add a module version and this makes them non-equal.


For the exploded module case then you could changing one of them to 
"export com.bar.extra" to make them non-equal. This is just temporary 
until we get the API changed as I mentioned in some of the other mails.




Also, if you remove com.bar from root module list for cfg2 final 
result will change:


 Configuration cfg2 = Configuration
.resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
.bind();

So all of this can not cause hard to find bugs in user applications.

Yes, nobody requires com.bar in the configuration for layer2 and so 
com.bar@2 is ignored.


-Alan

Re: Implied readability + layers

[Ali Ebrahimi]

Hi,

On Fri, Nov 6, 2015 at 11:42 PM, Alan Bateman 
wrote:

>
>
> On 06/11/2015 19:18, Ali Ebrahimi wrote:
>
>>
>>
> Right, I think you are running into issue again where the two versions of
> com.bar have equal ModuleDescriptors. When you create modular JAR then I'm
> guessing you add a module version and this makes them non-equal.
>
> For the exploded module case then you could changing one of them to
> "export com.bar.extra" to make them non-equal. This is just temporary until
> we get the API changed as I mentioned in some of the other mails.


Is not better we allow compiler support for module version in module
descriptor?

>
>
>> Also, if you remove com.bar from root module list for cfg2 final result
>> will change:
>>
>>  Configuration cfg2 = Configuration
>> .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
>> .bind();
>>
>> So all of this can not cause hard to find bugs in user applications.
>>
>> Yes, nobody requires com.bar in the configuration for layer2 and so
> com.bar@2 is ignored.

But don't you think with special handing of implied readability all of this
occurs and maybe some non-discovered ones.

May be user or IDE think adding 'requires com.bar' to com.foo is redundant
and removed.


-- 

Best Regards,
Ali Ebrahimi

Re: Implied readability + layers

[Ali Ebrahimi]

Hi,

On Fri, Nov 6, 2015 at 8:18 PM, Alan Bateman 
wrote:

>
>
> On 06/11/2015 10:59, Ali Ebrahimi wrote:
>
>> :
>>
>> module com.foo {
>>  requires com.baz;
>>
>>  exports com.foo;
>>
>> }
>>
> In this example then com.foo will also need to require com.bar as
> otherwise com.foo will not compile (I assume you've deliberately removed
> the requires public for this example).
>
This is my bad, I emitted requires public when typing mail.
The is correct version:

module com.baz{
  requires public  com.baz;
  exports com.bar;
}

Stil result is:

foo.canRead(bar2) -> true
foo.canRead(bar1) -> false
baz.canRead(bar1) -> true
baz.canRead(bar2) -> false
bar1
bar2


But:
I figure out what is problem here:
If you try this sample once with exploded modules and then with modular
jars you will found.

Also, if you remove com.bar from root module list for cfg2 final result
will change:

 Configuration cfg2 = Configuration
.resolve(finder2, layer1,ModuleFinder.empty(),"com.foo")
.bind();

So all of this can not cause hard to find bugs in user applications.




-- 

Best Regards,
Ali Ebrahimi

Re: Implied readability + layers

[Ali Ebrahimi]

Hi,

On Fri, Nov 6, 2015 at 9:20 PM, Alex Buckley 
wrote:

>
>>
>> importcom.bar.Bar;
>> public classBaz {
>>  publicString baz(){return newBar().bar();}
>>  publicBar bar(){
>>  return newBar();
>>  }
>> }
>>
>
> I expect javac will warn about the bar() method of class Baz. As a public
> method in a public type in an exported package, its return type is from
> another module (com.bar), yet module com.baz doesn't set up implied
> readability to that other module. Anyway, moving on.
>
As said in Alan's response this is my bad and I missed requires public.


>
> layer 2: com.foo and com.bar@2
>> 
>> module com.bar {//version2
>>
>>  exports com.bar;
>> }
>>
>> -
>>
>> //Bar.java
>>
>> packagecom.bar;
>>
>> public classBar {
>>  publicString bar(){return"bar2";}
>> }
>>
>> -
>>
>> module com.foo {
>>  requires com.baz;
>>
>>  exports com.foo;
>>
>> }
>>
>> -
>>
>> Foo.java
>>
>> packagecom.foo;
>>
>> importcom.bar.Bar;
>> importcom.baz.Baz;
>>
>> public classMain {
>>  public static voidmain(String[] args) {
>>  System.out.println(newBaz().baz());
>>  System.out.println(newBar().bar());
>>  }
>> }
>>
>
> Foo.java should not compile. 'import com.bar.Bar' names a type that is
> inaccessible from module foo. This makes the rest of the scenario moot.
>
>>
>>
>> I say this is puzzling since with almost the equivalent code I get
>> another result. If you want I can show for you in another post.
>>
>
> It is puzzling. By specifying com.bar@2 as one of the root modules in
> cfg2, you have managed to get layer2's loader to load the class com.bar.Bar
> from com.bar@2. And code in module foo can access that class, despite
> module foo not reading any com.bar module.
>

I sent test files directly to your mail.


-- 

Best Regards,
Ali Ebrahimi