Feeds

back to article Eclipse Xtends Java

The Eclipse Foundation has quietly launched a new language, Xtend, which it says is designed to address shortcomings of Java without replacing it. The aim of Xtend is to create more readable code, to add features that Java needs but doesn’t have, and to offer “a convenient alternative in situations where Java doesn’t shine”. …

COMMENTS

This topic is closed for new posts.
Silver badge
Thumb Up

It's like making an AR-15 actually work, but I still like to hear that.

A move in the direction of Groovy without the full uncertainty about what the code will actually do at runtime that comes with it.

0
1
Anonymous Coward

The actual reliability of the AR-platform...

What are you doing wrong..? My ARs have always run flawlessly. Seriously.

0
0

Most of these features were left out on purpose

The main point of Java (outside of Android) is that you have a very picky, explicit, and yes, redundant language where everything is fully spelled out so you can let hordes of incompetent corporate coders work on a project without stepping on each others' toes too much.

Though I guess if you're used to Java and need to run on the JVM there's nothing wrong in moving Java back towards being fun to program with a preprocessor like this, since the enterprisey types can just ignore it. I can see where it'd make Android programming much less tedious.

3
3
Coat

Still no *cough* unsigned *cough* :(

1
0
Bronze badge

Pardon?

"It supports direct access to Java properties, allowing a more “natural” statement like person.name=”Foo” to replace person.setName(“Foo”)."

I'm halfway (I hope) through a Java course, in which it's fairly plain that you -can- expose class properties when you write a program but you're advised not to, evidently so that you can change what they are and what actually happens in setName("Foo"). Validating "Foo" as an acceptable name value comes to mind, as does the vast topic of the actual forms that personal names can take. You could have behind it givenName, parentName, nameOrder, ...

4
2
Anonymous Coward

Seems pretty obvious

... that it's all about exposing the properties' accessors with a different, less burdensome syntax.

1
0

@ Robert Carnegie - how this could work

Just guessing, but if "name" is a private string, it could assume that thing.name = "abc"means you followed the bean naming convention and replaces .name = "abc" with .setName ( "abc" ).

JSTL does the same with the getter: ${ thing.name } returns "abc" .

If you mispell the getter as getNAme(), and name is private, it won't work

0
0
Silver badge

Properties vs Accessors

Yes, the get/set method syntax is a bit burdensome. But the alternative has its problems, too.

When coding in C# I found myself forced into silly naming conventions to prevent conflict and ambiguity between member field names and property methods. (Made ten times worse by a ridiculous Style Nazi add-on to Visual Studio that used to bitch about naming conventions - probably written by the jerk who did the grammar warnings in MS Word.)

The problem rarely arises when using the public interface to a class. Few experienced coders expose fields these days. But it needs to be clear in member methods whether we're accessing the field or the property.

Given the choice between get/set and having to call fields things like "mName", I think I prefer the former. It's mainly because "getName", "setName" and "name" have a relationship that's clear from reading them, but also because, in my heade at least, "mName" sounds like a cross between "M'Lud" and "My Computer".

3
0

Re the properties access, what it means is that if you would have written a simple setter such as setName(String name) {this.name=name}, instead you just don't need to.

If on the other hand you want to do something more advanced (eg adding validation etc), I *assume* you can write a setName(String name) method like normal. You would still only ever do person.name = "Foo" on the calling side though.

The PlayFramework already does this and once you get your head around the fact that you aren't directly accessing the class's fields even though it feels like you are, it works really well.

0
0
WTF?

Scala?

So what was wrong with Scala then? Too hard? They don't even mention it on the site.

4
0

Not Invented Here

Would've been better to put the resources into improving the IDE support for scala et al instead of letting the plugin developers make their own pet language.

0
0

comparisons with C#

It's interesting to note that as a dictatorship, MS has unilaterally added a lot of really nice features to C# without getting stuck in a lot of 'democratic' bickering about the best way to do things and without forcing C# developers into decisions as to which unofficial add-ons to work with.

I'm not a fan of MS and their practices by any means but it does illustrate that there is a downside to the "community" approach to standardization.

2
0
Coat

http://xkcd.com/927/ This is relevant as ever.

0
0
Joke

creates “type inference” to reduce the amount of redundancy in Java code, with the foundation stating that “a lot of the information written down in a Java file is actually technically redundant”.

So, that would be about 100% of it then.....

1
1

Project Lombok

Sounds a bit like Project Lombok

http://projectlombok.org/features/index.html

which runs as an AST transformer. Source code looks different but the AST navigator shows plain vanilla Java structure underneath.

0
0

"we recommend Guice"

Oh well, they just lost all credibility as far as I'm concerned.

1
0

I for one..

Quite like guice.

Compiler checked config instead of an XML file. Seems like a good idea to me if it fits with your app.

0
0
Meh

Can we have "Xtend lite" with only SOME of the features?

Some of the features look nice in principle, but some others are, in my opinion, unnecessary and prone to obscure bugs due to the generated Java code being subtly different from what was expected.

In particular, I *hate* the "new" switch - it looks like a shorthand for consecutive if sentences (and that's probably what it will compile to, anyway), {liberating us from | missing the point of} the fact that a switch statement is supposed to be a shorthand for evaluating a single expression.

And while we're at it, Xtend could add a REPEAT/UNTIL sentence (to {be synonymous with | replace} the do-while one).

And something that would be actually VERY nice would be to add the capability of returning two/three/N objects from a method in a single declaration, instead of having to create a TO for that purpose (or an Object array). Something like this:

public String,boolean,int whatDayIsIt(Date d) {

...

return dayName(d.get(Calendar.DAY_OF_WEEK)), isItHoliday(d), daysUntilChristmas(d);

}

to be used like this:

myDay, holiday, days = whatDayIsIt( new Date());

In the end, what really matters is oldtaku's opinion ("The main point of Java (outside of Android) is that you have a very picky, explicit, and yes, redundant language where everything is fully spelled out so you can let hordes of incompetent corporate coders work on a project without stepping on each others' toes too much."). "Free form" Java wouldn't be good news, I think.

0
0
This topic is closed for new posts.