Ok, so MigPane is finished and the option to make it truly independent on Java I'd have to manually transcribe it to Java. That's too much of a pain and not a generic enough solution.
So, is it possible to translate Java bytecode into Fantom bytecode (back port it somewhat)? That way I wouldn't need to branch MiGLayout and the community would get an awesome tool to translate Java into anything Fantom targets. I'm looking into this as my 6-month Master thesis.
brianWed 30 Mar 2011
So, is it possible to translate Java bytecode into Fantom bytecode
I suppose it it possible, although Fantom to JavaScript requires Fantom source, not fcode. And anything UI related would be highly desirable to target for JS generation.
Probably a more useful tool would be Java source to Fantom source converter. I've also thought that a Fantom to Java source converter would be really nice too.
DanielFathWed 30 Mar 2011
True, but I'm there seems to me several limitations that Fantom can't do. On the top of my head I can name are static mutable fields, generics and method overload.
Method overload could be fixed easily, by appending parameter names, but I'm unsure how would mutable fields or generics translate into Fantom.
Another worry is that Fantom code is more malable and subject to change, while fcode seems way more stable. I'd hate to make a "temporary" solution that remains forever but under the circumstances, it seems safer to take the bytecode apporach than going for source translation only for the language to change under me.
vkuzkokovWed 30 Mar 2011
Generics can be translated by erasure (just like java compiler does).
Mutable static fields can be implemented through storage Actor.
Fcode seems easier to comprehend (and target) than JVM bytecode.
What I see a problem is translating library classes and value types by replacing them with Fantom library classes as appropriate ( java.lang.String => sys::Str?; byte,short,char,int,long => sys::Int etc.)
DanielFathWed 30 Mar 2011
As for those classes, I'd definitely use interop classes Fantom provdies that way it would be maximally consistent (which is the point I guess). I'm really unsure how I could translate this Java code into Fantom.
class <T> Foo
{
T call(<T> param)
}
This is like infite overload. I'd love to see an example of what corresponding Fantom code would look like (even if using erasure). Would it just replace <T> with Obj? and if so how would I treat <T extends Num> and <T super Num>?
qualidafialWed 30 Mar 2011
What about using the GWT compiler to convert Java to JS?
vkuzkokovWed 30 Mar 2011
Erasure type for T extends Sth is Sth. In other cases it's Obj. The code becomes
class Foo
{
Obj call(Obj param)
}
I think either JLS or JVM spec should give the best explanation of how erasure works.
DanielFathThu 14 Apr 2011
Perhaps this solution should be attacked from two angles.
Create a way to translate JVM bytecode into fcode.
Create a way to create fcode into Fantom source.
That way if a reliable solution for 2. is made it will be easier to recompile any platform language into Fantom source.
DanielFath Wed 30 Mar 2011
Ok, so MigPane is finished and the option to make it truly independent on Java I'd have to manually transcribe it to Java. That's too much of a pain and not a generic enough solution.
So, is it possible to translate Java bytecode into Fantom bytecode (back port it somewhat)? That way I wouldn't need to branch MiGLayout and the community would get an awesome tool to translate Java into anything Fantom targets. I'm looking into this as my 6-month Master thesis.
brian Wed 30 Mar 2011
I suppose it it possible, although Fantom to JavaScript requires Fantom source, not fcode. And anything UI related would be highly desirable to target for JS generation.
Probably a more useful tool would be Java source to Fantom source converter. I've also thought that a Fantom to Java source converter would be really nice too.
DanielFath Wed 30 Mar 2011
True, but I'm there seems to me several limitations that Fantom can't do. On the top of my head I can name are static mutable fields, generics and method overload.
Method overload could be fixed easily, by appending parameter names, but I'm unsure how would mutable fields or generics translate into Fantom.
Another worry is that Fantom code is more malable and subject to change, while fcode seems way more stable. I'd hate to make a "temporary" solution that remains forever but under the circumstances, it seems safer to take the bytecode apporach than going for source translation only for the language to change under me.
vkuzkokov Wed 30 Mar 2011
Generics can be translated by erasure (just like java compiler does).
Mutable static fields can be implemented through storage
Actor
.Fcode seems easier to comprehend (and target) than JVM bytecode.
What I see a problem is translating library classes and value types by replacing them with Fantom library classes as appropriate (
java.lang.String => sys::Str?
;byte,short,char,int,long => sys::Int
etc.)DanielFath Wed 30 Mar 2011
As for those classes, I'd definitely use interop classes Fantom provdies that way it would be maximally consistent (which is the point I guess). I'm really unsure how I could translate this Java code into Fantom.
This is like infite overload. I'd love to see an example of what corresponding Fantom code would look like (even if using erasure). Would it just replace
<T>
withObj
? and if so how would I treat<T extends Num>
and<T super Num>
?qualidafial Wed 30 Mar 2011
What about using the GWT compiler to convert Java to JS?
vkuzkokov Wed 30 Mar 2011
Erasure type for
T extends Sth
isSth
. In other cases it'sObj
. The code becomesI think either JLS or JVM spec should give the best explanation of how erasure works.
DanielFath Thu 14 Apr 2011
Perhaps this solution should be attacked from two angles.
That way if a reliable solution for 2. is made it will be easier to recompile any platform language into Fantom source.