This is a bunch of commits squashed into one per Josh's request.
add dynamicTable field
add invokedynamic instruction
add defaultDynamic bootimage field
add dummy invokedynamic support in bootimage-generator
add defaultDynamic thunk
check dynamicTable offset
comment defaultDynamicThunk to fix unused function
comment defaultDynamicThunk to fix unused function
add dynamicTable / dynamicIndex stuff
comment dynamicIndex and dynamicTable
add invokedynamic instruction impl
stub out addDynamic
unstub addDynamic
don't allow tail calls in invokedynamic
implement stub JVM_GetTemporaryDirectory method
(build broken) begin add InvokeDynamicTest
Revert "(build broken) begin add InvokeDynamicTest"
This reverts commit 77f9c54e32ac66d0803eeab93e4a10d3541987a8.
add InternalError
add URLClassPath.c for openjdk-src builds
implement stub JVM_KnownToNotExist and JVM_GetResourceLookupCache methods
intercept open0 / open for openjdk
add basic java/lang/invoke stubs
remove non-public java/lang/invoke classes
fix invokedynamic example building
<wip debugging>
Someone on the Google Groups site asked how to set up an Eclipse
project with Avian classpath. This patch creates the descriptor
that you can you use to do that at `$(build)/eclipse/jdk/avian.ee`.
The descriptor includes the Avian version, platform, architecture,
and build options to allow for multiple versions to exist side by
side. Users can import the descriptor into Eclipse via:
Window >> Preferences >> Java >> Installed JREs >> Add >> Execution
Environment Description
Once the descriptor is imported, Avian can be used just like any other
JVM installation for Eclipse projects. Personally I use this in
conjunction with Eclim to gain code completion for Avian in vim.
The new targets also create symlinks to loosely mimic OpenJDK's
filenames and folder layout:
build/linux-x86_64-tails-continuations/eclipse/jdk/
├── avian.ee
├── bin
│ └── java -> ../../../avian
├── jre
│ └── lib
│ └── rt.jar -> ../../../../classpath.jar
└── src -> ../../classpath
Annoyingly, Eclipse for some reason expects this layout to exist
even though the descriptor format has required parameters for
specifying these locations. I suppose that other software may
look for this "standard" layout in a JVM installation so it may be
generally useful.
These artifacts are only built if the platform is one of `windows`,
`linux`, or `macosx`. The symlinks might not actually work at all on
Windows, I'm not sure how things like cygwin/msys handle that and I
do not have the means to test it. If they do not work a fallback
for windows might be to actually copy the files instead of symlinking.
I realize this can be done outside of the makefile but it seemed
useful to put it here to gain access to the information about the
build location, platform, architecture, and other build options.
For the record, this contribution is my original work and is released
under the same license that Avian uses, found in the license.txt
file in this repository.
80ce92a introduced a regression which caused the Cygwin build to fail,
since it tried to set platform=$(build-platform) when calling make
recursively, and platform=cygwin is rejected by the makefile.
Instead, we need to use $(bootimage-platform), which normalizes
"cygwin" and "mingw32" to "windows".
MinGW defines __STRICT_ANSI__ when -std=c++0x is specified, which we
have to override in order to get e.g. strdup. Also, we need to
specify -D_WIN32_WINNT=0x0500 to get post-Windows-2000 functions like
GetModuleHandleEx. Finally, it seems that GCC 4.8.1 wants us to use
%I64d instead of %lld on Windows.
Lots has changed since we forked Android's libcore, so merging the
latest upstream code has required extensive changes to the
Avian/Android port.
One big change is that we now use Avian's versions of
java.lang.Object, java.lang.Class, java.lang.ClassLoader, some
java.lang.reflect.* classes, etc. instead of the Android versions.
The main reason is that the Android versions have become very
Dex/Dalvik-specific, and since Avian is based on Java class files, not
dex archives, that code doesn't make sense here. This has the side
benefit that we can share more native code with classpath-avian.cpp
and reduce the amount of Java/C++ code duplication.
Posix_getaddrinfo needs to access fields in libcore.io.StructAddrinfo
via JNI, so we tell ProGuard to preserve them.
This commit also includes a minor indentation tweek in README.md and
removes -fno-rtti from lzma-build-cflags to avoid a warning from GCC.
Clang doesn't like seeing -std=c++0x when building C code, and many of
the options in cflags don't apply to the LZMA source code anyway, so
we give LZMA its own set of compiler flags.
