RFR 8163952: jlink exclude VM plugin does not support static libraries
Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8163952 Thanks, -Sundar
Re: RFR 8163952: jlink exclude VM plugin does not support static libraries
+1 > On Sep 6, 2016, at 7:12 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8163952 > > Thanks, > > -Sundar >
Re: RFR 8163952: jlink exclude VM plugin does not support static libraries
Hi Sundar
I'm not familiar with the code, but the for-loop at lines 105-107 looks
like a bug, since only the first element is considered:
105 for (String jvmlib : jvmlibs) {
106 return t.path().endsWith("/" + jvmlib);
107 }
Kind regards,
Anthony
On 6/09/2016 12:12, Sundararajan Athijegannathan wrote:
Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for
https://bugs.openjdk.java.net/browse/JDK-8163952
Thanks,
-Sundar
Re: RFR 8163952: jlink exclude VM plugin does not support static libraries
I missed that as well. Good catch.
> On Sep 6, 2016, at 11:50 AM, Anthony Vanelverdinghe
> wrote:
>
> Hi Sundar
>
> I'm not familiar with the code, but the for-loop at lines 105-107 looks like
> a bug, since only the first element is considered:
>
> 105 for (String jvmlib : jvmlibs) {
> 106 return t.path().endsWith("/" + jvmlib);
> 107 }
>
> Kind regards,
> Anthony
>
>
> On 6/09/2016 12:12, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for
>> https://bugs.openjdk.java.net/browse/JDK-8163952
>>
>> Thanks,
>>
>> -Sundar
>>
>
Re: RFR 8163952: jlink exclude VM plugin does not support static libraries
Yep, my mistake - Sorry! Thanks for the catch. Will file a bug.
PS. I suspect test ran -- but jlink missed removing those .a static
libraries!
Thanks
-Sundar
On 9/6/2016 8:25 PM, Jim Laskey (Oracle) wrote:
> I missed that as well. Good catch.
>
>
>> On Sep 6, 2016, at 11:50 AM, Anthony Vanelverdinghe
>> wrote:
>>
>> Hi Sundar
>>
>> I'm not familiar with the code, but the for-loop at lines 105-107 looks like
>> a bug, since only the first element is considered:
>>
>> 105 for (String jvmlib : jvmlibs) {
>> 106 return t.path().endsWith("/" + jvmlib);
>> 107 }
>>
>> Kind regards,
>> Anthony
>>
>>
>> On 6/09/2016 12:12, Sundararajan Athijegannathan wrote:
>>> Please review http://cr.openjdk.java.net/~sundar/8163952/webrev.01/ for
>>> https://bugs.openjdk.java.net/browse/JDK-8163952
>>>
>>> Thanks,
>>>
>>> -Sundar
>>>
Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes
(Finally getting back to this thread, now that vacation season is over.)
2016/7/21 10:01:11 -0700, jason.gre...@redhat.com:
> On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote:
>> 2016/7/13 20:27:45 -0700, jason.gre...@redhat.com:
>>> ...
>>>
>>> Sorry for the confusion, what I was trying to say on this point was a bit
>>> different. What I was trying to say was:
>>>
>>> (2') It weakens encapsulation by forcing the introduction of exports
>>> introducing potential conflicts that break applications.
>>>
>>> As an example, assume I have three modules with classloader-per-module
>>> isolation (A, B, and Victim)
>>>
>>> - A exports foo, and has a non-exported package “bar"
>>>
>>> - B exports bar
>>>
>>> - Victim has a module-info with requires A; requires B
>>>
>>> Now A decides to use IoC on some of its classes in bar, so it’s
>>> definition is changed to:
>>>
>>> { exports foo; exports dynamic bar; }
>>>
>>> Since exports dynamic is internally a normal export at runtime, module
>>> resolution fails when loading Victim, because its now including a
>>> duplicate package, even though A had no intention of publishing its
>>> internal bar package for linkage.
>>
>> Got it. Thanks for clarifying this -- I agree that it's a problem.
>>
>> Fortunately I think we can address it simply by revising the semantics of
>> `exports dynamic p` to omit the package-conflict constraint. This would
>> allow split packages to occur more readily at run time, though still
>> really only in fairly obscure situations involving poorly-written class
>> loaders.
>
> That would help, but there is also class visibility issues that would
> need to be addressed as well.
>
> Example 1 (Ambiguous class names):
>
> Both A and B export “bar”, and both define “bar.MyClass” which have
> differing definitions. Victim could load the supposed to be hidden A’s
> MyClass instead of the intended B’s MyClass.
>
> There is also a variant of this where the conflict is between Victim
> and A if A also exports another hidden package that is present in
> Victim itself.
Alan addressed this in a nearby message.
A high-level point worth emphasizing here is that visibility issues are
class-loader issues, and Jigsaw (for the most part) does not dictate how
custom class loaders should work. It's a good idea for class loaders to
respect the readability relationships set up by the module system, but if
they don't then there's nothing that the module system can really do
about it.
> Example 2 (Unintentional discovery):
>
> Victim uses ClassLoader.getResources (plural), looking for a standard
> configuration file or class name, and receives entries for both A and
> B. A’s was not intended to be discovered by victim, and leads to a
> failure state. As an example perhaps the configuration file in B
> specifies a class name in B’s dependency, which is not visible to
> Victim. Or, perhaps A’s config leads to duplicate runtime actions being
> configured (since the file was really only indented for A, which also
> processes it)
... which you later amended:
> Sorry for the confusion, this should read:
>
> " As an example perhaps the configuration file in [A] specifies a class
> name in [A]’s dependency, which is not visible to Victim. Or, perhaps A’s
> config leads to duplicate runtime actions being configured (since the
> file was really only indented for A, which also processes it)"
Alan also addressed this, in a couple of different nearby messages.
Again, what the class loaders do in this example is not really up to the
module system. This example can, however, be seen as an argument in
favor of #ResourceEncapsulation, as Alan noted. If module A contains a
resource that's strictly internal to A, and if the module system gives
the author of A a way to encapsulate such resources, then the module
system could help out in this case by refusing to locate that resource.
(Resource location is one way in which Jigsaw may well change how all
class loaders work.)
> You can potentially address 1 with precedence, but not 2.
>
> I think you would need to say that export dynamic is only utilizable
> for reflection permissions and has no other similarity with “export”
> (although perhaps that’s what you meant?)
No, that's not what I meant. `exports dynamic` allows static (i.e.,
bytecode) references too; it just doesn't allow compile-time access.
Anyway, this isn't an accessibility issue, as noted.
> If you combine that approach with a wildcard capability like you
> mentioned earlier then I’ll admit its very hard for me to quibble over
> a one line additional requirement in module-info.java.
Glad to hear it.
> Although, for completeness, let me (re?)introduce one other
> consideration that was briefly mentioned (although with sparing
> details) earlier in the thread
>
> If you have a custom serialization framework that is supposed to be
> identical to Java serialization in contract, then it becomes impossible
> to mirror using the only a
Fw: Any word on the updated spec
Re: problem with Class#getResource
On 05.09.2016 17:00, Alan Bateman wrote: On 05/09/2016 15:50, Jochen Theodorou wrote: getResource did not get caller sensitive, right? The Class getResource/getResourceAsStream methods are but this is only relevant if you are invoke them on classes in named modules. This is why I was asking what "this.class" was in the previous mail. ok, turns out getResource is doing the right thing for me actually. The error was instead in the JVM forking code deeper down, that just surfaced strangely. Sorry for the false alarm bye Jochen
Upgradeable Modules Question
Hi Jigsaw team, Can Jigsaw module be both upgreadeable and automatic? Thanks, Richard
Re: Upgradeable Modules Question
On 9/6/2016 3:31 PM, Richard Opalka wrote: Can Jigsaw module be both upgreadeable and automatic? No. By definition, an upgradeable module is a module linked into a runtime image. An automatic module is not linked into a runtime image. Alex
Can jdeps resolve unnecessary dependencies?
So jdeps can recursively identify all dependencies given a list of the jars that my application is made of. Assume my main application jar is app.jar and it depends (per gradle or maven dependencies resolution) on following libraries like so: app.jar > a.jar, b.jar a.jar --> x.jar, y.jar, z.jar x.jar -> profile1 y.jar -> profile2 z.jar -> profile3 And now assume that the app.jar in reality depends only on the part of a.jar that depends only on x.jar. In other words in reality statically (no reflection) my application does not really depend on y.jar and z.jar and only needs compact1 to execute properly. There are libraries that are "well focused" and have very few dependencies and there are those that pull ton of dependencies even though an application may only be using 5% of it. Would jdeps show only real or all dependencies in this case? If latter would it show enough information that can be analyzed to determine that y.jar and z.jar are not really needed and can be removed from my deployment? Would Java 9 jdeps work differently in this case? Would jlink be able to figure the "real" dependencies and only pull really needed JRE modules into the output image? Waldek
Re: Can jdeps resolve unnecessary dependencies?
> On Sep 6, 2016, at 6:07 PM, Waldek Kozaczuk wrote: > > So jdeps can recursively identify all dependencies given a list of the > jars that my application is made of. Assume my main application jar is > app.jar and it depends (per gradle or maven dependencies resolution) on > following libraries like so: > > app.jar > a.jar, b.jar > a.jar --> x.jar, y.jar, z.jar > x.jar -> profile1 > y.jar -> profile2 > z.jar -> profile3 > > And now assume that the app.jar in reality depends only on the part of > a.jar that depends only on x.jar. In other words in reality statically > (no reflection) my application does not really depend on y.jar and z.jar > and only needs compact1 to execute properly. There are libraries that > are "well focused" and have very few dependencies and there are those > that pull ton of dependencies even though an application may only be > using 5% of it. > > Would jdeps show only real or all dependencies in this case? If latter > would it show enough information that can be analyzed to determine that > y.jar and z.jar are not really needed and can be removed from my deployment? > $ jdeps -R -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar This will recursively analyze the run-time view of the dependencies from app.jar. The -s option shows the summary and doesn’t list the package-level dependencies. It will start with all types in app.jar and then transitively analyze the referenced classes. y.jar and z.jar will not be shown in the output if no type from those jar files are used at runtime. $ jdeps —-compile-time -s -cp a.jar:b.jar:x.jar:y.jar:z.jar app.jar This will recursively analyze the compile-time view from app.jar. It will start with app.jar and then recursively analyze the JAR files containing its referenced types. In other words, it will show the dependenencies as the example above. > Would Java 9 jdeps work differently in this case? jdeps -—compile-time option is a new option added in jdk9 jdeps. > Would jlink be able to > figure the "real" dependencies and only pull really needed JRE modules > into the output image? jlink will do the resolution per the specified root set and determine the resulting modules to be linked in to the output image. The dependences are declared in the module descriptors. You can refer the details in JEP 261 [1] and JEP 282 [2] Mandy [1] http://openjdk.java.net/jeps/261 [2] http://openjdk.java.net/jeps/282
Re: Upgradeable Modules Question
On 06/09/2016 23:37, Alex Buckley wrote: On 9/6/2016 3:31 PM, Richard Opalka wrote: Can Jigsaw module be both upgreadeable and automatic? No. By definition, an upgradeable module is a module linked into a runtime image. An automatic module is not linked into a runtime image. Maybe the question is asking if it's possible to deploy an automatic module on the upgrade module path to upgrade a module in the runtime image? That is possible of course (and necessary in the case of the java.transaction module because the EE version has dependences that aren't modules yet). -Alan
