We are working to improve the ergonomics of using Fantom APIs by Java code. We've had jardist for a long time, and soon we will have a transpiler to Java source. But it can still be a little awkward to use Fantom from Java code.
For 1.0.82 we have already transitioned fan.sys.List and fan.sys.Map to be Java generics to improve ergonomics.
But I would also like to make the following breaking changes to the Java native APIs:
Have fan.sys.List implement java.util.List
Have fan.sys.Map implement java.util.Map
Remove unnecessary public APIs from fan.sys like ListType, MapType, etc
The first two will allow Fantom's primary two collection types to be standard Java collection types. But it requires a few breaking changes. For example, java.util.List requires size() to return an int, which conflicts with the Fantom's List.size that must return a long. To fix this, we will define alternate versions used by Fantom bytecode:
public int size() // java version
public long _size() // fantom version
This will not change anything in the Fantom APIs and is transparent to Fantom developers. The translation will happen when we emit the fcode to bytecode at runtime. However, it is potentially a breaking change to existing Java native code.
The other change is to remove many of the unneeded public APIs in fan.sys. There are several public classes that don't map to Fantom APIs including:
FanClassLoader
GenericType
ListType
MapType
FuncType
ClassType
NullableType
Most of these can be easily moved to utility methods on Sys.java to avoid pollution of the public package API.
There are also several methods on public types that need review to decide if they really belong as part of the public API. The goal would be clean-up these APIs and clearly indicate if something public should not be used (Java doesn't really have concept of nodoc).
The goal here is to create a well defined public Java API that is ergonomic to Java programmers. But downside it does require some internal Java API changes. So want to give everyone a heads up. Let me know if you have any questions/concerns. I'm planning on starting this week next week most likely.
brian Tue 20 May
We are working to improve the ergonomics of using Fantom APIs by Java code. We've had jardist for a long time, and soon we will have a transpiler to Java source. But it can still be a little awkward to use Fantom from Java code.
For 1.0.82 we have already transitioned fan.sys.List and fan.sys.Map to be Java generics to improve ergonomics.
But I would also like to make the following breaking changes to the Java native APIs:
The first two will allow Fantom's primary two collection types to be standard Java collection types. But it requires a few breaking changes. For example, java.util.List requires size() to return an int, which conflicts with the Fantom's List.size that must return a long. To fix this, we will define alternate versions used by Fantom bytecode:
This will not change anything in the Fantom APIs and is transparent to Fantom developers. The translation will happen when we emit the fcode to bytecode at runtime. However, it is potentially a breaking change to existing Java native code.
The other change is to remove many of the unneeded public APIs in fan.sys. There are several public classes that don't map to Fantom APIs including:
Most of these can be easily moved to utility methods on Sys.java to avoid pollution of the public package API.
There are also several methods on public types that need review to decide if they really belong as part of the public API. The goal would be clean-up these APIs and clearly indicate if something public should not be used (Java doesn't really have concept of nodoc).
The goal here is to create a well defined public Java API that is ergonomic to Java programmers. But downside it does require some internal Java API changes. So want to give everyone a heads up. Let me know if you have any questions/concerns. I'm planning on starting this week next week most likely.