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.
The tower of patches and hacks grows higher. Ideally, we'll just drop
support for JDK 7 soon and clean this mess up a bit, but TravisCI
still hasn't gotten the memo that it's dead, so we muddle onward.
I've tested this on Windows, but not yet Linux or OS X. Wanted to get
a PR before I move on to that.
Did some cleanup as proposed by the main developers.
- Bigger HTTP Header Buffer
- Exception if Header is anyway exceeded.
- Linebreaks on HTTP Request fixed to standard.
- Only stop header reading on \r\n\r\n and no longer on \n\n\n\n
- Simplyfied the code to stop if buffer could not be filled.
- Handle special case if buffer has length 0, like specified in the Java API
- Socket will no longer fill the buffer completely
- handle sim flag to better distinguish between ios simulator / ios
- added ios_deployment_target to set ios min version
- default to 64 bit build for iOS
This option specifies that the test classes should be AOT-compiled
along with the class library, which allows us to test that everything
works in AOT-compiled form as well as JIT-compiled form. This is
primarily motivated by the need to test d906db6 (support for
AOT-compilation of Java 8 lambda expressions).
Note that I had to tweak Misc because it tested something that
couldn't be done in an AOT build without a lot of extra work, and
SystemClassLoader.getPackage because it was returning null when the
requested package could not be populated with JAR manifest metadata.
Technically, we probably *should* return null for packages that don't
exist at all (in the sense that no classes have been loaded from such
a package), but tracking that kind of thing seems like more trouble
than it's worth unless someone complains about it.
This stopped working recently, apparently due to obsolete jfrog.org
credentials. Since no-one is actually using these artifacts as far as
we are aware, I'm just disabling the task so the build doesn't
continue to fail.