For lambdas that implement java.io.Serializable, the compiler emits
calls to LambdaMetaFactory.altMetafactory, not
LambdaMetaFactory.metafactory, so I've provided a stub implementation
that ignores that currently ignores the extra parameters it receives.
This also fixes a bug in compiling lambda glue code for lambdas that
take longs and/or doubles.
Trace.java fails randomly on Travis, but we've never been able to
reproduce or debug the failure elsewhere, so now we skip it if we
detect the suite is running on Travis.
Per a recent bug report in the hello-ios project, we found that
bootimage-generator would abort with no explanation if it encountered
a lambda invocation and the `-hostvm` option was unspecified. This
commit ensures that a helpful message is printed before exiting.
Apparently the MinGW header files don't declare it, despite it being
part of liblphlapi.a. More confusingly, it didn't break anything for
64-bit builds because the compiler used an implicit declaration that
matched the link-time symbol name. Alas, no such luck for 32-bit
builds, since the implicit declaration was not annotated with the @48
stdcall argument stack size, so the build died at link time.
The title is not strictly required, but it's useful metadata, and part of the recommended license template text (see http://choosealicense.com/licenses/isc/ and https://opensource.org/licenses/isc-license)
As for the filename, lowercase is fine, but since this project already uses an uppercase README as customary, using the same standard for the LICENSE file seemed to make sense.
Prior to this commit, we had a little bit of "cleverness" wherein we
recursively invoked make to determine which of the .class files in the
class library were out of date with respect to their .java files. We
did this to avoid asking javac to recompile everything every time.
The problem with that is when building against an alternative class
library (e.g. OpenJDK or Android), we use a combination of classes
from the alternative library and some of the built-in Avian classes
(e.g. java/lang/invoke/MethodHandle, which is very closely tied to the
VM). This confuses the build process, since some of the classes were
taken from an external jar, and some of them were built from source.
The tricky bit is that, depending on the relative timestamps of the
extracted .class files and the .java source files, you might never see
the problem. That's why I couldn't reproduce this when it was first
reported a few months ago: my source files were newer than the .class
files from the OpenJDK jars I was using, so the Avian versions were
built and used as intended. It was only later when I used a newer
OpenJDK that I hit the problem.
Anyway, I've removed the cleverness. If this causes an unreasonable
regression in (re)build times, we can try to reintroduce it in a way
that avoids the above problem, but for now simpler is better.
Although some people still use MSYS to build Avian (e.g. the
avian-pack project), I'd rather not support it officially, and the
instructions in the README.md are outdated anyway. This will
hopefully encourage new users to use Cygwin instead, which is less
likely to break without me noticing since that's what I use myself.
Per a recent request for help on the Google group, I spent some time
this past weekend trying to debug the MSYS build. The conclusion I
came to is that MSYS is not worth supporting anymore. The most recent
release is almost three years old, and I've been unable to find any
variant with a 64-bit-target compiler that will actually install. If
someone else cares enough about building Avian on MSYS to maintain it
themselves, patches are welcome.
Meanwhile, let's all just use Cygwin. Perhaps someone will build a
cool package manager on top of WSL and suddenly make both Cygwin and
MSYS obsolete.
Previously, we only seemed to define sysroot for MacOS, not iOS, yet
we reference $(sysroot) in both cases. This ensures it is defined in
both cases as well.
OpenJDK's java.util.zip.ZipFile.getEntryBytes should return a byte
array that is not null-terminated, but we were giving it one that was
null-terminated, which caused lookups to fail later when
ZipFile.getInputStream was called.
Since we can't predict what warnings future compilers will emit, and
most people just want to build Avian without some new warning tripping
it up, we now omit -Werror unless requested via the "use-werror=true"
option to make. Note that we pass "use-werror=true" in test/ci.sh to
ensure Travis alerts us to new warnings as they appear.
BTW, sorry about the unrelated whitespace changes in this patch; I've
got Emacs set up to fix whitespace "problems" on save, and those are
what it found.
Previously, the following code would throw an IllegalMonitorStateException:
public class Test {
public static synchronized void main(String[] args) {
Test.class.notify();
}
}
The problem stems from the fact that for a long time Avian has had two
representations of a given class: avian.VMClass and java.lang.Class.
It used to be that there was only one, java.lang.Class, but that
didn't play nicely with OpenJDK's class library, so we split it into
two. Unfortunately, we forgot to update the JIT and interpreter
accordingly, so a static synchronized method would acquire the
avian.VMClass instance, whereas Foo.class.notify() would be invoked on
the java.lang.Class instance.
This commit fixes it.
