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."
check out eclipse -- a very sweet java IDE.
http://www.eclipse.org/
AFAIK they will not be breaking existing code... If anything, they had to go out of their way (e.g. the ugly foreach statement) to ensure backward compatibility. In 1.4, the assert keyword might have caused problems, but now I don't think that's the case.
This is what he said about Java and the likes.
Also here.
Hi,
;-)
Well, generics remind me of C++ templates
They're not quite the same; C++ templates are essentially glorified preprocessor macros with
some relatively small checking and a rather baroque
underlying functional language. Generics are more
concrete than that.
Not to mention that attached to variable name doesn't make code any more attractive to look at.
It would be really neat to have type inference there
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time.
That's the idea, and that's also what I try to do when writing programs. Why should I have to write half a dozen test suites for some simple program property if the type checker can tell me whether it'll work right?
Remember: Compilers don't do type checking just to optimise, but also to catch programming errors. And Generics allow you to catch a much more interesting class of these.
-- Christoph
Metadata
This is.. well.. strange. I didn't see the syntax for doing something like this. If it is just keyword/code replacing, then an #include directive would work just as well.
IMO, metadata is the coolest thing. It's a feature of C# which has had little recognition despite its coolness.
In both Java and C# you can use reflection to find out information about a class (class name, method names, etc). Attributes/metadata allow you to attach information to just about every element of a class/struct so that it can be queried dynamically using the reflection apis.
Imagine them as JavaDoc tags that aren't discarded at compile time but are instead compiled into a class's meta data. They'll do for source code what XML did for HTML -- give more meaning to the code.
Here's an example of using attributes/metadata to simplify XML serialization:The C# XmlSerializer class dynamically generates the IL that will do the serialization so it is *very fast*. It knows how to map the field names to element/attribute names by inspecting the attributes.
Some other obvious uses include object/relational mapping (no need for external XML mapping files) and XMLRPC (just mark a method as Remotable!) etc. You can imagine infinite other uses for attributes/metadata.
I'm not sure how it works in Java but in C#, attributes are simply classes (usually with a name ending in 'Attribute'). You can define your own custom attributes and your own classes that work with them. It's very cool.