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."
I think Generics is going to be a really nice long awaited feature. I am wondering if this type of change is going to require a modification to the bytecode specification. If that is the case, then new code bytecodes will not work with older bytecodes. Does anyone think that Sun can pull this feature off without a change to the bytecode spec? Would this be major compiler change?
These new java features or shortcuts whatever reminds of C++... Is Java going to come with "Pointer" manipulation features later on? Will java become the next C++ and will be extremely tidious to program with? Overall, change is good... :)
buffering...
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.
It's true that wading through 20 different ways of doing the same thing in one program can really be maddening, but within reason some of these shortcuts should exist, and should have from the beginning.
Every language has idioms, and a programmer should use those idioms in preference to other allowable ways to do things unless they have a good reason. It's all just part of good style.
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...
One of things that makes older more mature languages like Common Lisp (and perhaps Smalltalk) nice to work with is a feeling of both having really solid implementations and not breaking legacy code.
I like the idea of boxing and generics, but, these changes will affect old code (probably?) and the platform in general.
My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:
I would not like to see Java become a language designer's playground.
Because of great infrastructure software like servelt/JSP containers, (perhaps EJBs :-), XML utilities, solid web services support, etc. Java is a great platform.
Leave it alone (the sooner the better) except for improvements in the implementation.
-Mark
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)
"Shortcuts" are not the problem. Stupidity is the problem. A good programmer, or at least a kind programmer, uses "shortcuts" so that somebody else can figure out what's going on without having to everything about an object.
...}.
Enumerated types will save your ass the first time you change databases or some project manager adds a new "status level" in between DONE and FINISHED. They are much faster than using internalized strings, which is how I had been testing for this crap. Remember, once they hit the object code they're just constants anyway...
Foreach was easily the coolest thing about C# when I started using it, indexers were the second, and the code they create is FAR more maintainable than for(Object o = someList.FirstItem(); o != someList.LastItem(); o = someList.NextItem()){
Automagic "boxing" is a beautiful thing for newbie coders...I have had to teach so many the difference between a Byte and a byte that it isn't funny. I intend to use it, too...we pass in and out of the classes for char, int, byte, bool etc so often it makes sense to have the compiler/VM do our dirty work for us.
And generics...well, they look real queer in Java, where we've never used the syntax before. But they will save our behinds on reuse! Besides no doubt being faster, it will make more sense when typing collections of inherited objects. We have a BaseRecord class. We have an optimized BaseRecordColl class, usually full of different types of ChildRecord classes. If we can write the one collection class, and not have to explicitly cast each child op, it will save time, space, and hassle...and avoid calling the superclass methods of uncast subclasses!
Metadata is the only ingredient here that seems like it could cause trouble, and if it does it will be because people are using it wrong. Java is not a language that inlines...that's the whole idea of the JIT...and with today's cut and paste GUI IDEs, there's no need for programmers to use the lazy C declarations of the past. If people start doing so because it's neat, just nip it in the bud. Find/Replace when the code hits your desk. Eventually they'll get the hint.
Hey freaks: now you're ju
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 :)
Using the switch statement automatically means the programmer has slept through the OO class.
You simply do not need to use switch when you have polymorphism, which is a much more powerful mechanism and allows for much nicer scalable, maintainable, and readable code. Of course, this assumes that one has an understanding of OO.
If there is a problem with safe enums, it is with serialization and deserialization. There are a number of solutions available for that, however. Personally, I feel that those should have gotten in the Java libraries, not enums in the language, but oh well.
available such as , something that the safe enum provides, unlike the enumerations.
When will Java support shared jar files that work like shared objects or DLLs in operation systems?
IMHO this is one the main shortcommings of Java. Every jar file is loaded into every process causing a huge memory footprint and long startup times.
When playing around with some java shells, that only load classes once and simulate processes as threads, I saw simple swing applications load in 0.1 secs and other significant speed ups.
I was hoping for it in 1.4.x and now it seems it won't even make it into 1.5. I realize that it will be hard to implement this in a platform transparent way.