Eclipse Xtends Java
A plugin layer to simplify development
Agentless Backup is Not a Myth
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”.
Xtend ships as a set of plugins to an Eclipse install already running Java Development Tools (JDT). The developers say it “complies to readable Java code”, with support for familiar Eclipse Java IDE features like syntax coloring, content assistance, rename factoring and so on.
It maintains Java’s static typing, but 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”.
It supports direct access to Java properties, allowing a more “natural” statement like person.name=”Foo” to replace person.setName(“Foo”).
Features that Xtend adds to Java programming include closures, a more “elegant” Switch expression, Template expressions and Extension methods. ®
Eclipse describes Xtend’s library “a thin layer over the JDK” that “interacts with Java exactly the same way as it interacts with Xtend code.” Xtend code is also callable from Java. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Scala?
So what was wrong with Scala then? Too hard? They don't even mention it on the site.
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".
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.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
