As described in readme.txt, a standalone OpenJDK build embeds all
libraries, classes, and other files needed at runtime in the resulting
binary, eliminating dependencies on external resources.
Rather than try to support mixing Avian's core classes with those of
an external class library -- which necessitates adding a lot of stub
methods which throw UnsupportedOperationExceptions, among other
comprimises -- we're looking to support such external class libraries
in their unmodified forms. The latter strategy has already proven
successful with OpenJDK's class library. Thus, this commit removes
the stub methods, etc., which not only cleans up the code but avoids
misleading application developers as to what classes and methods
Avian's built-in class library supports.
Previously, we only built platform specific code in an
options-specific directory (e.g. build/linux-x86_64-debug), but built
the Java classes in the shared, top-level build directory. This
minimized duplication when building with different sets of options,
but now that we're supporting the option of selecting a third-party
class library, we need to put the classes in the options-specific
directory as well.
The latter is cheaper (avoids a state transition and possible memory
allocation) when we just want to know if an exception is thrown
without needing a handle to that exception.
We use this utility instead of objcopy to embed data into object files
because it offers more control over e.g. section alignment, which is
important for bootimage builds.
Here is a patch for getting Avian to build in Windows. I used MinGW
and MSYS for the build environment. The patch has the following
changes:
1. java-nio.cpp: Had to add an include and remove a function
declaration that was reported as duplicate.
2. readme.txt: Updated the instructions to include notes about
building on Windows.
3. makefile: Added a conditional for MinGW. I left the existing "ifeq
($(platform),windows)" conditional alone so as to not break
cross-compiled Windows builds. There are some similarities between the
two, so it might be possible to combine portions of them in an elegant
manner. Since I'm not sure how the cross-compiled builds have been
done, I didn't want to mess with that portion of the makefile.
