Page 1 of 6

Java Back End

PostPosted: Fri Feb 11, 2011 5:35 am
by hopscc
I've been doing some work on cobra supporting a jvm/java back end and have opened ticket:275 for holding patches for this.

There's nothing uploaded yet but so far I have some progress with the cobra compiler being able to find and use javac and java (in path), compiling and running (single file) Java modules and generating java source, compiling and running it for very (very) simple cobra source files.
Code: Select all
# cobc0 -back-end:jvm -kif -v:2 020-var-decl.cobra
Cobra Command Line 0.8.0 post-release
Copyright (C) 2003-2011 by Cobra Language LLC.

OS Version:   Microsoft Windows NT 5.1.2600 Service Pack 3
CLR Platform: .NET
CLR Version:  2.0.50727.3603
Current Directory: C:\home\hops\src\cobra\Tst\100-basics
Current Exe: C:\home\hops\src\cobra\wkspace\Source\cobra.exe
Option Dictionary:
    reveal-internal-exceptions: true
    color: true
    back-end: 'jvm'
    keep-intermediate-files: true
    verbosity: 2
    contracts: 'inline'
    correct-source: Set<of String>['none']
    debugging-tips: true
    embed-run-time: false
    include-asserts: true
    include-nil-checks: true
    include-tests: true
    include-traces: true
    native-compiler: 'auto'
    number: 'decimal'
    test-runner: 'Cobra.Lang.CobraCore.runAllTests'
    testify-results: 'r-testify'
Paths:
    020-var-decl.cobra
Phase: Binding Cobra run-time library
Referencing Cobra run-time
Adding reference to Cobra.Lang.dll
Phase: Reading libraries
Reading assembly:  mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
              at:  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
Reading assembly:  System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
              at:  C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll
Final assembly reference list:
0. Cobra.Lang.dll
Loading reference: Cobra.Lang.dll
Reading assembly:  Cobra.Lang, Version=0.8.0.1, Culture=neutral, PublicKeyToken=null
              at:  C:\home\hops\src\cobra\wkspace\Source\Cobra.Lang.dll
Phase: Parsing source code
Parsing 020-var-decl.cobra
Phase: Binding use directives
Phase: Binding inheritance
Phase: Binding interface
Phase: Computing matching base members
Phase: Binding implementation
Phase: Identifying .main
Phase: Generating Java code
cobratype - void
System.Int32
cobratype - java.lang.Integer
System.Int32
AsExpr-sh(5454, didBindInh=false, didBindInt=false, didStartBindImp=true, didBindImp=true, token=Token(ID, 'x', 'x', ln 7, col 4, 020-var-decl.cobra), name=x, name=x, type=IntType-mi(5451, didStartBindInh=true, didBindInh=true, didStartBindInt=true, didBindInt=true, didBindImp=false, isSigned=true, size=32, 5451), definition=LocalVar-mi(14017, name=x, didStartBindInh=true, didBindInh=true, didStartBindInt=true, didBindInt=true, didStartBindImp=true, didBindImp=true, token=Token(ID, 'x', 'x', ln 7, col 4, 020-var-decl.cobra), isTracked=true, isTracked=true, 14017), 5454)
x
Phase: Compiling Java code
Compiling generated code
Compiling to produce Test.class
compiler = javac.exe
    compilerOptions = -d . -classpath "C:\home\hops\src\cobra\wkspace\Source\CobraLang.jar"
    nativeArgs =
    outName = Test.class
    baseExeFileName = test.Test
    javaFileNameList = ['Test.java']
javac.exe -d . -classpath "C:\home\hops\src\cobra\wkspace\Source\CobraLang.jar" "Test.java"
Keeping intermediate files.
Phase: Checking if a default number type should be suggested
Running: test.Test
-------------------------------------------------------------------------------
stub:running all tests...
#


My initial target for this is to be able to compile and execute the tests in 100-basics ( so far I'm up to 025-assign-in-expr.cobra),
fleshing out at least minimal support for java codegen for the major (and obvious) cobra statements and expressions and to
eventually generate stand alone application jar files (currently just generate and run class files).

Its a bit messy since its a cross compilation environment from .Net using .Net libs and has no cobra compiled java RTL but thats the bootstrap path till I get something more java self hosting or hit a snag

I want to get a bit further with more things supported and tests working but hope to provide an initial patch soon.

Currently I'm working on Windows (XP) so the initial work will be (perhaps) specific to that

More as I get to it.

Re: Java Back End

PostPosted: Fri Feb 11, 2011 7:45 am
by RIGHT_THEN
Hello Mr. hopscc

Nice to hear you have started JVM port and your effort.

I only have few humble suggestions. Have you heard of this language STAB.
http://code.google.com/p/stab-language/
it is C#/JAVA implementation on JVM it implements almost the features found in C#.it even has Linq.it is almost word to word with C#.i cannot say it is dito C# because i have never worked on
JVM. but you can see on above mentioned site it appears dito C# to me for JVM.

Since Cobra allready has C# generator implemented. It would be easier to test cobra on JVM
with STAB than with JAVA. with minor tweaking . like

using ju = java.util;
using ja = java.awt;
..

instead of .net assemblies
using System;
using SNet = System.Net;
..

In nutshell Cobra allready has sortof backend ready for JVM.because C# = STAB!!!
so Cobra generated code can be passed to Stab compiler and let it tackle JVM.
it would be easier to bring about a JVM implementation this way.since you keep on
posting patches for Cobra so you must be good at C# too.i am not saying you may not
be good at JAVA. ;). Actually you might even hate C# :P . It is just that you may not
have to work that hard to test your logic on JVM and get faster results to realise
your vision for implementation.


ThankingYou
RIGHT_THEN

Re: Java Back End

PostPosted: Fri Feb 11, 2011 9:01 am
by Charles
hopscc wrote:I've been doing some work on cobra supporting a jvm/java back end and have opened ticket:275 for holding patches for this.

There's nothing uploaded yet but so far I have some progress with the cobra compiler being able to find and use javac and java (in path), compiling and running (single file) Java modules and generating java source, compiling and running it for very (very) simple cobra source files.

Is this based on the existing CobraWorkspace/Source/BackEndJVM files? There are about 2,500 (raw) lines of code there that invokes javac, etc.

I started that code and then wondered if a better approach would instead be to IKVM + ASM.

My interest has shifted to the Obj-C back-end. Maybe between the two of us, Cobra will have two new back-ends by year end. :D

Re: Java Back End

PostPosted: Fri Feb 11, 2011 9:05 am
by Charles
Regarding STAB, if you don't end up generating to it, you can still make use of looking at their implementation to see how they implement various features.

Re: Java Back End

PostPosted: Mon Feb 14, 2011 4:16 am
by hopscc
Thanks for the ptr to STAB - I wasnt aware of it.
Using it may help with bootstrapping but I'd be loath to make it (the only) backend java target since it demands another set of
tool dependencies to download and install (over the jdk) when using cobra on a jvm
Still it might be interesting to fiddle with if its not too dissimilar to C#.

The sticking point with the cobra source and multiple backends is is the direct use of the .Net libraries
cobra doesnt currently support the c# aliasing/renaming capability (though there is a patch for it on ticket:201
Code: Select all
#!cobra
use java.util as ju
# really want
#use java.NetEmu.System as System

but even it it was available it wont work to just alias the java libs to the .Net names because the names, API and architecture is
all different.
We'll start off cross compiling and probably end up when we go native with an enhanced RTL that supports the .Net API using java libs for the subset of pieces the cobra compiler uses (or something)

Yah, The code so far is based on the files from Source/BackEndJvm - I've got the javac/java invocation working and mapping from cobra source to
idiomatically named java source and class files its so far been just fleshing out the missing stuff in JavaGenerator.

Re: Java Back End

PostPosted: Tue Feb 15, 2011 8:14 am
by torial
It may be worth making an intermediate set of wrappers (ie adapters) that would change depending on whether the target was .Net / Java. But that is a *big* undertaking... but I've occasionally thought there may be some value to that longer term. Does anyone know if anyone has started such an approach? (perhaps there is already an attempt at a Java/.Net adapter...)

Re: Java Back End

PostPosted: Wed Feb 16, 2011 2:22 pm
by Charles
I have not started such an approach, but I've also been thinking about it. I call the long term approach the "Cobra Portable Library" or CPL, meaning that if you code against that, you would be able to compile your code on any Cobra back-end. I'm sure it is a huge task and that sealed classes such as String will probably provide some interesting challenges.

Re: Java Back End

PostPosted: Thu Feb 24, 2011 4:08 pm
by FierceForm
Could you use this for something like Android programming? That would be pretty cool.

Re: Java Back End

PostPosted: Thu Feb 24, 2011 9:29 pm
by Charles
I would imagine that it shouldn't be too hard to get working. I think you might also be able to use Cobra + Mono right now through MonoDroid (http://monodroid.net/), but I haven't tried it.

Re: Java Back End

PostPosted: Wed Mar 02, 2011 7:51 am
by hopscc
I've been off on a (dead end) sidetrack with the java backend in attempting to bootstrap code using STAB by porting Native.cs, etc.

Its sorta worked but while STAB is closer to C# than java is its not exactly the same, doesnt support all the C# constructs and does some of them differently so its almost as much twiddling to port to STAB as it is to go to pure Java which I'm now going back to doing.

I might revisit this for a STAB backend sometime in the future but for now its goanna be pure Java all the way down...

Having said that though STAB seems like a quite nice , convenient and modern language for the JVM
- a better java than java - providing many useful and convenient C# features that java (language) doesnt....