Hi Stuart,
please review the updated webrev, which remove not-suggested
filesystem modification and codebase stuff:
http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/
Thanks,
Felix
Hi,
the Lucene team installed JDK9 build 118 today and this failed our build during
some checks. The reason is that some classes are missing from the unnamed
module (standard Java 8 classpath-only application). Just try this test:
public class Test {
public static void main(String... args) th
In general, it's not practical to go back and fix updates to older
releases so that the compiler is cognisant of all syntax changes
in subsequent releases, especially changes in features that are
still under development.
For example, it's possible that the original submitter was using
a recent ve
On 16/05/2016 15:28, Uwe Schindler wrote:
:
This is not the only class that’s missing at runtime, there are more: I do not have the
complete list, but our checks using the forbiddenapis Ant/Maven/Gradle plugin fails to
load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*) and CORBA (org
Hi Jon.
What's recommend to do ? Do I need to find other version case it exists?
I've read some information about this problem. It advice to add this
project into jdk 9. Is it correct?
Thanks guys!
On May 16, 2016 11:45, "Jonathan Gibbons"
wrote:
> In general, it's not practical to go back and f
Thanks Alan,
so this means we should better remove the references to the mentioned class
from the Apache Solr code if not needed (I don't think we need the Java EE
features here, it might be an oversight). I just wonder why Javac succeeded in
our case to build. I have to dig.
For now I added "
You are right, Alan. Thank you.
http://cr.openjdk.java.net/~shurailine/8156972/webrev.01/
I have also tried to think of a better message, since it is UOE not and not ISE
… but decided it is descriptive enough as it is.
Shura
> On May 14, 2016, at 8:37 AM, Alan Bateman wrote:
>
> On 13/05/20
Martin's MineField test has been excluded for some time, one reason is
that it exercised -Xbootclasspath/p and so doesn't work with JDK 9. Jon
is cleaning up this test via JDK-8156989 and lo behold, it finds a
corner case.
The corner case is where the last element of the class is the empty
On 16/05/2016 18:28, Alexandre (Shura) Iline wrote:
You are right, Alan. Thank you.
http://cr.openjdk.java.net/~shurailine/8156972/webrev.01/
I have also tried to think of a better message, since it is UOE not and not ISE
… but decided it is descriptive enough as it is.
I think UOE is bette
On 16/05/2016 16:19, Uwe Schindler wrote:
Thanks Alan,
so this means we should better remove the references to the mentioned class
from the Apache Solr code if not needed (I don't think we need the Java EE
features here, it might be an oversight). I just wonder why Javac succeeded in
our ca
> On May 16, 2016, at 11:53 AM, Alan Bateman wrote:
>
>
> Martin's MineField test has been excluded for some time, one reason is that
> it exercised -Xbootclasspath/p and so doesn't work with JDK 9. Jon is
> cleaning up this test via JDK-8156989 and lo behold, it finds a corner case.
>
> The
On 05/16/2016 12:36 PM, Mandy Chung wrote:
>For tests then Jon will be pushing the updated MineField to jdk9/dev soon. We
need to go over the new options and get javac and the runtime consistent. I think
we want it so that empty elements in the new options are ignored, leaving class
path for
Hi guys!
I found the solution for my problem. Maybe this information can be
important for other developer. If you desire to run JIGSAW project's
examples cod, so you need download open-jdk-9 with jigsaw project:
https://jdk9.java.net/jigsaw/. It appears obvious, but I didn't know.
Thank you.
On
13 matches
Mail list logo
