I've made a series of a fairly substantial changes in both the compiler and the runtime for how the Java FFI works:

Classfile Disassembler

Up until this point, the Java FFI compiler relied on java.lang.reflect to perform its type checking. This was always intended a temporary hack (it just lasted several years). The problem with using reflection is that it required every class you used in your code to be in Fantom's system classpath.

I've now replaced this code with a proper classfile disassembler written in Fantom. This is a fairly massive change to how the compiler performs the reflection used for type checking. I believe I've achieved almost perfect parity with how the old code works and the test suite is fully working. But with a change of this magnitude I'm sure issues will crop up. If you are working off tip and a Java FFI user, I would appreciate any pre-build testing you can do. Just in case I've left the old code in place; to fallback to the old reflection loader:

// {home}/etc/compilerJava/config.props
useReflection=true

ClassPath

With the disassembler change, a new world of options has opened up. I've now enhanced both the compiler and the Java runtime to automatically include your dependent pods as part of your pod's classpath.

BuildPod

I've enhanced the compiler to treat a resource file with a "jar" extension specially. It will now bundle the jar into the pod in unzipped form (versus being included as a single file). This allows us to easily turn jars into a pod by adding the appropiate metadata. For example here is a sample script to turn "lucene-core.jar" into a Fantom pod:

class Build : BuildPod {
  new make() {
    podName = "luceneCore"
    summary = "Lucene Core"
    meta    = ["org.name":     "Apache",
               "org.uri":      "http://apache.org/",
               "proj.name":    "Lucene",
               "license.name": "Apache License Version 2.0"]
    version = Version("3.5.0")
    resDirs = [`lucene-core-3.5.0.jar`]
  }
}

Java in Fantom

All of these infrastructure changes are laying the new foundation for how we manage Java JAR files in the Fantom environment. Since Fantom already has a first class module system with clean dependencies, the logical design is to manage Java JAR files as standard Fantom pods. This is the design have been pursuing.

At this point, with what we have you can manually convert your JAR files into Fantom pods. Then you can declare dependencies on that pod in the standard way. The compiler will allow you use Java FFI for packages in your dependency chain, and the runtime will resolve everything correctly.

The next phase is to define the conventions and tools to automate the process of importing Java JARs into the Fantom runtime as first class pods. I believe the ideal solution is to enhance fanr to treat Maven as a special kind of repository. Then during the install process, we can convert the Maven metadata into pod metadata. This is probably not a project I'll do, but I'd like to work someone who would like to take the lead and work with me to ensure a clean integration. Any volunteers?

Promoted to ticket #1780 and assigned to brian

Ticket resolved in 1.0.62

This is great, that should allow a lot of improvements with java compatibility.

While Fantom java support is pretty good, i always felt it was a bit sub-par compared to say groovy or scala.

I think it's very important, because there are so many good(and terrible) java libraries out there to leverage

I know where I work I tried to use Fantom, but except for standalone projects it was kind of a no-go, because those projects where using a ton of java libraries and the whole thing managed with maven(not that i like maven much, but it's kinda needed).

So I think this could eventually allow to plugin Fantom within java and vice versa, personally I think it terms of adoption that could be huge, remember that the vast majority of developers are still stuck with Java.

+1, this is a great change. I have always felt that fantom was much too standoffish from Java. Yes I know that fantom strives for VM agnosticity, but for most people the target VM is known in advance and not likely to change. Now fantom will be much easier to incorporate into existing projects.

Yes, excellent! Mixed-mode (fantom & java) developing ought to work much better now, with the fantom compiler able to see actual classfiles instead of requiring to get them onto the classpath and reboot the vm.

Excellent. Thanks!