Forgot your password?
Java Programming

Summary of JDK1.5 Language Changes 839

Posted by michael
from the better-faster-stronger-more-caffeine dept.
An anonymous reader writes "Over at, 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."
This discussion has been archived. No new comments can be posted.

Summary of JDK1.5 Language Changes

Comments Filter:
  • enumerators (Score:4, Insightful)

    by billnapier (33763) <napier.pobox@com> on Friday May 09, 2003 @12:50PM (#5919637) Homepage
    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?
  • by PHAEDRU5 (213667) <instascreed@gmai l . com> on Friday May 09, 2003 @12:52PM (#5919657) Homepage
    ...he's forcing improvements in Java.
  • Agreed.. (Score:5, Insightful)

    by MilesParker (572840) on Friday May 09, 2003 @12:55PM (#5919671)
    ..Thought C# has some nice innovations, one of my big problems with it is that so many of its new 'features' are so much syntactic sugar. One of the big things I appreciate about Java is that there is typically onyl one right way to do something; a big change from C++ for example. Plus, modern IDEs like IntelliJ make it very easy to construct iterators and such [Ctrl-j itar..] That said, I don't think that the majority of the Java improvements are really sytactic sugar; things like generics will be very positve improvements. And its very important that Sun keeps up these improvements -- as long as they continue to be well thought out. Ideally we will continue to have a fairly state-of-the art language without any fluff.
  • by earache (110979) on Friday May 09, 2003 @12:56PM (#5919677) Homepage
    The metadata, auto-boxing, enhanced iteration looks like catch up with C#'s attributes, foreach, etc.

    Where are true properties though?
  • Re:enumerators (Score:2, Insightful)

    by Anonymous Coward on Friday May 09, 2003 @01:01PM (#5919720)
    It's preference right. Forcing some one to explicitly check isn't necessarily a bad thing. Iterators get too much flack, but it does change the programmers mindset. I would prefer programmers think carefully about what they are doing and not rely mainly on convienance, because when a bug does appear, it is harder to debug. But it all goes back to good programmers. bad programmers will make any language a nightmare.
  • by NReitzel (77941) * on Friday May 09, 2003 @01:05PM (#5919758) Homepage
    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.
  • by jameson (54982) on Friday May 09, 2003 @01:05PM (#5919760) Homepage

    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.
  • by Usquebaugh (230216) on Friday May 09, 2003 @01:05PM (#5919762)
    Code should be written so it can easily be read by a human and incidentally by a machine.
  • Uglification? (Score:5, Insightful)

    by oblom (105) <miscalculation@gmail.c3.14om minus pi> on Friday May 09, 2003 @01:05PM (#5919763)
    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?
  • Re:enumerators (Score:2, Insightful)

    by MilesParker (572840) on Friday May 09, 2003 @01:06PM (#5919775)
    Ya, its funny, enumerators were always one of the first things to gome up when people were griping, and has been the source of a lot of discussion re: workarounds. IIRC, Gosling wanted this in from the beginning, but they ran out of time..
  • by Knight2K (102749) on Friday May 09, 2003 @01:07PM (#5919784) Homepage
    I sure you have a valid point in general, but I'm not sure if this is a concern with the changes described. The description of the features in the article indicate to me that your concerns were taken into consideration. For instance, they explicitly mention that foreach and in weren't added as keywords to avoid killing programs that may have used these as variable names (kinda lousy variable names if you ask me, but I'm sure it happens).

    Looking at the examples in the article, I didn't see anything that would break the semantics of already existing code... assuming the generics feature uses Object if no other class is used.

    Do you have an example of the proposed semantics breaking some existing code? I would be interested in any examples and I'm sure the JCP would be too. I'm certainly not willing to go along with the JCP blindly if there is a practical, concrete example of where they are going wrong.
  • by cheezfreek (517446) on Friday May 09, 2003 @01:07PM (#5919785)
    As a compiler writer, I found this sentence to be particularly hilarious:

    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.

  • by Ageless (10680) * on Friday May 09, 2003 @01:08PM (#5919790) Homepage
    I might have missed something in the article, but as far as I could tell nothing existing breaks. They even mentioned that they worked very hard to make sure that was the case.

    What part of the new syntax would cause old code to break?
  • Re:Generics (Score:3, Insightful)

    by gray peter (539195) on Friday May 09, 2003 @01:09PM (#5919806) Homepage
    Read the article :-)

  • by Hobbex (41473) on Friday May 09, 2003 @01:10PM (#5919810)
    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.
  • by cprice (143407) * on Friday May 09, 2003 @01:11PM (#5919823)
    1.4.x is rife with issues; corefiles or memory leaks (StringBuffer ToString anyone?). I sure hope that this is a stability improvement release rather than another round of 'improvements'.
  • by pygeek (649716) on Friday May 09, 2003 @01:11PM (#5919824)
    Java is an OK language for teaching programming basics, but it's just too much bondage and discipline for my taste.

    You're forced to do object oriented programming. OK, I can respect that - but Java is not consistent. Everything is not an object, and it's just so damned ugly when you have to wrap an int in an Integer.

    Also, it's statically typed. It's so fucking annoying to have to typecast everything - I know I have a damn String - quit holding my fucking hand!

    Furthermore, Java's text processing abilites suck so bad, I don't even know where to begin.

    Give me Python any day. It can do any job Java can do, and probably better.
  • by Fnkmaster (89084) on Friday May 09, 2003 @01:15PM (#5919853)
    I gotta say, I'm positively impressed. C# and Java are feeding features off of each other. Iterators, enumerators and autoboxing/unboxing - hmm, I think I've seen those before. Java 1.5 starts to look more and more like C#.

    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.

  • by radish (98371) on Friday May 09, 2003 @01:16PM (#5919862) Homepage
    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.
  • by Grievance (102243) on Friday May 09, 2003 @01:17PM (#5919869)
    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.
  • by Anonymous Coward on Friday May 09, 2003 @01:18PM (#5919876)

    . . . are doomed to reinvent it.

    foreach anyone?

    null is zero?

    That said, I've wanted Generics in Perl since the first week of using the language and I can't wait until they are available.

    Disclaimer: I use Java professionally and Perl amateurly and I love them both.

  • Re:Uglification? (Score:3, Insightful)

    by ptomblin (1378) <> on Friday May 09, 2003 @01:18PM (#5919881) Homepage Journal
    I'm really looking forward to generics. I've got tons of code that casts the results from iterators or collections or maps. I've either got to test like hell and hope that I don't see any ClassCastExceptions and hope the testing was exhaustive, or I've got to do a lot of "instanceof" tests. Since 90% of the time when I use collections/maps I'm putting all of the same type in them, this just irks me.

    But for that other 10% of the time, remember that all classes are children of Object, so I'm betting you can still declare
    List = new ArrayList();
  • Re:Uglification? (Score:1, Insightful)

    by Anonymous Coward on Friday May 09, 2003 @01:20PM (#5919912)
    Not really. The generics take care of the one really irksome problem with Collections, having to recast all your data back to its original type. Its not only a pain, its inefficient. Every cast if chewing up a bit of CPU. It would be a lot better to simply have a List of Strings, instead of a List of Objects that we are going to recast as Strings and hope no one shoved an Integer in by mistake.

    Its an improvement. I'm not sure I like the syntax though, although I can't think of anything better.

    Does anyone know if the generics will allow you to create a collection of primitive values? There have been plenty of times that I would like to have a List of ints but have to settle for a List of Objects that are really Integers in disguise. Woo hoo, I get recast the variable and call a method just to extract my value. That blows. I guess the autoboxing would hide the details, but its still doing the recast and intValue() call in the JVM. I'd rather have a true List of int values.
  • Re:Generics (Score:3, Insightful)

    by forgoil (104808) on Friday May 09, 2003 @01:23PM (#5919946) Homepage
    It looks like Java's generics are much like C++'s templates. This means that it is a compiler feature, and not a runtime feature. This is not a step forward, but a way to keep the VMs still working. A trade off.

    For some interesting words on generics, and implementation for both Java and M$ CLR take a peak at this link: l= /library/en-us/dv_vstechart/html/vbconCProgramming LanguageFutureFeatures.asp

    All you "I hate M$" people out there will more than likely scream about how horrible they are and how we must use Java. If you hate M$ I would suggest you go take a look at mono instead. The CLR together with C# completly owns Java, and when generics are added it will be even sweeter. I program both Java, C#, and C/C++ daily, and it gives a very good view on what language is the easiest to work with and use.
  • Re:Uglification? (Score:5, Insightful)

    by Anonymous Coward on Friday May 09, 2003 @01:27PM (#5919991)
    No, I'm not irked. Not even a little bit.

    If your only experience of generics is C++, then all you've seen is the *worst* implementation of generics ever done in a language. Template code is almost unreadable. (Have you ever tried debugging one of the STL implementations?)

    Besides, the lack of generic types cripples Java's ability to do static type checking, since your code ends up being full of things like this:

    Foo f = (Foo) vector.elementAt(i);

    where type errors can only be detected at runtime. That not only makes it impossible to detect errors at compile-time, it hurts performance at runtime.

    Check out how generics are handled in Modula-3 for to see a much better way to handle them than C++ templates, or look at ML for something even more groovy (ML uses polymorphic type inference instead of generics, so you don't even have to mention types - the compiler just does the Right Thing).

    Once you've worked with a good generic implementation, you'll never want to stop using them.

  • by MilesParker (572840) on Friday May 09, 2003 @01:29PM (#5920012)
    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!
  • by MilesParker (572840) on Friday May 09, 2003 @01:32PM (#5920034)
    In my mind, this is _exactly_ the kind of thing that should be avoided in Java and that has sown so much confusions and monkey-business in the C++ community. Yea, you _should_ be defining those interfaces and abstract classes. That's why they call it OO. :D
  • by Malc (1751) on Friday May 09, 2003 @01:35PM (#5920062)
    Personally I like strong typing. The current approach of casting to (implicitly) and from (explicitly) Object violates this. IMHO, static typing saves far more pain in the long run than dynamic casting. If you like the general language, use JavaScript if you want to throw all that away.
  • by MilesParker (572840) on Friday May 09, 2003 @01:37PM (#5920088)
    "Also, it's statically typed. It's so fucking annoying to have to typecast everything - I know I have a damn String - quit holding my fucking hand!"
    Yea, you "know" you have a String...until you don't. Maybe you're superman, but I'm mortal -- and by the way, good practices demand a little humility, and assuming that you are _not_ perfect.

    Java's strong typing has been a huge productivity enhancement for everyone I've worked with. Just knowing that typically when you compile something, its actually going to run without a single error has been a revelation for me.
  • by DunbarTheInept (764) on Friday May 09, 2003 @01:43PM (#5920149) Homepage
    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."

  • Re:Agreed.. (Score:5, Insightful)

    by dhovis (303725) * on Friday May 09, 2003 @01:44PM (#5920156)

    Actually, i believe that in Java

    if(x = 5)

    will throw a compiler error because (x = 5) does not resolve to boolean.

    That is something I like about Java, it doesn't allow you to do stupid things like that. There is no reason to do an asignment in an if() statement.

  • by YetAnotherName (168064) on Friday May 09, 2003 @01:49PM (#5920203) Homepage
    From the article: "... you'll have to get used to providing additional information in declarations. Instead of merely saying:

    List words = new ArrayList();

    You'll have to say:

    List<String> words = new ArrayList<String>();"

    The way he says "you'll have to" suggests that old collection class construction might break. Let's hope that something like new ArrayList<Object> becomes the implicit default if you don't otherwise specify a type.
  • by KrisW (613034) on Friday May 09, 2003 @01:50PM (#5920215) Homepage

    I guess it doesn't matter if you're the only one reading the code, but I can't see how macros can do anything other than make code harder to read...

  • by Pentagram (40862) on Friday May 09, 2003 @01:51PM (#5920222) Homepage
    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.
  • by axlrosen (88070) * on Friday May 09, 2003 @01:54PM (#5920264) Homepage
    ... 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)


    foreach (TimerTask task in c)

  • Re:Uglification? (Score:1, Insightful)

    by Anonymous Coward on Friday May 09, 2003 @01:55PM (#5920272)
    when I make a collection of something, it's always of some type of thing. It's very rare that you only have a bag of 'objects', you have a bag of groceries. etc.

    this is now made explicit, safe, reduces run-time casts so reduces time and errors *and* involves less typing (of the keyboard variety).

    the old way exhibited major suckage.
  • by ratboy666 (104074) <> on Friday May 09, 2003 @01:58PM (#5920297) Homepage Journal
    Redefining the language to better meet the problem is one of the hallmarks of good (artistic) programming. And it has other purposes. To give you one:

    #define NOTHING ;

    if ((flag & VAL1) || (flag & VAL2)

    I know I can change this to eliminate the empty
    ';', but I choose not to, because I feel that the conditional reads better as a positive statement.

    [I also prefer to have the '<' or '>' in a compound conditional always point the same way:

    (5 <= x) && (x <= 10)

    so the conditional can be read "x between 5 and 10". I am a hacker -- thinking about code is a compulsion for me].

    Now, LINT (splint which I use), complains about the empty ';' as a probable coding mistake... I redefine NOTHING as /*@i@*/; and splint no longer complains ("indent" doesn't do the right thing, so I REALLY use /*=i=*/ which indent can handle, and splint can be trained to). Plus, when I am reading the code I can tell instantly that I meant it that way. FOREVER can be for(;;) or while(1), but it is clear from the read that I mean to iterate, well, forever. Typically, I would use that as the main loop of a thread.

    As to BEGIN and END -- I have coded with C (pre-ansi) on machines whose keyboards didn't have '{' and '}'. I had to construct an include file to define BEGIN and END with a binary editor. But it worked.

    There may be reasons that hackers do this -- don't be immediately dismissive. [#define ONE 1 I have used as well -- in defining manifest constants for numeric types in an object oriented number stack for C++. Ok, it was a constructor: myint one = 1; but I did it to keep only one copy of the number around -- improved efficiency]. The PUSHORT style I agree is USUALLY nonsense. I can see USHORT, but the '*' notation is supported. Of course there may be an attempt to impose an object system underneath, and it may be nice to define PUSHORT as "void*" to quickly highlight all uses of the underlying implementation. So even that has a purpose.

  • Re:Generics (Score:3, Insightful)

    by Mindbridge (70295) on Friday May 09, 2003 @02:00PM (#5920317) Homepage
    It looks like Java's generics are much like C++'s templates

    No, they are not. In fact, they are very different. C++ templates are heterogenious (every parameter set means a new class, hence you get lots of additional classes); Java generics are homogenious (one class serves all parameters). C++ templates' requirements for the parameters are "as they come" -- the code is simply recompiled with the new parameter classes; Java generics' parameters need to implement interfaces/extend classes if a particular method of the parameter is to be used (which is much neater from a design perspective, if you appreciate this kind of thing). The only thing in common is the first glance appearance.

    The CLR together with C# completly owns Java

    Yes, it is a better solution in some respects and much worse in others. Given that it was designed 5 years after Java, the first was to be expected, the second was not. It merits a look, until you realize that any advantages are only marginal, and that there is only one company that provides major products for it (like application servers) and defines its interfaces. Given the fact that the company has a long notorious history and it has standardized less than 10% of the API does not make things better. And then there is Mono that now has to rely on Wine... Ah well.

  • Re:Generics (Score:3, Insightful)

    by Caoch93 (611965) on Friday May 09, 2003 @02:01PM (#5920342)
    It's not possible to engage in the level of typechecking you're talking about with generics. All objects go through a typesafe container having the type of java/lang/Object. Java, right now, cannot check at compile time whether or not a call to get(), returning java/lang/Object, will yield an object of java/lang/String in the typecast. This is preceisely why ClassCastExceptions at runtime is such a big deal.

    By comparison, by telling the compiler that you want all of the objects in some container to be of type java/lang/String, the compiler can provide checks against it because the expected type is now a facet of the method signature. To engage in the kind of typechecking at compile time that I'm talking about without programmer clarification (via generics) would require the compiler to have a guaranteed knowledge of a lot more than it does. For example...

    If, in one piece of code you insert a java/lang/String into an ArrayList, then in another piece later, it is clobbered and replaced with a java/math/BigDecimal, and then in another piece, get() is called and the retrieved java/lang/Object is cast to java/lang/String, the compiler, to provide type-checking and catch this class cast failure, would have to be able to prove that, every time that specific get() was called, something other than a java/lang/String came out of it. To do that would requrie a lot of information about the dynamic state of the program at that time.

    In fact, depending heavily on the method in question, it may be impossible to guarantee the permitted type of the object available when you cast/miscast it. Consider a multithreaded environment. You're fast reaching a place where the only way to know what the type of the object is is to actually wait and see each time, which is what runtime casting is.

    You are correct that certain forms of type safety can be found at compile-time. For example, type safety in passing parameters, assigning values from a return, etc, can be tested. Likewise, a type saftey check of this nature is trivial:

    ArrayList l = null;
    String s = new String();
    l = s;

    However, there reaches a point where runtime type safety has to take over, and most of the cases of improved type safety thanks to generics is a matter of moving more type checks away from runtime and into compile time.

    And generics does not have to be "a hell of type casts". It can be a preprocessor hack where, at compile time, the types are provided in a special syntax and the generics (or template) code is then used to generate a unique piece of source code from those types. This would clearly make your compiled code size bigger, but avoids excessive use of the runtime type system.

  • Re:what if... (Score:3, Insightful)

    by pmz (462998) on Friday May 09, 2003 @02:07PM (#5920412) Homepage
    what if microsoft buys sun?

    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 .NET, and Solaris is the biggest commercial competitor to Windows Server.

    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.
  • -1, troll

    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.

  • Re:foreach (Score:3, Insightful)

    by sohp (22984) <> on Friday May 09, 2003 @02:40PM (#5920772) Homepage
    I guess you didn't RTFA. Introducing a new keyword breaks programs that happen to use that as an identifier. They broke JUnit when they introduced the assert keyword, and having been burned once, learned something.
  • by LogicHoleFlaw (557223) on Friday May 09, 2003 @02:49PM (#5920864) Homepage
    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.
  • by slagdogg (549983) on Friday May 09, 2003 @02:53PM (#5920898)
    I couldn't agree more with your view of the Oracle tools ... but I really do use Java's platform independence all the time, and for non-GUI applications I think it works beautifully. The key here is the 'non-GUI' ...

    Actual example, I recently developed a servlet-based application, and given the hardware and time constraints I was under I developed on Linux, performed functional testing while deployed on Windows, and finally deployed on Irix. There was no change in behavior with the application other than performance, and it was a complex, multi-threaded application.
  • by spakka (606417) on Friday May 09, 2003 @03:03PM (#5921019)

    I know I can change this to eliminate the empty ';', but I choose not to, because I feel that the conditional reads better as a positive statement.

    At the cost of failing to compile

  • Re:enumerators (Score:5, Insightful)

    by revscat (35618) on Friday May 09, 2003 @03:05PM (#5921031) Journal

    The article makes no claim about the typesafe enum pattern being broken, it just points out that you have to be careful if you use it and implement Serialzable. This is something that Bloch specifically addresses in Effective Java, and does not mean that the entire pattern should be scrapped. You just have to be aware of potential problems.

  • by Ed Avis (5917) <> on Friday May 09, 2003 @03:10PM (#5921081) Homepage
    No - distinguish between syntactic sugar, which gives you a new syntax to express what you could have said anyway, and real language features.

    For example array access with [] in C is syntactic sugar, since you could do the same with pointer arithmetic - a[b] is exactly equivalent to *(a+b). However a declaration of an array variable:

    int a[1000];

    is _not_ syntactic sugar, since there is no other way to reserve space for a thousand contiguous integers on the stack. You could use malloc() from the standard library, but as you know that allocates on the heap and you have to free the memory afterwards.

    (OK you could have a thousand 'int' declarations but I don't think it's guaranteed they will be a contiguous block in memory.)

    As an example of a language with no syntactic sugar, look at Unlambda [] (although you wouldn't want to program in it). The language syntax is minimal but semantically it is a long way off from raw machine code.
  • by _fuzz_ (111591) <<moc.niknudevad> <ta> <em>> on Friday May 09, 2003 @03:21PM (#5921179) Homepage
    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.
  • by melted (227442) on Friday May 09, 2003 @03:31PM (#5921281) Homepage
    For the gaping holes and pitfalls he has created in C++. Everyone who has read books from Effective C++ and Exceptional C++ series knows this. In Java or C# you've got to try to shoot yourself in the foot, in C++ this comes by default, you don't even have to do anything. Some insanely simple situations shoot you in the foot so bad, it's not even funny. Not that C++ doesn't have its uses, but its usage should be limited and punished for. Thanks to Bjarne's "excellent" design, devs punish themselves every time they use the language for something non-trivial.
  • Re:enumerators (Score:4, Insightful)

    by bnenning (58349) on Friday May 09, 2003 @03:33PM (#5921301)
    By making them objects you have to worry about the compiler creating a lot of extra objects behind your back especially in tight highly used loops.

    I would think they'd have to be like singletons, with the compiler creating exactly one instance of each enum value.

  • by blahedo (24332) on Friday May 09, 2003 @03:36PM (#5921339) Homepage

    Your answer highlights the very reason that C macros are a bad idea. You say:

    #define NOTHING ;
    if ((flag & VAL1) || (flag & VAL2)

    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.)

  • by samwhite_y (557562) * <> on Friday May 09, 2003 @03:53PM (#5921499)
    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
  • by Troll_Kamikaze (646926) on Friday May 09, 2003 @04:01PM (#5921556)

    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.

    Perhaps this is why huge applications are usually written in languages requiring typecasting, and the "looser" languages are usually relegated to simple task duty.

    Dynamically yet strongly typed languages such as Python and Lisp allow you to tell the compiler or interpreter "exactly what you mean" with regard to types, they just don't require you to do so. Where's the beef?

    Bruce Eckel, a C++ and Java expert and the author of the "Thinking In ..." series of books, wrote [] recently:

    After I had worked with Python for awhile -- a language which can build large, complex systems -- I began noticing that despite an apparent carelessness about type checking, Python programs seemed to work quite well without much effort, and without the kinds of problems you would expect from a language that doesn't have the strong, static type checking that we've all come to "know" is the only correct way of solving the programming problem.

    This became a puzzle to me: if strong static type checking is so important, why are people able to build big, complex Python programs (with much shorter time and effort than the strong static counterparts) without the disaster that I was so sure would ensue?

    This shook my unquestioning acceptance of strong type checking...

  • by Mindbridge (70295) on Friday May 09, 2003 @04:02PM (#5921562) Homepage
    As pointed out in other posts, Metadata is JSR 40, which has been around since 1999 (before .NET). It is not a C# invention.

    In addition, C# properties are pretty badly implemented. Quite often one needs to have a private (protected) 'set' and a public 'get'. This is not something one can do as a property in C#. Also, who had the great idea of making public members and properties look the same? It is okay to allow one or the other in the language, but both?
  • by cant_get_a_good_nick (172131) on Friday May 09, 2003 @04:10PM (#5921619)
    When will C be frozen?

    C99 changed a lot of things, and added things that may cause some breakage for old projects. Just like you can tell your compiler to compile pre-C99, you use a different jsdk. C is > 30 years old and still has to evolve. Java is much younger and has more places where it needs to mature.
  • by willtsmith (466546) on Friday May 09, 2003 @04:38PM (#5921888) Journal
    Any language feature can be abused and used in inappropriate ways. I once knew a programmer who included comments like the following. // I'm really tired now. ... // Gosh gotta go to the bar ... // I'll never do this again // Source control is my enemy, they'll know who writes all these stupid comments ....

    Obviously he wasn't using comments correctly. And sometimes would even obfuscate by not modifying comments to reflect code changes.

    However, this is not a reasonable arugment for why comments should NOT be part of a higher level language. Some people actually write usable comments that add something to code.

    Same thing is true with operators. The fact that some yahoos assign weird functionality to operators doesn't diminish the uses for operators AND the ability to write large volumes of code shorthand through operators.

    As far as syntactic sugar goes, as long as the compiler processes it correctly, it's good. Writing the same pieces of code OVER, and OVER, and OVER, and OVER, and OVER, and OVER, and OVER is a waste of time (AND MONEY!!!!). It's a job better left to a compiler. If a programmer can't grasp or understand newer constructs (beyond cut and paste :-), they should question whether they're in the right field.

  • by Gorimek (61128) on Friday May 09, 2003 @04:41PM (#5921924) Homepage
    The same goes for preprocessing. Consider things like '#define + -'...

    An other awful consequence of operator overloading is that code like this
    if (x != null && ...
    is unsafe, since the && may be overloaded.

    (The above may not be valid C++ syntax. I left C++ for Java many years ago and I'm never going back!)
  • by Baki (72515) on Friday May 09, 2003 @05:26PM (#5922249)
    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.
  • by __past__ (542467) on Friday May 09, 2003 @05:40PM (#5922353)
    Java isn't strongly typed. It has static, or manifest, typing. Those two qualities are orthagonal.

    In a strongly typed language, there are no cast operators, and hence no ClassCastExceptions. You don't have these even in dynamically-but-strongly typed languages, like Lisp or Python.

    Java doesn't give you type safety, just type errors when you try to be smarter than the compiler, which isn't that hard. That is no surprise - it has been shown that proper type inference runs into the halting problem, by research on languages that at least try to be helpful rather than just annoying while maintaining static typing (like ML or Haskell). In this regard, Java combines the worst of both worlds, just like C and C++, even if it is otherwise better than them in almost everything.

  • by __past__ (542467) on Friday May 09, 2003 @05:45PM (#5922397)
    Try Lisp. Common Lisp compilers usually generate faster code than Java (mostly because they compile to native code), yet you don't have to declare types unless you choose to do so. If you do, the compiler can use the declarations either to check type correctness or to generate optimize code, just as you wish.

    Once you've experienced the freedom and flexibility of Lisp, there's no way back. Unfortunatly, you'll soon realize that this fact sucks hard when you try to program by library-shopping, scince there basically are no third-party libs for CL.

  • Re:Needed feature (Score:3, Insightful)

    by Thorgal (3103) <> on Friday May 09, 2003 @06:00PM (#5922508) Homepage
    Hotspot optimizes bound checks away. What would be more useful for scientists are:

    a) true arrays,
    b) FPU-using trigonometrical ops
  • Re:enumerators (Score:3, Insightful)

    by spells (203251) on Friday May 09, 2003 @06:26PM (#5922643)
    Polymorphism is a single tool in the belt and doesn't replace switch statements.
    Although I agree every instance of a switch statement can probably be implemented with polymorphismc some times you will end up with a worse design using polymorphic solutions that haven't placed enough emphasis on encapsulation and connascence. Options are good.
  • by rjh (40933) <> on Friday May 09, 2003 @06:42PM (#5922723)
    Any language which cannot be redefined is, much like any programmer who says languages must not be redefined, fundamentally wrong. If you can't rewrite your language on the fly, then what good is it? :)


    A Very Happy LISP Programmer.
    No, really. Redefining the language is one of those things which sounds like a bad idea, up until the time you learn functional languages. Once you grok functional languages, redefining the language becomes second nature to you: for any given serious programming task, you modify the language into a special-purpose language meant specifically for solving your problem. For instance, I wrote a crypto library in LISP recently, and I needed to do a lot of addition modulo 2**32. In any other language, I'd have to write a function to do the additions... in LISP, I just wrote a macro.

    Redefining the language is an astonishingly powerful technique, and once you grok it, the idea of a language forbidding you the ability to redefine itself seems like an Apocalyptically Bad Idea.

Luck, that's when preparation and opportunity meet. -- P.E. Trudeau