Hey,

The xtend language [1] had a new release last week; they purport to be a 
"better Java" syntax but interestingly compile-down to Java source code, 
not Java byte code. Which means something like GWT can read the .java files 
and not care that the original language was not actually Java.

As much as I like GWT, I will readily admit the aging Java syntax is not 
one of it's strengths, so have been actively looking for alternatives. Here 
are my thoughts on xtend/the syntax problem in general.

* xtend itself seems kind of flaky--I could not get it to work by using 
their update site into my existing Eclipse installation. However, their 
update site has a long, complex list of features to choose, so I may have 
just choose the wrong one.

* They also have a new distribution, which I did get to work, but only 
after deleting some code from their out-of-the-box sample project that for 
some reason wasn't compiling. It seems like I had to do a couple of clean 
builds before I finally saw things kick into gear and make some .java 
source files.

These two points being said, it's a new project, so I have no problem with 
some rough edges. That being said, it also looks like:

* If you run a junit test and it fails, and click on the failed method, 
Eclipse takes you to the generated .java file to show the failure. The 
generated .java files aren't necessarily ugly, but it seems like the point 
of a new syntax is to not have to look at the old one.

* You cannot currently set debug points in .xtend files, you have to go to 
the generated .java files, set a debug point there. The Eclipse debugger 
will also step you through the generated Java code instead of the original 
.xtend code while you're debugging.

So, this seems a little bit more odd to me. Perhaps it's something they can 
fix as the project matures, but I would really prefer the Eclipse tooling 
to use the original .xtend source files for debugging/etc.

Applying xtend to GWT, it would probably result in the same issue--any 
errors/stack traces/debugging/etc. would be reported against the generated 
.java files, as GWT wouldn't know they should map back to whatever original 
.xtend source file.

Which, I dunno, I guess might be fine to get a better syntax, but I don't 
think is ideal. So I'm still looking for more suitable "Java.next" 
contender that could integrate with GWT.

In that regard, my current favorite is the scala-gwt project, which I've 
been helping out with a little bit. It is in the same early stages, so has 
a number of rough corners, but once you get it setup, doesn't have the 
.java vs. .xtend problem. Debugging happens in your .scala files, etc. 
Which is pretty sweet. The project just released a new 0.1-m3 milestone, so 
I'd encourage anyone here who's interested to try it out and offer feedback.

- Stephen

[1]: http://www.eclipse.org/Xtext/xtend/

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/wEF-0Vidxn8J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to