John Rose a écrit :
> When experimenting with invokedynamic or even just method handles,
> always compile with -target 7 (or -XDinvokedynamic) and run with
> -XX:+EnableInvokeDynamic. These defaults will get better when the EG
> converges on the spec.
>
> The API docs don't get built, and javac claims that java.dyn doesn't
> exist, for the same reason. I made an error (in configuration
> management) in the makefile which controls which APIs are officially
> visible. The same makefile variable ${CORE_PKGS} controls (a) which
> classes get javadoc, and (b) which javac can see. Quite logical, in
> hindsight. :-) We're fixing this in b59.
>
> I have done a build with the config change and from that build I can
> browse the API and run javac w/o the extra "-cp rt.jar". Xiomara is
> going to run some more extensive builds and tests, the results of
> which I hope will be available in the next OpenJDK build.
>
> Meanwhile, I'll release the patch to the makefile in MLVM. (And see
> below; it's simple.)
I've tried your patch and it partially works :(
/usr/jdk/jdk1.7.0b58b/bin/javac -source 1.7
fr/umlv/indy/visitor/AbstractVisitor.java -d ../test-classes/
fr/umlv/indy/visitor/AbstractVisitor.java:15: cannot access
sun.dyn.MethodHandleImpl
private final ConcurrentHashMap<Class<?>, MethodHandle> map;
^
class file for sun.dyn.MethodHandleImpl not found
The compiler is confused by the fact that java.dyn.MethodHandle inherits
from sun.dyn.MethodHandleImpl
which is not visible.
We found another reason to change that design :)
Rémi
>
> There may be another problem. I have been getting irregular success
> from javac on Mac OS when building. Sometimes the wrong javac gets
> used, instead of the javac built from the mlvm/langtools patches. The
> symptom is that the build breaks with the compiler reporting errors on
> method handle invocation sites (because it's not upgraded). This must
> happen if a partial jdk-only build is done, but it seems to happen
> even if a full build of langtools + jdk is done. Not sure yet what's
> up; maybe I haven't done enough "rm -rf build", or maybe there's a
> problem with the wrong tools.jar getting picked up by javac. There is
> a rumor that Mac OS javac is unusual in that it puts the system
> tools.jar on the bootclasspath, making it hard to override.
>
> I'll look at your NPE also, Remi. Thanks for the great reports.
>
> -- John
>
>
> diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk
> --- a/make/docs/CORE_PKGS.gmk
> +++ b/make/docs/CORE_PKGS.gmk
> @@ -97,6 +97,7 @@
> java.awt.print \
> java.beans \
> java.beans.beancontext \
> + java.dyn \
> java.io \
> java.lang \
> java.lang.annotation \
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
