9 ms·

Xtend – Modernized Java

106 points by eurg 13y ago

salvatoreromeo 13y ago
coming from java, xtend is probably the best choice right now (also compared to java8) because you are up and running in few hours. really! and the development time will decrease significantly. You can create full projects in a fraction of time. Active annotations are also very useful to generate common boring code (Logging, patterns, ...) also from configuration or HTML files, or to generate files like javascript to call your backend service. the only drawback is that it only works in eclipse. Eclipse has full support, meaning that debugging, refactoring, click from stacktrace and so on are available and work perfectly. just try it for 30 minutes, you'll not come back!
thescrewdriver 13y ago
Compared to other JVM languages Xtend seems to be seeing very little adoption or interest. I have yet to encounter anyone who's actually using it.
- IReadYourCode 13y ago
  A search on Github for Xtend classes reveals 10,502 results: https://github.com/search?q=class+extension%3Axtend&type=Code&ref=searchresults https://github.com/search?q=class+extension%3Axtend&type=Cod... This beats Ceylon by factor two (4,189 results) and is close to Kotlin (12,233 result).
- pjmlp 13y ago
  It is a me too language from Eclipse foundation without any clear roadmap why anyone in the industry would care to use it given the more mature JVM languages, specially given its dependency to Eclipse and generation of Java code instead of bytecode.
  - kitd 13y ago
    Xtext, the Eclipse/JVM language development toolkit behind Xtend, is in many ways more interesting than Xtend itself. In fact (I may be wrong) but Xtend was really done as an Xtext example/test/advertisement. I have used Xtend a little (not in production) and it was interesting when first introduced. I suspect Java 8 will make it redundant.
    - pjmlp 13y ago
      My feelings as well. I just looked into it as a possible language for Android development given the stagnation on Java compliance on the platform, but Kotlin looks much better suited for it given Google's investment into InteliJ.
antocv 13y ago
Everyone and their dog is writing a language these days. Oh well. Id rather improve on applications and libraries we already have.
- efdee 13y ago
  What is keeping you from doing that? Or did you mean that you'd rather have other people improve on applications and libraries for you?
- mattgreenrocks 13y ago
  > Id rather improve on applications and libraries we already have. Can you be more specific? Also, working on tooling is way more interesting than working on apps...at least for me. There are actually hard problems to solve ;)
  - chalgo 13y ago
    You're trying to invent solutions to problems that nobody have.
eurg 13y ago
Xtend seems to be a very conservative, but sensible iteration on Java. Does anybody have some experience with it, knows some pitfalls, etc.?
- creatio 13y ago
  I think its only usable with eclipse. I do wish it had ADT and pattern matching.
dtech 13y ago
I don't see any advantages in this over Scala.
- kitd 13y ago
  Many enterprise shops won't look too far beyond plain Java. Xtend is not as far beyond plain Java as Scala is. One of its selling points is that you can just generate plain Java from Xtend into your normal source folders. Yes, yes, I know enterprise CTOs need a good slapping, but at least this gives their down-trodden devs an option. As such, I think it will come under threat from Java 8 rather than Scala.
- ZoFreX 13y ago
  Probably easier to write for Android with Xtend than Scala.
  - bad_user 13y ago
    Why is that? Tooling support at this point is much better for Scala than it is for many JVM languages, including Xtend. Checkout: https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid You can do that in combination with IntelliJ IDEA for example, which has awesome support for both Scala and Android. Google's new Android Studio is actually the same as IntelliJ Android plugin that they distribute as part of their open-source distribution. It's also the best IDE ever.
  - lmm 13y ago
    Why's that? If you're worried about generating lots of extra inner classes, isn't that still a problem with Xtend? Other than that, what's the problem with using Scala on Android?
- coldtea 13y ago
  Not having to mess with the Scale typesystem is a great advantage.
  - klibertp 13y ago
weddpros 13y ago
I've used xtend last year, before I switched to Scala. Eclipse integration is better with Scala (autocompletion among others), and Scala has more to offer. Biggest pain point: stack traces point to the Java translations, not to xtend's source code. That made me switch to Scala.
- valevk 13y ago
  Could you tell me something about the difference between Xtend and Groovy. To me, Xtend looks like Groovy with a stricter syntax, and instead of directly translating to Java byte code, it gets transalted to Java source first.
  - IReadYourCode 13y ago
    Xtend is statically typed but your Xtend code can be as lean and concise as your groovy code because the Xtend compiler can infer the correct types for you. Because Xtend is statically typed, the Eclipse Xtend editor has quite an excellent autocomplete. For your cursors's location it can propose you a list of all valid keyword, methods names, filed names, local variable names, Class names, etc. And by excellent I mean: Autocompletion will not forget things and it won't show invalid proposals. No guessing! For Groovy this just isn't possible because it is mostly unknown to the editor which methods and fields an object has. It's only known at runtime.
    - klibertp 13y ago
      > For Groovy this just isn't possible It's true in general, but in most specific cases it is possible to statically analyse dynamic languages to the point of providing meaningful auto-completion. For example in Python-land there is Jedi (http://jedi.jedidjah.ch/en/latest/ http://jedi.jedidjah.ch/en/latest/), and also commercial Komodo IDE and PyCharm. This is done through static analysis, so that no code is ever run for auto-completion. So, while it's impossible in general case, it's perfectly possible to create useful auto-completion for dynamic languages. There are such tools for Python, JS and probably others as well.
- renszarv 13y ago
tinco 13y ago
"Modernized Java", it's basically a slightly uglier C#. Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.
- bad_user 13y ago
  Same can be said for the JVM vs CLR, only in reverse.
  - commentzorro 13y ago
    I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.
    - windust 13y ago
      Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
    - bananas 13y ago
      Technical aspects are almost irrelevant. For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM. The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box. A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects. [1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
    - 13y ago
reactor 13y ago
They surely need to find a solution for proper debugging. Nobody likes mental gymnastics needed when debug stack traces to a language other than the language you write the s/w in.
- IReadYourCode 13y ago
  Xtend isn't supposed to replace Java. It enhances it. That's why Xtend doesn't compile to byte code but to Java code. If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace. If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.
noelherrick 13y ago
What I would hope is that these features get rolled back into Java. Xtend could be a testing ground that shows how something would work, similar to the way browsers have their own proprietary implementations of an idea that then serve as examples to the W3C.
- thescrewdriver 13y ago
  I find it sad that some view JVM languages which aren't Java as a testing ground for features which could be added to Java. Other JVM languages are worthy of usage independent of the Java language. Not everything can be back-ported to Java and keep the language backward compatible.
  - pjmlp 13y ago
    The main problem is that the enterprise sees: JVM == Java and CLR == C# (or VB.NET for VB shops) Given the size and skills of the said teams, usually you cannot sneak in alternative languages anyway. So for many of us, regardless how much we like alternative languages, those are the ones we are allowed to play with.
- larsmak 13y ago
  ..which is exactly why we have scala, groovy, etc!
cpfohl 13y ago
It's like Coffeescript for Java... I hereby suggest it be renamed "Coffee".
- xutopia 13y ago
  That would be an evil prank on us all though... We'll have job offers with "12 years of Coffee experience with jQuery".
NanoWar 13y ago
What's that «guillemets» nonsense??
- IReadYourCode 13y ago
  It's finally a syntax that doesn't get into your way when you want to generate stuff. Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it. Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?> Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.
  - NanoWar 13y ago
    I can't find « » on my keyboard :(
    - IReadYourCode 13y ago
      If you press CTRL+SPACE the Eclipse content assist will insert a pair of « ». This only works when « » are valid, i.e. between ''' and '''. Wikipedia has a nice list of key combinations for each OS/language/keyboard: http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_a...
  - lmm 13y ago
    <? is easier to type and no harder to read than «.
    - txmikester 13y ago
      Sure, until you are trying to generate php. The templating engine is one of the parts carried over from the old Xpand project on which Xtend is based. Xpand's sole purpose was as a templating language for writing code generators in MDE projects, and as such they tried to make it easy to generate any kind of code, so they chose a non-ASCII delimiter. It's really not a problem in practice - type < and then ctrl-space and code completion will fill it in for you. The only real gotcha is that you have to make sure your project is set to use UTF-8 encoding, which unfortunately is not the default setting in Eclipse.
yawz 13y ago
This all looks OK to me but my first worry would be ease of debugging. I eyeballed the doc but couldn't see anything specific to debugging. Anyone has some experience they could share?
- IReadYourCode 13y ago
  You can debug Xtend code using the Eclipse Java debugger and debug Xtend code just like you would usually debug Java. During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.
th3iedkid 13y ago
MPS from jet-brains offers another good option something called baseLanguage with very good DSL equivalents for a lot of use-cases combined with one more called SModel language.But its not parser based one like xtend is , its AST based projection editing and manipulation platform.I've been learning it for sometime.
ninjazee124 13y ago
Better to use Java 8 with Lombok extensions.
- IReadYourCode 13y ago
  Did you have a look at Xtend's Active Annotations? http://www.eclipse.org/community/eclipse_newsletter/2013/march/article1.php http://www.eclipse.org/community/eclipse_newsletter/2013/mar... You can define your own annotation processors without having to understand Java Byte Code. With Xtend, an annotation processor is basically a small Java code generator that can add/remove/modify classes/interfaces/fields/methods. It's quite awesome for automating design patterns, e.g. generating getters/setters, observer pattern, property objects, delegators, etc.
- eranation 13y ago
  Nice, liked Lombok! But why stop there, Scala / Kotlin have everything you have in Lombok + Java 8 (case class in Scala and data class in Kotlin do basically what @Data does, in Scala there are no checked exceptions by default, and both have very good null safety solutions, albeit different approach) I think that if a company is open to using Java 8 + Lombok, then they should at least try out Scala / Kotlin (or even xTend) for comparison. If compile times are what worries you, Kotlin seems to be on par with Java compilation times, although I don't think Kotlin is production ready yet. (and it misses some Java 8 / Scala goodies such as parallel collections etc... though I'm sure JetBrains will add it soon...)
- fved 13y ago
  Anyone with any sense of taste avoids Lombok. It's a terrible hack. Rather use Scala which gives you far more. Maintaining Lombok + Java is a pain.
  - jonhohle 13y ago
    I dislike nearly everything about Lombok but `val`. Everyone else seems to be the opposite :-(
chalgo 13y ago
JVM languages seem to be the flavour of the month at the moment. Why do IDE makers feel the need to invent their own languages?
- IReadYourCode 13y ago
  Because many languages were designed with only the compiler in mind, but IDEs have requirements regarding language design, too… Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations. Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.
- yawz 13y ago
  JVM is the platform, not the goal. The goal is increased productivity.
kushti 13y ago
Oh, how many "next Java" options we have now... Kotlin, Ceylon, Gosu, Xtend, Java 8 :) (Scala not mentioned as I refuse to call it "the next Java", it's a new player)
- andrewflnr 13y ago
  Had not seen or forgotten Gosu. Thanks. Not that I'm likely to use it, Kotlin will be my first choice when I get back to my Android app.
  - stewbrew 13y ago
    Doesn't Kotlin target jvm 1.6?
    - andrewflnr 13y ago
      Honestly, I don't know. No one seems to have mentioned anything like that as an obstacle to kotlin on android, but I haven't done a ton of research.
txmikester 13y ago
I've used Xtend many times over the last few years. In fact, I'm using it right now at my "real" job for an internal project. I'm mostly a Clojure guy who still has to do a lot of Java work to pay the bills - when I can't use Clojure on a project, Xtend is a breath of fresh air. The current form of Xtend has been around for a few years now, and has steadily improved. Its origins go back many years, to the OpenArchitectureWare project where its predecessor (called Xpand) was used as a templating and model transformation language for the framework. Since oaw moved to the Eclipse foundation (5-6 years ago?), most of the tools have been dropped, reworked, or merged in with other Eclipse projects. Out of all this reworking for the new generation of Xtext came Xbase, which is an expression language that you can just drop into your DSL and have pretty much the entire Java language available (type system, expressions, scoping, etc.). If you're doing serious modeling/DSL work, this is about as good as it gets without going to something like MPS (which is awesome, but has its own set of limitations). Xtend is essentially this Xbase language in stand-alone form, with a few other goodies. There is also another project called Xcore which lets you create EMF models in plain text, mixing behavior along with structure, and it uses Xtend/Xbase as well. This is one of the reasons why I'm not too worried about Xtend becoming "abandonware" or anything like that - its main components are pretty essential to some key projects in the Eclipse ecosystem. So why wouldn't you just use (Scala, Groovy, etc.)? Well for one thing, I can (and have) bring Java developers up to speed on Xtend in about an hour (less if they know anything about functional programming). You can see some benefits in more concise code right away, and it only takes a couple days to get productive with it. No one can do that in Scala or Clojure. If you're looking for a strategic platform to build your next JVM architecture on - well, that's not really Xtend's place, you're looking for Scala or Clojure (hint - the latter). But there are a lot of projects where Xtend is a very nice fit, and as a bonus, I've found that developers who learn Xtend first have a much easier time learning a more "serious" language like Scala or Clojure later.
thomasfl 13y ago
Xtend seems for me to be like coffeescript. It gives nice syntax like blocks to java.
zak_mc_kracken 13y ago
Xtend has been around for a while and I think one of the reasons why it didn't catch on is because it generates Java, which severely limit its performances. These days, "modernized Java" would probably be Ceylon or Kotlin.

106 points by eurg 13y ago

coming from java, xtend is probably the best choice right now (also compared to java8) because you are up and running in few hours. really! and the development time will decrease significantly. You can create full projects in a fraction of time. Active annotations are also very useful to generate common boring code (Logging, patterns, ...) also from configuration or HTML files, or to generate files like javascript to call your backend service. the only drawback is that it only works in eclipse. Eclipse has full support, meaning that debugging, refactoring, click from stacktrace and so on are available and work perfectly. just try it for 30 minutes, you'll not come back!

thescrewdriver 13y ago

Compared to other JVM languages Xtend seems to be seeing very little adoption or interest. I have yet to encounter anyone who's actually using it.

IReadYourCode 13y ago
A search on Github for Xtend classes reveals 10,502 results: https://github.com/search?q=class+extension%3Axtend&type=Code&ref=searchresults https://github.com/search?q=class+extension%3Axtend&type=Cod... This beats Ceylon by factor two (4,189 results) and is close to Kotlin (12,233 result).
pjmlp 13y ago
It is a me too language from Eclipse foundation without any clear roadmap why anyone in the industry would care to use it given the more mature JVM languages, specially given its dependency to Eclipse and generation of Java code instead of bytecode.
- kitd 13y ago
  Xtext, the Eclipse/JVM language development toolkit behind Xtend, is in many ways more interesting than Xtend itself. In fact (I may be wrong) but Xtend was really done as an Xtext example/test/advertisement. I have used Xtend a little (not in production) and it was interesting when first introduced. I suspect Java 8 will make it redundant.
  - pjmlp 13y ago
    My feelings as well. I just looked into it as a possible language for Android development given the stagnation on Java compliance on the platform, but Kotlin looks much better suited for it given Google's investment into InteliJ.

antocv 13y ago

Everyone and their dog is writing a language these days. Oh well. Id rather improve on applications and libraries we already have.

efdee 13y ago
What is keeping you from doing that? Or did you mean that you'd rather have other people improve on applications and libraries for you?
mattgreenrocks 13y ago
> Id rather improve on applications and libraries we already have. Can you be more specific? Also, working on tooling is way more interesting than working on apps...at least for me. There are actually hard problems to solve ;)
- chalgo 13y ago
  You're trying to invent solutions to problems that nobody have.

eurg 13y ago

Xtend seems to be a very conservative, but sensible iteration on Java. Does anybody have some experience with it, knows some pitfalls, etc.?

creatio 13y ago
I think its only usable with eclipse. I do wish it had ADT and pattern matching.

dtech 13y ago

I don't see any advantages in this over Scala.

kitd 13y ago
Many enterprise shops won't look too far beyond plain Java. Xtend is not as far beyond plain Java as Scala is. One of its selling points is that you can just generate plain Java from Xtend into your normal source folders. Yes, yes, I know enterprise CTOs need a good slapping, but at least this gives their down-trodden devs an option. As such, I think it will come under threat from Java 8 rather than Scala.
ZoFreX 13y ago
Probably easier to write for Android with Xtend than Scala.
- bad_user 13y ago
  Why is that? Tooling support at this point is much better for Scala than it is for many JVM languages, including Xtend. Checkout: https://github.com/pocorall/scaloid https://github.com/pocorall/scaloid You can do that in combination with IntelliJ IDEA for example, which has awesome support for both Scala and Android. Google's new Android Studio is actually the same as IntelliJ Android plugin that they distribute as part of their open-source distribution. It's also the best IDE ever.
- lmm 13y ago
  Why's that? If you're worried about generating lots of extra inner classes, isn't that still a problem with Xtend? Other than that, what's the problem with using Scala on Android?
coldtea 13y ago
Not having to mess with the Scale typesystem is a great advantage.
- klibertp 13y ago

weddpros 13y ago

I've used xtend last year, before I switched to Scala. Eclipse integration is better with Scala (autocompletion among others), and Scala has more to offer. Biggest pain point: stack traces point to the Java translations, not to xtend's source code. That made me switch to Scala.

valevk 13y ago
Could you tell me something about the difference between Xtend and Groovy. To me, Xtend looks like Groovy with a stricter syntax, and instead of directly translating to Java byte code, it gets transalted to Java source first.
- IReadYourCode 13y ago
  Xtend is statically typed but your Xtend code can be as lean and concise as your groovy code because the Xtend compiler can infer the correct types for you. Because Xtend is statically typed, the Eclipse Xtend editor has quite an excellent autocomplete. For your cursors's location it can propose you a list of all valid keyword, methods names, filed names, local variable names, Class names, etc. And by excellent I mean: Autocompletion will not forget things and it won't show invalid proposals. No guessing! For Groovy this just isn't possible because it is mostly unknown to the editor which methods and fields an object has. It's only known at runtime.
  - klibertp 13y ago
    > For Groovy this just isn't possible It's true in general, but in most specific cases it is possible to statically analyse dynamic languages to the point of providing meaningful auto-completion. For example in Python-land there is Jedi (http://jedi.jedidjah.ch/en/latest/ http://jedi.jedidjah.ch/en/latest/), and also commercial Komodo IDE and PyCharm. This is done through static analysis, so that no code is ever run for auto-completion. So, while it's impossible in general case, it's perfectly possible to create useful auto-completion for dynamic languages. There are such tools for Python, JS and probably others as well.
renszarv 13y ago

tinco 13y ago

"Modernized Java", it's basically a slightly uglier C#. Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.

bad_user 13y ago
Same can be said for the JVM vs CLR, only in reverse.
- commentzorro 13y ago
  I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.
  - windust 13y ago
    Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
  - bananas 13y ago
    Technical aspects are almost irrelevant. For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM. The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box. A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects. [1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
  - 13y ago

reactor 13y ago

They surely need to find a solution for proper debugging. Nobody likes mental gymnastics needed when debug stack traces to a language other than the language you write the s/w in.

IReadYourCode 13y ago
Xtend isn't supposed to replace Java. It enhances it. That's why Xtend doesn't compile to byte code but to Java code. If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace. If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.

noelherrick 13y ago

What I would hope is that these features get rolled back into Java. Xtend could be a testing ground that shows how something would work, similar to the way browsers have their own proprietary implementations of an idea that then serve as examples to the W3C.

thescrewdriver 13y ago
I find it sad that some view JVM languages which aren't Java as a testing ground for features which could be added to Java. Other JVM languages are worthy of usage independent of the Java language. Not everything can be back-ported to Java and keep the language backward compatible.
- pjmlp 13y ago
  The main problem is that the enterprise sees: JVM == Java and CLR == C# (or VB.NET for VB shops) Given the size and skills of the said teams, usually you cannot sneak in alternative languages anyway. So for many of us, regardless how much we like alternative languages, those are the ones we are allowed to play with.
larsmak 13y ago
..which is exactly why we have scala, groovy, etc!

cpfohl 13y ago

It's like Coffeescript for Java... I hereby suggest it be renamed "Coffee".

xutopia 13y ago
That would be an evil prank on us all though... We'll have job offers with "12 years of Coffee experience with jQuery".

NanoWar 13y ago

What's that «guillemets» nonsense??

IReadYourCode 13y ago
It's finally a syntax that doesn't get into your way when you want to generate stuff. Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it. Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?> Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.
- NanoWar 13y ago
  I can't find « » on my keyboard :(
  - IReadYourCode 13y ago
    If you press CTRL+SPACE the Eclipse content assist will insert a pair of « ». This only works when « » are valid, i.e. between ''' and '''. Wikipedia has a nice list of key combinations for each OS/language/keyboard: http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_and_.22.C2.BB.22_on_computers http://en.wikipedia.org/wiki/Guillemet#Typing_.22.C2.AB.22_a...
- lmm 13y ago
  <? is easier to type and no harder to read than «.
  - txmikester 13y ago
    Sure, until you are trying to generate php. The templating engine is one of the parts carried over from the old Xpand project on which Xtend is based. Xpand's sole purpose was as a templating language for writing code generators in MDE projects, and as such they tried to make it easy to generate any kind of code, so they chose a non-ASCII delimiter. It's really not a problem in practice - type < and then ctrl-space and code completion will fill it in for you. The only real gotcha is that you have to make sure your project is set to use UTF-8 encoding, which unfortunately is not the default setting in Eclipse.

yawz 13y ago

This all looks OK to me but my first worry would be ease of debugging. I eyeballed the doc but couldn't see anything specific to debugging. Anyone has some experience they could share?

IReadYourCode 13y ago
You can debug Xtend code using the Eclipse Java debugger and debug Xtend code just like you would usually debug Java. During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.

th3iedkid 13y ago

MPS from jet-brains offers another good option something called baseLanguage with very good DSL equivalents for a lot of use-cases combined with one more called SModel language.But its not parser based one like xtend is , its AST based projection editing and manipulation platform.I've been learning it for sometime.

ninjazee124 13y ago

Better to use Java 8 with Lombok extensions.

IReadYourCode 13y ago
Did you have a look at Xtend's Active Annotations? http://www.eclipse.org/community/eclipse_newsletter/2013/march/article1.php http://www.eclipse.org/community/eclipse_newsletter/2013/mar... You can define your own annotation processors without having to understand Java Byte Code. With Xtend, an annotation processor is basically a small Java code generator that can add/remove/modify classes/interfaces/fields/methods. It's quite awesome for automating design patterns, e.g. generating getters/setters, observer pattern, property objects, delegators, etc.
eranation 13y ago
Nice, liked Lombok! But why stop there, Scala / Kotlin have everything you have in Lombok + Java 8 (case class in Scala and data class in Kotlin do basically what @Data does, in Scala there are no checked exceptions by default, and both have very good null safety solutions, albeit different approach) I think that if a company is open to using Java 8 + Lombok, then they should at least try out Scala / Kotlin (or even xTend) for comparison. If compile times are what worries you, Kotlin seems to be on par with Java compilation times, although I don't think Kotlin is production ready yet. (and it misses some Java 8 / Scala goodies such as parallel collections etc... though I'm sure JetBrains will add it soon...)
fved 13y ago
Anyone with any sense of taste avoids Lombok. It's a terrible hack. Rather use Scala which gives you far more. Maintaining Lombok + Java is a pain.
- jonhohle 13y ago
  I dislike nearly everything about Lombok but `val`. Everyone else seems to be the opposite :-(

chalgo 13y ago

JVM languages seem to be the flavour of the month at the moment. Why do IDE makers feel the need to invent their own languages?

IReadYourCode 13y ago
Because many languages were designed with only the compiler in mind, but IDEs have requirements regarding language design, too… Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations. Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.
yawz 13y ago
JVM is the platform, not the goal. The goal is increased productivity.

kushti 13y ago

Oh, how many "next Java" options we have now... Kotlin, Ceylon, Gosu, Xtend, Java 8 :) (Scala not mentioned as I refuse to call it "the next Java", it's a new player)

andrewflnr 13y ago
Had not seen or forgotten Gosu. Thanks. Not that I'm likely to use it, Kotlin will be my first choice when I get back to my Android app.
- stewbrew 13y ago
  Doesn't Kotlin target jvm 1.6?
  - andrewflnr 13y ago
    Honestly, I don't know. No one seems to have mentioned anything like that as an obstacle to kotlin on android, but I haven't done a ton of research.

txmikester 13y ago

I've used Xtend many times over the last few years. In fact, I'm using it right now at my "real" job for an internal project. I'm mostly a Clojure guy who still has to do a lot of Java work to pay the bills - when I can't use Clojure on a project, Xtend is a breath of fresh air. The current form of Xtend has been around for a few years now, and has steadily improved. Its origins go back many years, to the OpenArchitectureWare project where its predecessor (called Xpand) was used as a templating and model transformation language for the framework. Since oaw moved to the Eclipse foundation (5-6 years ago?), most of the tools have been dropped, reworked, or merged in with other Eclipse projects. Out of all this reworking for the new generation of Xtext came Xbase, which is an expression language that you can just drop into your DSL and have pretty much the entire Java language available (type system, expressions, scoping, etc.). If you're doing serious modeling/DSL work, this is about as good as it gets without going to something like MPS (which is awesome, but has its own set of limitations). Xtend is essentially this Xbase language in stand-alone form, with a few other goodies. There is also another project called Xcore which lets you create EMF models in plain text, mixing behavior along with structure, and it uses Xtend/Xbase as well. This is one of the reasons why I'm not too worried about Xtend becoming "abandonware" or anything like that - its main components are pretty essential to some key projects in the Eclipse ecosystem. So why wouldn't you just use (Scala, Groovy, etc.)? Well for one thing, I can (and have) bring Java developers up to speed on Xtend in about an hour (less if they know anything about functional programming). You can see some benefits in more concise code right away, and it only takes a couple days to get productive with it. No one can do that in Scala or Clojure. If you're looking for a strategic platform to build your next JVM architecture on - well, that's not really Xtend's place, you're looking for Scala or Clojure (hint - the latter). But there are a lot of projects where Xtend is a very nice fit, and as a bonus, I've found that developers who learn Xtend first have a much easier time learning a more "serious" language like Scala or Clojure later.

thomasfl 13y ago

Xtend seems for me to be like coffeescript. It gives nice syntax like blocks to java.

zak_mc_kracken 13y ago

Xtend has been around for a while and I think one of the reasons why it didn't catch on is because it generates Java, which severely limit its performances. These days, "modernized Java" would probably be Ceylon or Kotlin.