search

Simn / genjvm

13 stars 1 forks source link

std/java #3

Closed Simn closed 5 years ago

Simn commented 5 years ago

The standard library is a bit of a mess. There's some __java__ which have to be replaced, as well as @:functionCode. I'm not sure how to go about this without making a huge #if-fest.

Simn commented 5 years ago

39 results in 6 files for @:functionCode

Of these, 28 are in the java.internal package which I plan to ignore (there will be JVM-specific internal stuff in java/jvm). So it's only 11 occurrences.

8 results in 4 files for __java__

The only immediate problem here is Std.hx.

Simn commented 5 years ago

Ideally we support Reflect.jvm.hx for this, but I don't want to rename the actual target.

Gama11 commented 5 years ago

but I don't want to rename the actual target.

Ah, so there's not going to be --jvm and --java, like there is with --swf and --as3?

Simn commented 5 years ago

My main concern is the existing java package. If we have a completely new target name, we should not access the old stuff in std/java, BUT all the native java types are namespaced to java.lang etc. too.

I don't think there's a good solution to this that isn't filesystem-based.

Simn commented 5 years ago

For now I have added std/jvm which is added with priority over std/java. It has its own _std to override some things, but falls back nicely to the std/java implementations otherwise.

Something that bothers me is that I have @:native("haxe.jvm.Something") on every type right now. I don't want to hijack the jvm namespace in the generated code, so we need a better strategy for this.

Although, come to think of it, I certainly don't want to hijack the java namespace either. It uses the same @:native approach to avoid the issue.

Any ideas how to handle this?

Simn commented 5 years ago

I guess we'll stick to this.