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."
enumerators are much better than just plain ints. Even though they may compile to the same thing, the compiler can do a little more checking on the enumerators, since it know the valid ranges for the enumerator so you don't have to explicitly check the range. You do check to make sure you get passed a valid value for all your int-as-enumerators? Don't you?
The metadata, auto-boxing, enhanced iteration looks like catch up with C#'s attributes, foreach, etc.
Where are true properties though?
During my time at telco, development costs were always a fraction of maintenance costs. Producing write-only code may be cute, and may cut back on other people using it, but it also cuts back on your own people being able to maintain it.
Oh, do I agree, in boldface.
Don't take life too seriously; it isn't permanent.
Hi,
FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly).
These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.
Is anybody else irked by generics? One of the arguments in C++/Java discussion that I've read was: "Java removes complexity of C++, while remaining OOP". Well, generics remind me of C++ templates, which where a bit hard for me to swallow. Not to mention that attached to variable name doesn't make code any more attractive to look at.
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time. Will generics become THE way, or just remain one of the options?
Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.
That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.
May no camel spit in your yogurt soup.
One may say so. You see, C# had all features mentioned in article excluding generics since Beta 2. I think this is more than a year.
It's more that C# includes a bunch of features that some java programmers had been asking for, and so does java 1.5. It's not like any of these features were out the blue in C#, they are mostly things people have been missing from other languages.
Some of this other stuff has been going on for ages - I'm curious about the metadata/declarative programming features. I've developed complete code generation systems for Java - the number of situations that require reams of very repetitive code in your average large-scale Java app is huge, and much of that can be automated. It would be great to see a consistent, standard system for doing this built in as a language feature rather than having hundreds of home-rolled systems everywhere, but the nature of many problems lends themselves to home-rolling. I can't tell you how many times I've written simple SAX parsers that spew out Java code, and rolled up an ant target to run it on some schema and package up the result. It's not clear from this brief example whether this is only for XML/RPC or whether there's an extensible metadata system that you can build on top of.
Then again, we should be careful not to roll too much into the language itself. I think generics, autoboxing, and enumerators are fabulous. Iterators I could give less of a shit over. Other stuff is great, but I question whether extending the language is the right mechanism. Much of the power and flexibility of Java comes from its simplicity. And most importantly, the ease of reading other people's code - there's far less stylistic variation because there are only N ways to do a task, rather than N! ways to do it, like in C++ (don't get me wrong, for a lot of tasks, I'd never dream of doing them in Java, like 3D programming). But it takes me about 1/4 to 1/3 the time to assimilate and learn a new Java API or library as it does to learn your average C++ API or library, and that's the appeal of Java.
Of course, I'll be thanking the gods that I never have to deal with the fugliness of casting and wrapping to move stuff between typed arrays and untyped Lists again.
Of course maintenance costs more than development, that's a given. But the thing which reduces maintenance costs is easy to read and understand code, coupled with good documentation.
The ultimate removal of "syntatic sugar" would take you down to raw machine code. I do not believe that would be easier to maintain than Java, or pretty much any higher level language. The aim of syntatic constructs is (or should be) to make it easier for the developer to express the algorithm clearly. It's not about saving typing (unless we're talking perl) and not about being smart for the sake of it, it's about making it easier to read and understand.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
As others have pointed out, moving move type information into the declaration allows the compiler to help eliminate several kinds of type errors generated by programmers.
Now, if you want a weakly/dynamically/non-typed language, you should use one, and deal with the inevitable tradeoffs. It's not like there's a shortage of non-strongly-typed languages out there.
AC, I agree that the current approach is a PITA. I would also be very happy to see a more terse way to express properties. But what you are doing in your example, is throwing the baby out w/ the bathwater.
Note that you now don't have anyway to specify access and protection! I had given a little thought to better ways to handle this, and even had an interesting brief email exchange w/ a C# engineer about it. For the protection aspects you could do something like [this is just a quick idea I cam up with:]
property access String name;
where access is one of {read, write, readwrite}
But note taht right away you have a problem -- no way to assign protection levels to the various access, which is really a cross-product. What happens for example if you want the getter to be public, but the setter to be private?
Also, note that you would also need semantics to handle overriding the property accessors. You could just say that the property access defines an equivalent to the getter and setter methods, but that can get weird and confusing very quickly. Think about the situation where you have an interface defining getters and setters and then you implement it by just providing the one-line property definition. That would not be very transperent TSTL.
All this is just to say that it is a noble goal, but not as trivial as it sounds at first glance. IMO, the C# "solution" is particularly ugly, and qualifies strongly for the "syntactic sugar" label.
FInally, as in my other note, good IDEs like IntelliJ provide very convenient ways to auto-generate these things. I care much less about this issue now that I am not having to type all this stuff out by hand!
The problem is that some syntatic sugar doesn't actually increase readability. Consider operator overloading. If your language has that, you can never again know what on earth is going on when you see x = y + z, unless you are aware of every operator overload which was used. Let's say y is a char* and z is an integer. Normally then the expression (y+z) would mean in C++ "a char pointer which points at the character at index 'z' of the string stored in y." But with operator overloading in the language, you can never be too sure. Maybe somewhere in the code the programmer thought it would be a good idea to say that char* plus int really means "convert the string to integer with atoi(), then add the integer second argument to it, then convert back to string form and return that."
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
x++ is the standard way of writing the statement, used by most coders in preference to ++x (in my experience anyway.) The fact that there is such a convention is reason enough to use it IMHO; if I see ++x in a piece of code, it's a warning that something unusual is going on.
As for your equality test examples, putting assignments in if statements in Java gives you a compile error. Also, it's quite rare to ever put a specific number in an if statement, and if you do it's likeley to be 0.
... but man do I hate the enhanced for-loop syntax. At some point you have to give up perfect backwards-compatibility for readability. One or two new keywords would do a world of good.
for (TimerTask task : c)
task.cancel();
becomes
foreach (TimerTask task in c)
task.cancel();
what if microsoft buys sun?
.NET, and Solaris is the biggest commercial competitor to Windows Server.
What happens when matter meets anti-matter?
1) Microsoft wouldn't have a clue how to manage Sun. Sun is a hardware-engineering firm with a different corporate culture than Microsoft.
2) Most of Sun's employees would either quit or sight tight until they can quit.
3) Sun's customers would leave for IBM or HP; they would not eat MS' dog food.
4) The Justice Dept. would actually do something for once, because J2EE is the only big competitor to
what if ibm buys sun?
Bye bye, UltraSPARC. This would probably alientate lots of Sun customers.
Java would cease being as open as it is. The JCP would close down.
Healthcare article at Kuro5hin
memory leaks (StringBuffer ToString anyone?).
Sorry, not a bug. What happened is the JDOM folks (gambling) relied on the internal implementation of StringBuffer and not its public API. That also broke JDOM for 1.2 jvms, which implemented StringBuffer differently. The internal implementation changed in 1.4.1, hosing the JDOM folks. Sun's only mistake was making this change in a minor version instead of a major one.
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
You know, I've just got to say this.
Each and every point on this list of additions to the languages addresses problems that I have personally run into in my use of Java at work. These things will make the writing and maintenance of java projects small and large much, much easier.
Generics: Thank you God, yes! Having to explicitly cast objects out of Containers is tedious and error-prone.
Iterators/Enhanced 'for': Make iteration much easier to read and understand.
Autoboxing/Unboxing: This helps alleviate the enormous kludge that is the Object/primitive dichotomy. Casting to and from wrapper types just to pass ints, etc. around really sucks.
static import: Not having to fully specify tedious class names to access static members is a big boon for making stuff digestible and easy to read.
Metadata: Writing boilerplate sucks the big one. How many hours have I lost writing boilerplate? Way too many. Having language support for generating code from the metadata cuts my implementation times way down.
I could sit here and argue with folks about the 'new Java' versus C++ or C# or Smalltalk or whatever endlessly. But man, these things sure make Java a whole lot more pleasant to use.
-- Flaw
My vote would be to freeze the Java language (perhaps after 1.5) and concentrate on the following:
...
* memory footprint
* runtime efficiency
Leave it alone (the sooner the better) except for improvements in the implementation.
This is a good idea. However, my vote is to concentrate on Java3. Screw backwards compatibility going forward and fix the standard library. Throw out the crap that has come along from JDK 1.0-1.1 and make the platform consistent. Why do we have both Enumerations and Iterators? Why are constants mostly UPPERCASE but sometimes lowercase (see java.awt.Color)? What about Thread.stop()?
This cruft is never going to go away until Sun releases a version of Java that isn't backwards compatible. Perl and Python do it. Java should too. It makes for a much cleaner language for new projects. Old projects may get stuck on a Java2 platform until the owners invest the time to convert them, but that's the way things go. It's time to clean out the cobwebs in Java and make better use of the new features.
Once all the old crap is gone, then it will be time to freeze the language and standard library.
47% of all statistics are made up on the spot.
Your answer highlights the very reason that C macros are a bad idea. You say:
#define NOTHING ;
...
if ((flag & VAL1) || (flag & VAL2)
NOTHING;
Correct me if I'm wrong, but that's going to put two semicolons after the if---not itself an error, but it's going to block the else from working properly, since the second semicolon is a(n empty) statement after the end of the if clause!
In general, using macros in this fashion is dangerous and difficult to maintain, because it's not known what exactly is in the content of the macro. If a shortcut is at least part of a language, then a maintainer has some reasonable chance of understanding a piece of code as written without going hunting through header files. (Though of course one of the major complaints against perl is that there are so many shortcuts that are part of the language that nobody knows them all, pretty much reducing us to the previous problem.)
``This, too, shall pass.'' ---Eastern proverb
In the old days when people talked about Linux, there was an expression "What about the big pink elephant in the middle of room" and it was referencing the fact that Linux did not support truetype fonts and font aliasing. Now some of that has been fixed, but Java still has its big pink elephant. Here are some of the things that people don't talk about.
The memory foot print for loading Java is 20meg + and growing. I am part of a team that has been developing a complex Java application for the last few years and we have created about a 3meg library (and it probably does at least as much as the more popularily used Java classes). I have looked at some of the source code for the core Java libraries and it is clear that a good rewrite could reduce this footprint by a factor of 2 to 4. Currently, C# loads with a footprint of 2 meg to 4 meg. Most other scripting languages usually have engines that are about the same size. To put it simply, the base core Java libaries are unjustifiably large. Maybe if Java were truly open source this could be addressed, but of course Sun doesn't even believe in submitting Java to a standards board.
You cannot load the Java VM once and run multiple processes (note "processes", not "threads") from the same Java VM memory footprint. I hear that such a thing is becoming possible for C# on Linux. You would have to build all the core Java classes into a "DLL" or ("so" on Linux), but that shouldn't be so difficult.
You still cannot do basic OS operations in Java without writing your own JNI library. The one that stands out is the inability to get the ID for the current running process. The "nio" package has corrected some of these issues, but the "nio" package should be the "io" package instead of having two separate packages (similar to AWT vs. Swing).
Window focus handling is still terrible. Ever have two frame windows up, have a modal dialog pop up on one frame while you were looking at the other? The frame window without the popop modal dialog becomes unresponsive and the other frame cannot be reached by tabbing through the windows. Only if you are lucky and that window is still visible on your desktop can you successfully reach it. Also, if a user clicks on a button that generates a modal dialog, the frame is only locked out from user input once the dialog manifests. This creates the infamous "double" clicking problem.
Java's package management is still primitive. If you want to do anything more subtle then using the classpath to load in custom libraries, you have to write your own class loader. Having an auxillary file specifying parameterizable rules for class loading would be nice. It would also be nice if you could ask a running Java process what packages it had loaded (and metadata about them such as location and version). Compare this to C# (or the way some of the web server oriented scripting languages work).
Some of the basic core library functions have some major weaknesses. For example, the Hashtable should be written as a native object when using String lookup keys and also allow you to dictate the algorithm for creating hashes (ex: use first 8 characters, last 8, or middle 8). There should also be a non thread safe version as well as a thread safe version. The lack of such a natively implemented primitive object is one of the big reasons why some less cleverly implemented scripting languages (such as python) can beat Java in performance on many web applications. In general, the core collection classes should be implemented in pure optimized (down to the actual chosen assembly code) native code.
Many of the utility libraries are broken in fundamental ways. Send back a badly formed response to the HTTP library and you go into an infinite loop when it falls into its keep-alive/retry logic. Date parsing is still behind what is available in the C standard library. Locale specifications do not allow you to independently specify date formats, language, floating point format, currency format, and time zone. You get o
I always get the creeps when I see if( xxx ).
It is as if "if" is a function putting the parentheses like that.
foo( xxx ) is a function call
if ( xxx ) is a statement which gets a block in parentheses.
I couldn't resist. I have to fight this good fight every day against some of my colleages.