Is it possible to have a Java object as a static field? Just reduced my case down to

using [java] java.util::Date

class QuickTest
{
  static Void main()
  {
    echo("hi")
  }
  static const Date d := Date()
}

and it won't compile:

/Users/liam/Documents/mtcode/fantest/quicktest.fan(10,3): Const field 'd' has non-const type '[java]java.util::Date'
ERROR: cannot compile script

This is contrived as I wouldn't typically need to use a java Date object, but the behavior was the same for the original type I was trying to use. Have I missed something silly? Thanks for any tips!

I haven't looked at Brian's FFI code, but I would assume the answer is no. Static types must be const, which requires the value to be immutable. And Java types do not provide that guarantee.

OK, gotchya. Thanks for that confirmation.

I've been trying to imagine how to create a class-level java object, or even mutable map of them. None of the built-in Fan concurrency strategies seem to be good options since the java object isn't serializable. Is there a recommended pattern for this kind of usage?

The heart of that question is an interesting philosophical debate - how much should we enforce Fan's immutable and thread safety rules when using the Java FFI (same goes for Fan's nullable type system)?

The problem with Java APIs is that we have no ability to reflect nullability and immutability (since it isn't supported in the language). Although we could potentially create a meta-data library which explicitly told us what Java types were immutable and what APIs never take/return null. I think that might be kind of a cool long term project.

I kinda view it like calling out to JNI from Java. Once you leave the native environment, you're kinda on your own to make sure you don't screw things up. As an experienced java dev'er, i'm looking for more ease of integration than for any "hand holding" the type system might give. While I'm writing fan code, that stuff is all fine and good, but when I'm trying to get at java code, I just need the system to stay out of the way as much as possible.

Kinda agree with Cheeser on this. Wonder what scala does here.

But is there ever really a good reason that a Fan class needs a static field of a Java type?

In the case of actors you can always wrap the Java class with sys::Unsafe and figure out how to make it safe yourself.

Unsafe works just fine for my current needs - thanks for the pointer.

We could maybe enhance the using [java] syntax to tag imported classes as const:

using [java +const] com.mycompany::MyImmutable

The compiler could not statically guarantee the object's immutability, but that's okay as long as you take the risk yourself.

/Users/liam/Documents/mtcode/fantest/quicktest.fan(10,3): Const field d has non-const type [java]java.util::Date

For the record, java.util.Date actually is mutable. Sad but true.