Slashdot Mirror
Summary of JDK1.5 Language Changes
An anonymous reader writes "Over at java.sun.com, there's an informative article about the new features in JDK1.5. Some of the changes like generics are nice and should make some things easier. Some of the enhancements to me are purely sugar, like enumerators. When it comes down to it, once the code is compiled, it's the same. The thing I hope is, some of this new syntactic sugar doesn't result in more obfuscated code. Unlike some people, I feel using programming shorthand leads to increased maintenance. This is especially true when you have to debug a complex application."
Agreed that it's a great feature. I use collections all the time and not only is it time consuming to keep casting (especially when you write out long class names like I do...) I'd say a huge % of my runtime errors are from bad casting. I'm definitely looking forward to this. As far as the bytecode specs go, I don't see that this will cause much change at all. The compiler should do the same thing it's always done.
May no camel spit in your yogurt soup.
I think the new additions are great (except, perhaps, the autoboxing stuff). But I'm missing a fix for that extremely common javabean convention: get/set methods.
/**
/**
/**
/**
To add a property, say a String called name you have to write:
* The name of this object.
*/
private String name;
* The name of this object.
*/
public String getName() {
return name;
}
* The name of this object.
*/
public void setName(String name) {
this.name = name;
}
That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.
This could easily be reduced to something like:
* The name of this object.
*/
property String name;
expanded to exactly the same code as above by the compiler. Incredibly useful if you're, say, writing a lot of value objects in a j2ee scenario.
Also, it's statically typed. It's so .. annoying to have to typecast everything
:)
Typecasting is a tool -- do you really trust the compiler to recognize exactly what you mean in every scenario, throughout your hundereds of thousands of lines of code? I don't want to have the compiler (or run-time environment, or interpreter, whatever) to "guess" at what I mean -- I want to tell it exactly what I mean.
<flame> Perhaps this is why huge applications are usually written in languages requiring typecasting, and the "looser" languages are usually relegated to simple task duty.</flame>
10b||~10b -- aah, what a question!
One of the coolest new features of JDK 1.5 is the completely reworked concurrency stuff (JSR 166). I just listened to Doug Lea (spec lead) give a talk on this very subject and I'm pretty convince this will rocket Java performance way up for a lot of the collections stuff, concurrent programming, etc.
/ oswego/cs/ dl/util/concurrent/intro.html
:)
Bascially, the goal of JSR 166 is to do for concurrency programming what JDK 1.2 did for data structurs (Collections stuff). The gist is, you'll never need to use "new Thread()" or "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc. Also, queues are *completely* reworked to be ultra scalable.
JSR 166 is based on Doug's concurrency package:
http://gee.cs.oswego.edu/dl/classes/EDU
OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives.
Cheers!
I'd say that "++x" is actually the "best" way because it puts things in verb-noun order, which I'm used to as an English speaker. "x++" is noun-verb, which feels strange to me. "++x" reads as "increment X", while "x++" reads as "x. increment it".
(Just goes to show there will be differences of opinion and no such thing as "the" right way. Here's another example:
if( x == 5 ) { do something }
versus
if( 5 == x ) { do something }
Some prefer the second way because it puts the term which cannot be a valid lvalue on the left side, thus if you make the common typo of "=" instead of "==", you will get a compile error from it, which wold not happen for x = 5. But, it looks very odd to write it 'backward' like that, so some say the readability of doing it the 'dangerous' way makes it worth doing it that way.
There is no such thing as "the" best way, not even in Java.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
They're actually objects (you can put them in collections, for instance), they can have fields, methods, and constructors, etc. It's just that the compiler takes care of creating the instances and all, plus you can use them in swtch statements because the compiler knows they're enumerated.
Evil thought: you could get relatively nice-looking static instances with methods if you combined enums with anonymous inner classes...
I don't use ints for my enumerations anymore after reading Josh Bloch's Effective Java. The type-safe enum pattern he recommends is fantastic.
For those not sure exactly how it works, you simply create a class to represent an instance of the enum, and you make the constructor private so that no one can create their own instances. Then you just provide a public static instance of the class for each enum.
I used this pattern simply to achieve its intended effect of providing an enumeration, and then later found that by adding methods to the class, I could even give behaviors to the enumeration instances! Try doing that with an int. This was far more elegant than creating a giant "if" statement and performing conditional logic to test the value of the enumeration, because I simply used a polymorphic method call.
An example:
You get the main idea. No, not as fast as an int, but far more powerful.
"First you gotta do the truffle shuffle."
This is a fine alternative ... but cumbersome, and indeed once you add the toString() methods and other such niceties, it's approaching messy. The fact that a single statement now can offer all of these features is outstanding.
;)
It's nice to see Java stealing something from C# for once
(Score:-1, Wrong)
Metadata has been supported by the Java VM since the beginning, and JSR 40 (the metadata stuff in the language) has been around since 1999. It is _very_ doubtful that Java got this from C#. I will grant you that it probably forced issues a bit, though :)