Hello Jon,
we've encountered situation when class files resulted from successful
compilation cause runtime error; the sources are compiled by single
javac invocation. This looks like incorrect javac behavior, namely it
seems that javac should produce compile-time error if one tries to
compile
Hello everyone,
People reported that they are not able to run Eclipse with the latest JDK
build (b118). This is critical for us and would like to see it resolved as
soon as possible. We believe this is caused by change in resolution of EE
modules and further discussion can be found here -
https:
On 18/05/2016 14:42, Jayaprakash Arthanareeswaran wrote:
Hello everyone,
People reported that they are not able to run Eclipse with the latest JDK
build (b118). This is critical for us and would like to see it resolved as
soon as possible. We believe this is caused by change in resolution of EE
I just raised this issue on the JPMS experts list, but I want to discuss
the technical issues here.
On 05/18/2016 08:23 AM, David M. Lloyd wrote:
Related to #MutableConfigurations, in order to support dynamically
changing deployments for containers (including, I believe,
OSGi-compliant containe
Without yet looking at your zip file, it is possible to compile classes
that will not load in the application class loader, because of the
restrictions defined for the boot layer. That does not imply the classes
themselves are invalid, since they can be loaded and run in suitable
configured lay
On 18/05/2016 16:04, David M. Lloyd wrote:
I just raised this issue on the JPMS experts list, but I want to
discuss the technical issues here.
On 05/18/2016 08:23 AM, David M. Lloyd wrote:
Related to #MutableConfigurations, in order to support dynamically
changing deployments for containers (i
On 05/18/2016 10:35 AM, Alan Bateman wrote:
On 18/05/2016 16:04, David M. Lloyd wrote:
I just raised this issue on the JPMS experts list, but I want to
discuss the technical issues here.
On 05/18/2016 08:23 AM, David M. Lloyd wrote:
Related to #MutableConfigurations, in order to support dynami
On 18/05/2016 17:13, David M. Lloyd wrote:
At present, you can remove a module or a bundle even if existing
dependent module classes are statically referring to their contents.
It'll work fine as long as those classes haven't been loaded yet. So
we'd basically be taking away this capability
The runtime environment needs to have a way that developers can impose version
consistencies that make sense. In some cases it is just data consistencies
which can be managed literally with data construction.
But when code versions are mixed in with data versions, the runtime context
needs to
It appears at least in the latest b118 of jdk9 (I haven't tried any earlier
yet), compact profiles mappings to modules are broken? Doing an import of,
for example, javax.crypto.Cipher, which should exist in all 3 compact
profiles according to java 8 docs [1], fails with java 9.
$ javac -profile co
On 05/18/2016 12:36 PM, Alan Bateman wrote:
On 18/05/2016 17:13, David M. Lloyd wrote:
At present, you can remove a module or a bundle even if existing
dependent module classes are statically referring to their contents.
It'll work fine as long as those classes haven't been loaded yet. So
we'd
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html
This is to allow to patch java.base with an exploded image for JDK development
purpose like this:
$ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version
jdk.internal.module.SystemModules cla
On 18/05/2016 22:24, Ryan Ernst wrote:
It appears at least in the latest b118 of jdk9 (I haven't tried any earlier
yet), compact profiles mappings to modules are broken? Doing an import of,
for example, javax.crypto.Cipher, which should exist in all 3 compact
profiles according to java 8 docs [1]
On 19/05/2016 02:41, Mandy Chung wrote:
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html
This is to allow to patch java.base with an exploded image for JDK development
purpose like this:
$ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -ver
On 19/05/2016 06:49, Alan Bateman wrote:
:
In the mean-time then this should work:
java -release 8 -profile compact3 ...
or specify -limitmods, as in:
java -limitmods java.compact3 ...
Oops, I meant `javac` here of course (not `java`).
-Alan
15 matches
Mail list logo