On 10/18/17 2:29 AM, Erik Joelsson wrote:
New webrev again: http://cr.openjdk.java.net/~erikj/8189094/webrev.03/
Looks fine to me.
Thanks
Mandy
On 2017-10-18 11:29, Erik Joelsson wrote:
New webrev again: http://cr.openjdk.java.net/~erikj/8189094/webrev.03/
Looks good to me!
/Magnus
Removed the ToolProvider patching.
Changed build/tools/symbolgenerator/TransitiveDependencies.java to use
JavacTool directly.
Changed Gendata-jdk.com
New webrev again: http://cr.openjdk.java.net/~erikj/8189094/webrev.03/
Removed the ToolProvider patching.
Changed build/tools/symbolgenerator/TransitiveDependencies.java to use
JavacTool directly.
Changed Gendata-jdk.compiler.gmk to just use INTERIM_LANGTOOLS_ARGS
instead of listing a separa
On 2017-10-17 15:59, Erik Joelsson wrote:
New webrev:
On 2017-10-17 13:10, Magnus Ihse Bursie wrote:
This is a quite complex change. It's a bit unfortunate that we have
to make these kinds of changes to use JDK 9 as a boot JDK. Anyway,
that's the way it is.
A couple of remarks:
* In boo
Actual link: http://cr.openjdk.java.net/~erikj/8189094/webrev.02/
On 2017-10-17 15:59, Erik Joelsson wrote:
New webrev:
On 2017-10-17 13:10, Magnus Ihse Bursie wrote:
This is a quite complex change. It's a bit unfortunate that we have
to make these kinds of changes to use JDK 9 as a boot J
Hello,
On 2017-10-17 19:54, mandy chung wrote:
On 10/17/17 10:44 AM, Jan Lahoda wrote:
The problematic part is TransitiveDependencies, right?
Might be easier to replace:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
with:
JavaCompiler compiler = JavacTool.create();
(import co
Hello Martin,
On 2017-10-17 19:54, Martin Buchholz wrote:
Does $(INTERIM_LANGTOOLS_MODULES_COMMA) need to be repeated below? I
would think you could drop it from --limit-modules
+INTERIM_LANGTOOLS_ARGS := \
+--limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
+--a
On 17/10/2017 20:20, Martin Buchholz wrote:
:
Wow, --limit-modules sure is a good trick. So now we have two
possible replacements for the demise of -Xbootclasspath/p:
--patch-module
--limit-modules combined with renamed replacement modules
The trick works for the unique scenario of bootstrapp
On 10/17/17 12:20 PM, Martin Buchholz wrote:
On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman
wrote:
On 17/10/2017 17:53, Martin Buchholz wrote:
I tried to figure out how this patch actually works. At first I thought
we were "shading" (renaming all the packages in the source files) but now I
On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman
wrote:
> On 17/10/2017 17:53, Martin Buchholz wrote:
>
> I tried to figure out how this patch actually works. At first I thought
> we were "shading" (renaming all the packages in the source files) but now I
> think we're merely renaming the modules
Does $(INTERIM_LANGTOOLS_MODULES_COMMA) need to be repeated below? I would
think you could drop it from --limit-modules
+INTERIM_LANGTOOLS_ARGS := \
+--limit-modules java.base,jdk.zipfs,$(INTERIM_LANGTOOLS_MODULES_COMMA) \
+--add-modules $(INTERIM_LANGTOOLS_MODULES_COMMA) \
On 10/17/17 10:44 AM, Jan Lahoda wrote:
The problematic part is TransitiveDependencies, right?
Might be easier to replace:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
with:
JavaCompiler compiler = JavacTool.create();
(import com.sun.tools.javac.api.JavacTool;)
That should avo
The problematic part is TransitiveDependencies, right?
Might be easier to replace:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
with:
JavaCompiler compiler = JavacTool.create();
(import com.sun.tools.javac.api.JavacTool;)
That should avoid the ServiceLoader lookup.
Jan
On 17.
On 17/10/2017 17:53, Martin Buchholz wrote:
I tried to figure out how this patch actually works. At first I
thought we were "shading" (renaming all the packages in the source
files) but now I think we're merely renaming the modules by appending
".interim" to the names. But that looks like che
It'd be simpler if we could avoid patching ToolProvider. The ctsym
generator is a build tool. Jan and Jon may have suggestion if the build
tool can find the compiler from the interim module instead and use
--limit-modules to java.base?
Mandy
On 10/17/17 8:55 AM, Erik Joelsson wrote:
The
I tried to figure out how this patch actually works. At first I thought we
were "shading" (renaming all the packages in the source files) but now I
think we're merely renaming the modules by appending ".interim" to the
names. But that looks like cheating to me - we're not allowed to have
multiple
1.
The upgrade module path. This path contains compiled definitions of
modules that will be observed in preference to the compiled definitions of
any *upgradeable modules* that are present in (3) and (4). See the Java
SE Platform for the designation of which standard modules are upg
The ctsym generator in Gendata-jdk.compiler.gmk looks up the tool using
the ToolProvider. That part of the change was just a reaction to ctsym
generation failing.
/Erik
On 2017-10-17 17:47, mandy chung wrote:
Hi Erik,
On 10/16/17 6:12 AM, Erik Joelsson wrote:
To generate the new modules,
Hi Erik,
On 10/16/17 6:12 AM, Erik Joelsson wrote:
To generate the new modules, I copy the module-info.java files to a
new gensrc dir and sed replace the module names. I also generate a new
ToolProvider.java so that the default tools are taken from the interim
modules.
:
Webrev: http://cr
New webrev:
On 2017-10-17 13:10, Magnus Ihse Bursie wrote:
This is a quite complex change. It's a bit unfortunate that we have to
make these kinds of changes to use JDK 9 as a boot JDK. Anyway, that's
the way it is.
A couple of remarks:
* In boot-jdk.m4, please update the comment as well:
On 2017-10-16 15:12, Erik Joelsson wrote:
With JDK 9 released, it's high time to change the required boot jdk
for building JDK 10. This time, the change wasn't as straight forward
as it usually is.
It's currently possible to use any of JDK 8, 9 or a recent build of 10
to boot the JDK 10 build
On 16/10/2017 19:53, Martin Buchholz wrote:
What's the canonical way to list all upgradeable modules?
There's a list in JEP 261, but naturally we can't consider it
authoritative.
make/common/Modules.gmk has the list (look for UPGRADEABLE_MODULES and
UPGRADEABLE_TOOL_MODULES).
I was surprise
On 10/16/17 11:53 AM, Martin Buchholz wrote:
What's the canonical way to list all upgradeable modules?
There's a list in JEP 261, but naturally we can't consider it authoritative.
I was surprised that even java --describe-module doesn't tell me whether a
module is upgradeable.
I was surprised t
What's the canonical way to list all upgradeable modules?
There's a list in JEP 261, but naturally we can't consider it authoritative.
I was surprised that even java --describe-module doesn't tell me whether a
module is upgradeable.
I was surprised to see JEP 261 say that java.compiler is upgrade
Obviously y'all have the engineering resources to do any shoe-horning
necessary to get jdk9 to run jdk10 langtools. But consider that this is
the sort of thing users will be doing as well. It seems very natural to
decouple langtools from its host jdk; at Google we often run langtools
hosted in th
On 16/10/2017 16:41, Martin Buchholz wrote:
The difficulties encountered trying to run langtools10 in a jdk9 suggests
that the jdk9 module model is too restrictive. I've long lobbied for
treating langtools as just another collection of ordinary programs that
happen to be written in java and shou
The difficulties encountered trying to run langtools10 in a jdk9 suggests
that the jdk9 module model is too restrictive. I've long lobbied for
treating langtools as just another collection of ordinary programs that
happen to be written in java and should not need special support from the
host jdk.
With JDK 9 released, it's high time to change the required boot jdk for
building JDK 10. This time, the change wasn't as straight forward as it
usually is.
It's currently possible to use any of JDK 8, 9 or a recent build of 10
to boot the JDK 10 build. This support is however fragile. The most
28 matches
Mail list logo
