Please review this simple fix for two related aspects of the same problem:
Export the "standard doclet" used by javadoc, such that it is possible
to derive alternative doclets, either by delegation or subtyping.
In JDK 9, javadoc has a "new" standard doclet (JEP 221), but the old one
remains
Since you have already admitted to using multiple concatenated lower
case words in unexportedinapi, and since "unexported" is not a real
word, can I suggest notexportedinapi for the category, and
NOT_EXPORTED_IN_API for the Lint category. Or else just simply all the
was down to "exports" and
The test can also report which providers it is testing and/or skipping,
so that anyone checking the .jtr file can verify the behavior.
Maybe it fails if expected modules or providers are not found.
-- Jon
On 06/29/2016 10:50 AM, Mandy Chung wrote:
Valerie’s suggestion is a good one. The tes
Noted. Thanks for the report.
-- Jon
On 07/11/2016 12:24 PM, Paul Benedict wrote:
Error from the command line:
src\com.domain2\module-info.java:2: error: module not found: com.domain1
requires com.domain1;
^
If you can't see this message in fixed-width font, please note
Changeset: f5581208bbd2
Author:jjg
Date: 2016-07-12 13:51 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f5581208bbd2
update options for javac, javadoc
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.javadoc/share/classes/com/sun/too
Changeset: f4927f52aa7b
Author:bpatel
Date: 2016-07-05 13:30 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f4927f52aa7b
8157987: overview-summary.html generated by javadoc should include module
information
Reviewed-by: jjg, ksrini
!
src/jdk.javadoc/share/classes
Changeset: b7ce08828bfc
Author:jjg
Date: 2016-07-14 15:28 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b7ce08828bfc
update javadoc usage messages for --release
!
src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties
!
src/jdk.javadoc/
Changeset: 4b0b87edac75
Author:jjg
Date: 2016-07-22 14:14 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4b0b87edac75
update and standardize javap output for Module attribute
! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
SOURCE_PATH is normally a package-oriented (JDK-8 style) path. It's not
a module-oriented path, so generally, you won't find modules on it.
You probably want to use MODULE_SOURCE_PATH.
-- Jon
On 07/26/2016 06:59 AM, Konstantin Barzilovich wrote:
Hello,
I try to use method getModuleLocatio
Changeset: 559e85570040
Author:jjg
Date: 2016-07-26 17:54 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/559e85570040
8160489: Multiple -Xpatch lines ignored by javac
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/
If your module is in source form, then you have two choices:
1. put the contents of the module directly on the SOURCE_PATH, as a
hierarchy of packages and types, with module-info.java in the root of
that hierarchy. by contrast with using MODULE_SOURCE_PATH, (described
next), there should not b
Changeset: eff836b97514
Author:anazarov
Date: 2016-07-27 15:14 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eff836b97514
8161906: Develop tests for "requires static" feature
! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
! test/tools/javac/classf
Changeset: 9f8da995da88
Author:vromero
Date: 2016-07-19 11:27 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9f8da995da88
8161383: javac is looking for operator symbols at the wrong place
Reviewed-by: mcimadamore
! src/jdk.compiler/share/classes/com/sun/tools/javac
Changeset: 078fb7cea81c
Author:anazarov
Date: 2016-07-29 19:53 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/078fb7cea81c
8162713: Develop new tests for "export dynamic" feature
! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
! test/tools/javac/cla
On 08/08/2016 03:02 PM, Mandy Chung wrote:
>In javap.properties then there is a typo in "instead whitespace" (missing "of"). Also probably
best to say a "file URL" instead of "URL" as I don't think it accepts an arbitrary URL.
>
Fixed.
Please unfix.
For a couple of releases, javap has acc
On 08/09/2016 06:12 AM, Jan Lahoda wrote:
I took a pass through langtools changes. Overall seems OK to me. Some
minor comments:
-src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java:
commented-out code in hasArg(). (Some more in Option.ArgKind, but that
seems mostly OK.)
-src/jdk
Shura,
Such is the nature of things, I would expect there are some instances of
the old style options inbound from separate changesets under development
or in review. I would expect that we will do a separate additional pass
over tests before we remove support for the old style options.
-- J
Changeset: 8150eeaf8c24
Author:vromero
Date: 2016-07-27 07:07 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8150eeaf8c24
8161277: javax.lang.model.util.Types.isSameType(...) returns true on wildcards
Reviewed-by: mcimadamore
! src/jdk.compiler/share/classes/com/su
On 08/18/2016 05:17 AM, Alan Bateman wrote:
On 11/08/2016 05:50, Jayaprakash Arthanareeswaran wrote:
Hi Alan,
I also need a clarification on the following passage in JEP 261:
/"In large systems the source code for a particular module may be
spread across several different directories. In the J
Changeset: 0f8b6aba6279
Author:ksrini
Date: 2016-08-09 07:31 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0f8b6aba6279
8075529: Documentation in DocumentationTool.getTask(...) should mention about
"null" parameter for doclet.
Reviewed-by: jjg
! src/java.compiler
David,
Are you being affected by javac's long-standing policy of implicit
compilation?
If ListShim.java references other classes, and those classes either only
exist on the module source path, or are newer on the module source path,
then they will be compiled into the output directory as wel
Looks good to me.
-- Jon
On 08/26/2016 04:06 PM, Mandy Chung wrote:
This patch removes the old module options from java, javac, javadoc, etc. The
new options are in jdk-9+132 [1]. I did a scan on the jdk9/dev forest to
replace any remaining reference to the old options. I find some tests i
On 09/20/2016 07:49 AM, Alan Bateman wrote:
On 20/09/2016 06:43, Stephen Colebourne wrote:
Just to note that the report below is mostly about the confusing error
message, something which users will get if they write "wek" instead of
"weak".
Understood, I'm sure Jon or Jan will comment on tha
If the annotation processor is trying to execute code in that module,
you may want -J--add-modules=java.xml.bind to add the module to the
javac runtime environment, as compared to the compilation environment
-- Jon
On 10/4/16 11:48 AM, Stephen Felts wrote:
In JDK9, the java.xml.bind module i
Langtools change looks good,
-- Jon
On 09/30/2016 09:29 PM, Mandy Chung wrote:
Jon points out that javac should also be updated. javac currently opens the
JMOD file with JarFileSystem. Jon and I discussed this and we agree to keep
the current workaround for now and add the validation to det
Changeset: 9d791b717b5c
Author:jjg
Date: 2016-10-19 13:58 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9d791b717b5c
fix 'requires public' in diagnostic to 'requires transitive'
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
!
src/jdk.compil
Currently, the compiler expects sources on a source path (i.e.
--source-path) to be organized in a specific hierarchy corresponding to
packages and classes. For the module source path, this is extended to
include the enclosing module. Although we experimented with requiring
the module direct
Changeset: 0a91e3198c97
Author:jlahoda
Date: 2016-10-18 16:00 +0200
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0a91e3198c97
8167461: jshell tool: Scanner#next() hangs tool
Summary: PipeInputStream.read(byte[]...) should only read available bytes;
properly resending e
Changeset: 2fb22956b1d1
Author:jjg
Date: 2016-10-31 15:22 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2fb22956b1d1
update javac tests
+
test/tools/javac/diags/examples/HasBeenDeprecatedRemovalModule/HasBeenDeprecatedRemovalModule.java
+
test/tools/javac/diags/
Changeset: 9fcb953ee79d
Author:jjg
Date: 2016-10-31 15:59 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9fcb953ee79d
basic support for new provides table in Module attribute
! src/java.base/share/classes/java/lang/module/ModuleInfo.java
! src/java.base/share/classes/jdk
Changeset: 08e003561fba
Author:jjg
Date: 2016-10-31 16:00 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/08e003561fba
initial support for new provides syntax and provides table in Module attribute
! src/java.compiler/share/classes/javax/lang/model/element/ModuleEle
Changeset: 74b4b6a2ae2b
Author:jjg
Date: 2016-10-31 16:50 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/74b4b6a2ae2b
fix test for provides table
! test/tools/javac/classfiles/attributes/Module/ModuleTest.java
! test/tools/javac/classfiles/attributes/Module/ModuleT
Remi,
Your command line is questionable for putting output/modules on both -d
and --module-path. You don't need it on --module-path. When compiling
modules, javac will automatically look in the output directory for
classes for the module(s) being compiled.
Does your module source path cont
On 11/02/2016 09:49 AM, Remi Forax wrote:
I agree that if there is a folder java.base in the module-source-path, it
should be used but this is not the case.
Here, i want to add files to an existing modules (java.base) and those files
are in output/classes not in src.
You currently can't add
A variant of this problem is under consideration, which may address your
use case.
In the meantime, the workaround is to make sure there is no evidence of
java.base on the module source path.
-- Jon
On 11/02/2016 10:11 AM, Remi Forax wrote:
I agree with that, but that's not my use case.
I w
Changeset: 6f99c4e110f1
Author:jjg
Date: 2016-11-02 11:20 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6f99c4e110f1
add no-op --add-opens option to javac
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com
Changeset: 1bb329a71382
Author:jjg
Date: 2016-11-02 13:04 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1bb329a71382
fix tests that use normal and deep reflective access
! test/tools/javac/6304921/TestLog.java
! test/tools/javac/modules/PatchModulesTest.java
! tes
Changeset: 8154a3ab3a1f
Author:jjg
Date: 2016-11-02 14:49 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8154a3ab3a1f
fix remaining uses of :private
! test/jdk/jshell/CompletionSuggestionTest.java
! test/jdk/jshell/ComputeFQNsTest.java
! test/jdk/jshell/PipeInputSt
Changeset: 3286b60836a5
Author:jjg
Date: 2016-11-03 13:35 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3286b60836a5
temporary fix to merge multiple provides for a service
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
Changeset: 03cece
Changeset: 2b552c8cff2b
Author:jjg
Date: 2016-11-03 18:32 -0700
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2b552c8cff2b
javadoc should change "requires public" to "requires transitive"
! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/package-info.java
! src/jdk.jav
Changeset: d3dde3f775b8
Author:jlahoda
Date: 2016-11-02 16:48 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d3dde3f775b8
8166538: Improve error reporting for compiling against unexported package
Summary: When a type cannot be found, look into other modules, search
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires', etc are lexed as identifiers. When we
get to the point where the grammar would accept one of these words as a
ke
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first
alternative.
- If you don't lex 'package', but rather lex 'import', then parsing
is ambiguous until you've looked ahead to lex either '
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
On 11/16/2016 11:01 PM, Jonathan Gibbons wrote:
On 11/16/2016 01:41 PM, Stephan Herrmann wrote:
At the end of the day we need full pattern matching right?
Not really, at least, not in javac.
Words like 'module', 'requires&
On 11/16/2016 02:34 PM, Stephan Herrmann wrote:
On 11/16/2016 11:19 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:08 PM, Stephan Herrmann wrote:
On 11/16/2016 10:02 PM, Alex Buckley wrote:
- If you lex 'package', then the sequence must parse as the first
alternative.
- If you
On 11/16/2016 02:55 PM, Stephan Herrmann wrote:
On 11/16/2016 11:35 PM, Jonathan Gibbons wrote:
On 11/16/2016 02:26 PM, Stephan Herrmann wrote:
Still no good news for tools wishing to process just a fragment of
the text.
Just how small a fragment, and in how unknown a context are you
On 11/16/2016 03:28 PM, Stephan Herrmann wrote:
On 11/17/2016 12:10 AM, Alex Buckley wrote:
On 11/16/2016 3:03 PM, Stephan Herrmann wrote:
On 11/16/2016 11:57 PM, Alex Buckley wrote:
On 11/16/2016 2:26 PM, Stephan Herrmann wrote:
And we may safely assume regularity of the grammar, i.e.,
the
Changeset: b8086bb7db9a
Author:jjg
Date: 2016-11-17 14:34 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b8086bb7db9a
Fix spurious error caused by @deprecated tag on module comment
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
Changeset: b98dda53ad13
Author:jjg
Date: 2016-11-17 21:33 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b98dda53ad13
fix issues with deprecation on modules
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/su
On 11/20/16 3:39 PM, Eirik Bjørsnøs wrote:
Turns out that:
a) Maven treats -J arguments in a special way which hides them from the
debug log, but they're still passed on to javac
b) Maven parses the javac output for error messages, but drops any output
not following the javac output format.
S
Changeset: ecda27ca1011
Author:jjg
Date: 2016-11-22 17:49 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ecda27ca1011
fix 2 failing tests after Module attribute changes
! test/tools/javac/classfiles/attributes/Module/ModuleTestBase.java
! test/tools/javac/modules/O
Changeset: ea87091ceefc
Author:jjg
Date: 2016-11-22 18:18 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ea87091ceefc
remove support for old-style Module attribute
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.jdeps/share/class
Changeset: 51f0bf95d616
Author:jjg
Date: 2016-11-22 18:42 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/51f0bf95d616
Add classfile Module_attribute.OPensEntry
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/jdk.jdeps/share/classes/com/
Changeset: 98a2842ec26a
Author:bpatel
Date: 2016-11-23 14:01 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/98a2842ec26a
8168766: javadoc should support deprecation on modules.
Reviewed-by: jjg
!
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/h
Changeset: 1dcda080bb13
Author:jjg
Date: 2016-11-23 14:15 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1dcda080bb13
remove interim/compatbility support for 'requires public'
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
Changeset: 7678462efbc3
Author:bpatel
Date: 2016-11-23 15:29 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7678462efbc3
8159607: Update javadoc to support annotations on module-info.java
Reviewed-by: jjg
! test/jdk/javadoc/doclet/testModules/TestModules.java
! tes
Stéphan,
You say you are using com.sun.tools.javac.api.JavacTrees. Although that
class is not exported from jdk.compiler, it is an implementation of the
interface com.sun.source.util.Trees, which is exported. Is the
interface sufficient to your needs? If not, what methods are you calling?
-
On 11/28/16 3:28 AM, Maurizio Cimadamore wrote:
Hi,
the langtools code looks generally ok. Few questions:
* Why doesn't 'open' get its own directive in Directive.java - instead
of relying on a 'mode' set on an export directive?
I agree that "opens" leveraging a type named "Exports..." is
par
Changeset: 55e9018d9f89
Author:jjg
Date: 2016-11-29 17:21 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/55e9018d9f89
disentangle exports and opens in javac
! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java
! src/jdk.compiler/share/class
Changeset: c64079dbb1ba
Author:jjg
Date: 2016-11-30 14:46 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c64079dbb1ba
rename test class from Aux to Extra to avoid problems on Windows
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleHelper.java
! test
On 12/04/2016 12:36 AM, Alan Bateman wrote:
On 04/12/2016 00:07, Remi Forax wrote:
Hi all, hi Jon,
while updating ASM6 to the new classfile format, i think i've found a
bug in javap.
javap as no trouble to read module-info.class if the class is
specified directly
$ /usr/jdk/jdk-9-jigsaw/
Changeset: 222acf0cd461
Author:jjg
Date: 2016-12-12 16:41 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/222acf0cd461
fix StackOverflowException handling JCOpens nodes
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
Changeset: 376da2abfeba
Author:jjg
Date: 2016-12-13 12:59 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/376da2abfeba
add filter for opens directives
! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
Changeset: eb2ed1365493
Author:jjg
Date: 2016-12-13 15:14 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eb2ed1365493
disallow -profile with -target 9
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! test/tools/javac/diags/examples/NotInPr
Changeset: 7863fba025ea
Author:jjg
Date: 2016-12-13 19:05 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7863fba025ea
update module names in tests
! test/jdk/javadoc/doclet/testModules/TestModules.java
- test/jdk/javadoc/doclet/testModules/module1/module-info.java
Changeset: 4a200166396d
Author:jjg
Date: 2016-12-13 19:23 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4a200166396d
enable -Xlint:module by default
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
Changeset: 7b6b9fd8d26d
Author:jjg
Date: 2016-12-14 13:22 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7b6b9fd8d26d
Add javap support for ModuleResolution attribute
! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java
! src/jdk.jdeps/share/classes
Changeset: 334e62436026
Author:jjg
Date: 2016-12-14 14:18 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/334e62436026
fix javac command line help for --module-version
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
Changeset: 63af48cfc1c9
Author:jjg
Date: 2016-12-14 17:05 -0800
URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/63af48cfc1c9
Add support for reading module resolution flags
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/clas
leSourcePathLocationHandler) already stores paths for different
modules separately, it seems to be rather easy to expose ability to specify
module-source-path on per-module basis to StandardJavaFileManager's API.
The change in API suggested by Jonathan Gibbons (see this post
<http://mail.op
an be used to
specify paths for all modules at once if they follow the same naming
scheme, and 'setLocationForModule' can be used if locations of modules
don't follow any common scheme.
On Fri, Dec 16, 2016 at 5:50 PM, Jonathan Gibbons
mailto:jonathan.gibb...@oracle.com>>
Looks OK to me.
-- Jon
On 12/19/2016 02:41 PM, Mandy Chung wrote:
tools/launcher/modules/patch/systemmodules/PatchSystemModules.java needs to be
updated since ModuleBootstrap now depends on this new method:
diff --git
a/test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/inter
Thank you for the report. It is obviously intended that these options
should simply be aliases for each other, but I will see if there is
something else going on to explain what you are seeing.
-- Jon
On 1/5/17 3:23 AM, Nicolai Parlog wrote:
Hi,
during experimentation I encountered compil
implemented within the native javac
launcher, and not in the mainstream javac code. And yes, in the code
in question, --class-path is not supported, and probably should be.
Filed: https://bugs.openjdk.java.net/browse/JDK-8172309
-- Jon
On 01/05/2017 08:33 AM, Jonathan Gibbons wrote:
Thank
Hi Rémi,
On 1/21/17 1:22 AM, Remi Forax wrote:
For the JDK, there are several kind of modules from a doc perspective,
we have root modules that are available by default, like java.base,
we have implementation modules, those that starts with jdk like jdk.jshell,
and we have modules that are not
Stephan, Rémi, et al,
Yes, we need to better document the @SuppressWarnings and lint options
accepted by javac.
At least part of the problem is that we don't have a good place to write
such documentation/specification. We are working on that too.
-- Jon
On 1/22/17 8:21 AM, Stephan Herrmann
ke for Java 9?
best,
Stephan
On 01/22/2017 07:00 PM, Jonathan Gibbons wrote:
Stephan, Rémi, et al,
Yes, we need to better document the @SuppressWarnings and lint
options accepted by javac.
At least part of the problem is that we don't have a good place to
write such documentation/specifi
Nicolai,
I don't think this proposal is a good way to go. If nothing else, it would
require all the module-specific output directories to be created ahead
of time, so that javac can determine which ones to use, which would
require additional setup commands to be executed after a "make clean"
or i
time module path.
-- Jon
so long ... Nicolai
On 23.01.2017 20:51, Jonathan Gibbons wrote:
Nicolai,
I don't think this proposal is a good way to go. If nothing else,
it would require all the module-specific output directories to be
created ahead of time, so that javac can determine
reasons to consider multi-module builds after all?
thanks,
Stephan
On 01/25/2017 07:38 PM, Jonathan Gibbons wrote:
On 1/25/17 12:20 AM, Nicolai Parlog wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Jonathan,
thanks for considering this.
If nothing else, it would require all t
able.
-- Jon
On 25.01.2017 23:50, Jonathan Gibbons wrote:
Stephan,
There will be many cases where one project contains one module and
for those cases, the single module mode compilation will be
sufficient and bears the most similarity to the way people
organize their project today.
At the other end
t would be complementary to -d option. When a module it
not listed in the --module-output, its classes are written to a common
tree specified by -d.
This is just a thought.
Regards, Peter
On 26.01.2017 19:15, Jonathan Gibbons wrote:
On 1/26/17 6:30 AM, Nicolai Parlog wrote:
Hi,
I see t
specified by -d.
This is just a thought.
Regards, Peter
On 26.01.2017 19:15, Jonathan Gibbons wrote:
On 1/26/17 6:30 AM, Nicolai Parlog wrote:
Hi,
I see that this feature is unlikely to be in Java 9 ;) , but I
want to give it one last push before conceding:
Comparing the two ways of comp
Previously, in JDK 8 and before, javac would use the runtime
bootclasspath if there was explicit setting for the compilation
bootclasspath.
Now, in 9, there is no sense of a bootclasspath, since it has been
superseded by modules and the module graph. But even so, it is
reasonable to ask the q
Nicolai,
The simple answer is "Yes, there will be an easy way to generate
documentation based on accessibility",
and "yes, the javadoc tool is module aware".
We've added new options that generalize the existing simple options, so
that you can have detailed
control if you really need it, but t
I see the command line help text has not been updated for the existing
simple options. That is a bug.
-- Jon
On 01/30/2017 04:05 PM, Jonathan Gibbons wrote:
Nicolai,
The simple answer is "Yes, there will be an easy way to generate
documentation based on accessibility",
and
On 01/31/2017 01:45 AM, Andrew Dinn wrote:
Hi Jonathan,
On 31/01/17 00:05, Jonathan Gibbons wrote:
From the command-line help, the relevant new options are the following:
. . .
The good news is that you can use the existing simple options, which are
now
internally defined in terms of those
FWIW, I think javac also deserves some amount of similar work.
-- Jon
On 02/01/2017 01:49 PM, Nicolai Parlog wrote:
Hi Alan,
`-Xdiag:resolver` is awesome! :) I think these messages are great
candidates for info-level messages with the "modules" tag via unified
logging.
Something else I noti
On 2/9/17 3:07 PM, Alex Buckley wrote:
All the JLS wants is for the class to be 'public'.
Alex:
Does that just apply locally to the declaration of the class itself, or
does it also indirectly apply to any enclosing classes, in the case of a
nested class?
-- Jon
Peter,
The circumstances of the analysis of service providers are very
different to the normal JLS rules regarding visibility and accessibility
of named items.
I know that we have some cleanup to do, for javac to "catch up" with the
latest updates to JLS, especially with regards to the diffe
On 03/07/2017 08:06 AM, Doug Simon wrote:
To be able to develop Graal on JDK 9, we're using the `--release 8` javac
option and providing jar files for API that is either not in 9 or is not
exported in 9. Here is a simplified form of a javac command:
javac -cp jdk.internal.vm.ci.jar:jdk.unsup
h
find bin
The last command above should show the extra class files from
jdk.internal.vm.ci.jar in bin.
-Doug
On 7 Mar 2017, at 18:55, Jonathan Gibbons wrote:
On 03/07/2017 08:06 AM, Doug Simon wrote:
To be able to develop Graal on JDK 9, we're using the `--release 8` javac
optio
). Is that somehow
better/cleaner than an empty source path? Of course, since I control creation
of the synthetic jars, I should really just put the sources into a separate zip
(a la src.zip in the jdk).
-Doug
On 9 Mar 2017, at 02:17, Jonathan Gibbons wrote:
Doug,
The jar files in your examp
On 20/03/2017 22:26, Jonathan Gibbons wrote:
If nothing else, the javac error message needs work.
(package org.mockito.stubbing is declared in module , which does not
export it)
The space between "module" and "," means there's an "empty" module
name the
... " fixes the issue, which
doesn't feel correct.
When dependencies are put on the classpath, the import statement is not
required.
Regards,
Pavel
On 20/03/2017 22:26, Jonathan Gibbons wrote:
If nothing else, the javac error message needs work.
(package org.mockito.stubbing is decla
Alan,
langtools changes are OK.
-- Jon
On 03/21/2017 02:42 PM, Alan Bateman wrote:
We have been accumulating changes in the jake forest for the last few
weeks to align with the proposals in JSR 376 and also to pick up API
changes and bug fixes. It's time to bring these changes into jdk9/dev.
I am beginning to consider how to rewrite (micro)resolution in javac in
the light of the recent discussions regarding readability, visibility, etc.
I know that we have determined that the JDK module graph is acyclic. I
think we decided that all module graphs should be acyclic, right?
I gues
Vote: yes
On 08/05/2014 04:13 PM, Mandy Chung wrote:
I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer.
Erik is one of the main contributors to the new build system
in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project.
Erik has already contributed many change sets i
Vote: yes
On 08/05/2014 04:14 PM, Mandy Chung wrote:
I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer.
Mike has been a long time contributor to the JDK, making changes
and reviewing in jdk8, jdk9, lambda projects. Mike has also been
contributing many patches in the build infrastr
Yes, we (the LangTools team) are on our own for this file. Jan Lahoda
did some work to update the build.xml file for us. At some point we may
want to do more surgery on this file, but that is a discussion for the
LangTools team to have.
-- Jon
On 08/15/2014 06:17 AM, Erik Joelsson wrote:
1 - 100 of 351 matches
Mail list logo
