Hi Paul,
Even if there were any resource visibility controls implemented at the
module level, I would expect automatic modules to make all resources
visible, just like they export all packages. So no changes to automatic
modules behavior.
Regards,
Peter
On Aug 14, 2016 23:05, "Paul Bakker" wro
I have been testing migrations of "typical" applications (e.g.
Spring/Hibernate) using Automatic Modules. The application code is migrated to
modules, while libraries are used as Automatic Modules.
The dropped resource constraints make a huge difference. With a JDK build that
still has the resou
>From Spring's side, dropping resource encapsulation would be the easiest
way out. That said, I can imagine some middle ground as well since we
effectively only need access to META-INF resources.
For a recent example, https://jira.spring.io/browse/SPR-14579 is about
finding schema declarations beh
On 05/07/16 09:34, Alan Bateman wrote:
> Just to expand on this. Java agents that are deployed via the -javaagent
> command line option, or loaded into a running VM by means of the Attach
> API, have their types loaded by the application class loader. Some
> agents will also add to the boot class l
- Mail original -
> De: "Andrew Dinn"
> À: "Remi Forax"
> Cc: "mark reinhold" , jigsaw-dev@openjdk.java.net,
> jpms-spec-comme...@openjdk.java.net
> Envoyé: Mardi 5 Juillet 2016 11:18:04
> Objet: Re: Proposals for some open JPMS iss
Hi Remi,
On 05/07/16 00:00, Remi Forax wrote:
> Hi Andrew, for me it's another issue,
> currently you can not use a modular jar with the -javaagent on the command
> line,
> it's seems to be the root cause of your issue.
Yes, that's basically it. Although, I'll admit I'm not really keen on
making
On 04/07/2016 13:26, Andrew Dinn wrote:
:
As I understand the current situation (after conversations with Alan
Bateman) all agent classes loaded from an agent jar -- whether the agent
is deployed on the command line or dynamically, using the VM_Attach API
-- will belong to the unnamed module _M.
- Mail original -
> De: "Andrew Dinn"
> À: "mark reinhold" , jigsaw-dev@openjdk.java.net,
> jpms-spec-comme...@openjdk.java.net
> Envoyé: Lundi 4 Juillet 2016 14:26:34
> Objet: Re: Proposals for some open JPMS issues,
> #ReflectiveAccessBy
On 28/06/16 22:47, mark.reinh...@oracle.com wrote:
> FYI, I've just posted proposals for some of the open issues in the
> draft JPMS specification, including:
> . . .
> #ReflectiveAccessByInstrumentationAgents
> . . .
I am not sure the proposed solution is going to work for my agent and it
m
On 06/30/2016 06:13 AM, Peter Levart wrote:
Hi,
The proposal for #ResourceEncapsulation plans to drop the
resource-encapsulation requirement. Have you thought about a "middle
ground" ?
I went into a lot of detail on this topic last year [1] but nothing much
came of it. I do agree that it wou
Hi,
The proposal for #ResourceEncapsulation plans to drop the
resource-encapsulation requirement. Have you thought about a "middle
ground" ?
Possibility 1: resources in a module could be divided in two groups:
always accessible: resources in "root" package and special
directories such as
FYI, I've just posted proposals for some of the open issues in the
draft JPMS specification, including:
#CompileTimeDependences
#ReflectiveAccessToNonExportedTypes
#ModuleAnnotations and #ModuleDeprecation
#ResourceEncapsulation and #ClassFilesAsResources
#ReflectiveAccessByInstrumentati
12 matches
Mail list logo
