Hi all,
In #AddExportsInManifest two new manifest entries are proposed. I can only find
the following email containing more details:
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-September/000547.html
<http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-Septem
On 11/05/2017 07:22, Paul Bakker wrote:
Hi all,
In #AddExportsInManifest two new manifest entries are proposed. I can only find the
following email containing more details:
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-September/000547.html
<http://mail.openjdk.java.
t;
> On 11/05/2017 07:22, Paul Bakker wrote:
>
>> Hi all,
>>
>> In #AddExportsInManifest two new manifest entries are proposed. I can only
>> find the following email containing more details:
>> http://mail.openjdk.java.net/pipermail/jpms-spec-obs
On 11/05/2017 07:51, Paul Bakker wrote:
Hi Alan,
What is the reason only exports/opens to unnamed are possible?
Also, are these implemented in the current jigsaw prototype? I'm having trouble
getting it to work, but that might be entirely my own doing...
The attributes are defined for the mai
I'm a little confused by "...deployments work if they are dependent on JDK
internal APIs". What does internal JDK usage have to do with opening/exporting
your own packages? I would think this solves the problem that some other code
(e.g. a library) requires access to application code?
Also, can
These two attributes are defined to ease migration so that executable JARs can
run with java -jar command, as is today, to avoid adding command-line options
to break into encapsulation.
Mandy
[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest
> On May 11, 2017, a
On 11/05/2017 21:25, Paul Bakker wrote:
I'm a little confused by "...deployments work if they are dependent on JDK internal
APIs". What does internal JDK usage have to do with opening/exporting your own
packages? I would think this solves the problem that some other code (e.g. a library)
requ
Got it! It makes sense after this example. As a bit of feedback: I do think the
naming of the properties is confusing. Because they are the same as the
--add-opens/--add-exports flags, my assumption was they would work (exactly)
the same.
Naming things is hard, and I don't have a better alternat
This seems reasonable.
Stephen
On 12 September 2016 at 16:09, Mark Reinhold wrote:
> Issue summary
> -
>
> #AddExportsInManifest -- Using a command-line option such as
> `--add-exports` to make JDK-internal APIs available to existing code is
> difficult, if n
Hi Jigsaw Team,
#AddExportsInManifest is good proposal for "uber" jars.
How about extending this proposal to cover:
--upgrade-module-path
--module-path
--add-modules
--limit-modules
options too?
Both Module-Path and Upgrade-Module-Path manifest entries
would be relative t
10 matches
Mail list logo
