Beautiful Code

Java is well past being "on the edge" and went completely off the cliff with generics. It only gets esthetically uglier with each subsequent release.

"Things should be made as simple as possible, but no simpler." -- Albert Einstein

Something Java should have taken on long ago IMO.

Closures are ok, but most important things, missed in Java are delegation! Now you must implement all methods from interface, make class abstract or use adapter. But when you inheritance from another class, and your actual class can't be abstract you have the problem. You must then implement all method from implementing interface.

interface SomeListener{
void oneEvent();
void secondEvent();
void anotherEvent();
}

class SomeListenerAdapter implements SomeListener{
public void oneEvent(){}
public void secondEvent(){}
public void anotherEvent(){}
}

class BaseClass{
//important code
}

//Becouse in java there isn't multiple inheritance you must use interface SomeListener
class ActualClass extends BaseClass implements SomeListener{

public void oneEvent(){
//some action
}
//This methods are unused
public void secondEvent(){}
public void anotherEvent(){}

//Some logic
}

I wish that Java 7 have import alias functionality (import JMap = java.util.Map) - C++, C# have it and I don't understand why Java don't. This would be great to be able to name classes without worying about potential conflicts with eg java's standard classes (see AWT and Swing classes - swing uses stupid prefix J)

Never used Eclipse ? Try to click Ctrl + Shift + O and you will never care about imports ...

Marek, "import alias" may be nice for writing code, but not for reading code, especially other people's code.

Remember, code is read much more often then it's written.

I'm with you. I started using Java in '96 because it was clean and simple. Now...

The problem with elegance is that you can't make any money off it.

People buy software by the pound -- give them something simple and easy and they'll take it and run.

Hence, bloatware.

Hi, basically I agree that a language should be kept simple. That's why Smalltalk is my favourite language (yes it has its weaknessess but it's just beautiful to read). And I think the idea of closures is not inspired by functional programming languages but by Smalltalk, which was kind of the first OO language. It makes excessive use of closures and keeps methods really simple this way. Especially for operations on collections closures are a nice thing to have. For example, if you want to remove something from a collection in java you have to write:

Iterator i = list.iterator();
while(i.hasNext()) {
X = i.next();
if (...) { i.remove() };
}

With closures you'd have: list.remove([ :x | condition ]);

And the list of examples is almost infinite. I'd really welcome closures in Java.

best regards
Andy

We have people who complain Java is becoming a mess like C++ and we have others who campaign for modern features. Both are right. They just emphasize different aspects of the problem. Why should we have one language for everyone? Let's get a second "official" language for the Java platform. It's about time.

Of course, Java already has several third party languages. But Java API and frameworks are typically difficult to work with, without strong support from tools and for me, it is this deficiency that stands in the way of adopting a new language. A minimal feature for using any language with Java is good intellisense/code completion. Groovy is a good "made-for-JVM" language that blends well with Java code. Unfortunately, good open language-aware IDEs are lacking (the new beta of IDEA has some support).

A language can be good looking but not before it has implemented all tools needed.
My wish list to Java 7 would include Properties and Event Delegates (as C#)
But there is a main concern about Java: My most recently choice for client - server applications cannot be Java, due to massive resource eating VM. I think a general rewrite of the language himself to improve performance would be greater than "good looking"

I completely agree with you. A language should be well thought out enough that it doesn't need so many syntaxes and different constructs. They make the language murky and highly inconsistent. These issues should be addressed in architecture, not in the language itself.

C# is a perfect example of a good design (ironically based on java) that's been adhoc'd with everybody's wishlist, including conveniences that people wanted from other languages. It's a mess, and projects in C# from different teams at the same company might just as well have been implemented in different languages they're so different.

I'm totally disagree with closures on Java language. It only adds complexity and confusion to the developers community. If people wants functional programming, it maybe better to make another language for the VM instead of adding things that don't relate all in one language.

Closures are great in theory. I think that the proposals that Ricky Clarkson and friends are making for Closures in Java 7 are rather weak, appear to be pasted on top of the language, and aren't going to make a nice addition to the language.

Generics were fit in quite nicely, I believe, and the additional syntax necessary was limited. They rather cleanly managed to make everything else mostly work as is, and make generics work as you think they would (although generic methods are a bit tricky to grok at first, I suppose). But with this closure suggestion, that's clearly not the case.

Java 7 needs lambdas, not closures of the haskell nature. The semantics of a lambda, in my opinion, much more clearly and naturally accompany the existing semantics of the language. To paste some high level functional language behavior on top of Java is of minimal benefit. Creating lambdas and method references, more akin to the anonymous functions of java script, would provide for most intents and purposes the same functionality without having semantics that seem so foreign to the language.

Also great care needs to be taken when introducing this feature. Generics added strong typing for a lot of poorly handled cases in the language, and any form of lambda, closure, or support for method references should continue with this type-safe legacy. However I don't think pasting a qualifying token (the "=>" in ricky's examples) is the right solution. Why not extend the generic syntax instead, so the additional feature feels more natural in the language?

I came here from "theserverside" webpage that qouted the above post. Here is my personal take on this : Java 7 is a long way from making it big. There are too many features that have not even been considered. Will see.

I will Blog about this as well, just as soon as I see some more info. Great read, BTW. and Happy New Year

Hi Michael. I started working with Java little over two years ago in college. At first I found it difficult to come to terms with, especially since I was taught C++ before Java - which in most cases is the wrong way of doing things, as it often causes confusion - especially in my case! - surrounding classes and objects.

Now that I've graduated from college, I'm now reading into Java 7 - as all my college work was based on Java 5. A little outdated I know, but we were told 'it is the best' - I doubt this.

Anyway, just to say thanks for adding to the list of articles/blogs to read up about the latest production from Java.

Thanks again.

Whether of not Java 7 is beautiful remains to be seen. Though its extremely powerful - there are still limitations holding it back from being truly beautiful. Maybe we might need to wait for Java 8 or 9 before it can be honestly called a "beautiful thing".

Alex