Forgot your password?
typodupeerror
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 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."
This discussion has been archived. No new comments can be posted.

Summary of JDK1.5 Language Changes

Comments Filter:
  • Generics (Score:3, Interesting)

    by boxhead609 (671383) <prowe2@yahoo.com> on Friday May 09, 2003 @12:52PM (#5919654) Homepage
    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?
  • Re:Generics (Score:5, Interesting)

    by gray peter (539195) on Friday May 09, 2003 @01:03PM (#5919738) Homepage
    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.
  • Retro... (Score:3, Interesting)

    by dance2die (596340) on Friday May 09, 2003 @01:06PM (#5919769) Journal
    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... :)
  • not just sugar (Score:4, Interesting)

    by Anonymous Coward on Friday May 09, 2003 @01:09PM (#5919796)
    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.
  • by Grievance (102243) on Friday May 09, 2003 @01:11PM (#5919822)
    I see all six of the enhancements described in the article as coming directly from C#, and I think they're all Good Things. (i don't remember enough from my Lisp days to know if some ultimately derive from that most elegant language.)

    i've been a Java programmer (primarily) for 8 years, and just recently did a project in C# -- which i was dreading, but the language turned out to be OK, like Java with sops thrown to C++ diehards.

    now, if Sun adds operator overloading (*shudder*), i'm jumping ship.
  • by eGabriel (5707) on Friday May 09, 2003 @01:14PM (#5919840) Homepage
    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.
  • by coyote-san (38515) on Friday May 09, 2003 @01:15PM (#5919849)
    It sounds like C# uses a lot of stuff from Ada (and I'm sure countless other languages), but forgot to honor prior work. :-)

    Seriously, the "C# copied from Java/Java copied from C#" argument misses the point. There's a lot of prior work, and finding the right balance between usability and clutter is difficult. As much as I loved writing stuff like "for (value'range) do..." I would rather see a conservative approach to features since it's always easier to add stuff than remove it.
  • by Anonymous Coward on Friday May 09, 2003 @01:18PM (#5919888)
    Agree.

    It will also make code easier to write in another way:

    Modern java editors (in particular the almost magical Intellij IDEA) provide code completion based on valid types in a given context. The more the editor knows about the types involved, the better this feature will work.
  • by forsetti (158019) on Friday May 09, 2003 @01:21PM (#5919923)
    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> :)
  • by dood (11062) on Friday May 09, 2003 @01:23PM (#5919947)
    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.

    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/ oswego/cs/ dl/util/concurrent/intro.html

    OH, and there will be classes like AtomicLong which guarantee atomic 'compare and set' options for primitives. :)

    Cheers!
  • Re:Generics (Score:3, Interesting)

    by justins98 (316484) on Friday May 09, 2003 @01:25PM (#5919972)
    I don't think it will require a bytecode change. I don't know the details of how it works, but my guess is that the compiler will simply insert the casts for you. For example, when you say:

    List<Foo> list = new ArrayList<Foo>();
    list.add( myFoo );
    Foo otherFoo = list.get( 0 );

    The compiler will interpret the second and third lines as if they said:

    list.add( (Foo)myFoo );
    Foo otherFoo = (Foo)list.get( 0 );

    It's a pretty elegant way to incorporate type-safe generics without imposing any changes on the VM. I think the compiler changes would be relatively easy to implement -- nothing more than inserting casts at the appropriate places.
  • Re:Agreed.. (Score:5, Interesting)

    by DunbarTheInept (764) on Friday May 09, 2003 @01:27PM (#5919994) Homepage
    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.

  • by MillionthMonkey (240664) on Friday May 09, 2003 @01:30PM (#5920020)
    This looks to me like they are changing a language so that existing apps no longer compile which is a bad idea.

    Huh? Where did you see that?

    It looks like they're making changes so that new apps won't compile on older compilers, not that old apps won't compile on newer compilers.

    They risked a backwards compatibility problem when they introduced that "assert" keyword in 1.4 but there is a compiler switch to turn it off if you have variables with that name. Before that, they haven't messed with the syntax since 1.1, when they added class literals (syntactic sugar) and inner classes (a major change). The new syntax was so bizarre that no older programs were affected. I don't see how the 1.5 changes are any different. Some of them look like a cat walked across someone's keyboard.

    My company is stuck with having to support Java 1.1 because of Mac OS 9. (In fact, according to our demo download stats, the number and percentage of Mac OS 9 users is only going up.) So we use modern compilers when developing (no decent IDE works well with 1.1) but the nightly build script uses 1.1.8.

    Inner classes were an immense change compared to most of this sugary 1.5 stuff (except generics). Work here a few months and you learn about all the bugs in the 1.1.8 compiler with respect to inner classes. There are a number of perfectly legal constructs that get flagged as errors. But I bet the same kind of thing will happen with generics.

  • by Anonymous Coward on Friday May 09, 2003 @01:31PM (#5920025)
    I think a number of the 'improvements' for 1.5 are nothing more than syntaxic sugar that are pushing Java in a bad direction. One or two these enhancements does offer some lesser compile time checking which is a good thing, but for the most part they seem to be an attempt to let the programmer type fewer characters and letting the compiler 'generate' the code.

    Why is that bad you might ask? I mean who wouldn't want to do more in fewer keystrokes. Well there are a few major problems that I see:

    1. There is a much greater ability to get into the "Perl factor" where there are 16 million ways to do the same thing. While having so many ways to get the same thing done is great if you are one or two folks working on a project, its terrible if you are 20-30 developers working on the same project. So these 'improvements' seem to push Java away from being a good Enterprise level language.

    2. While none of the changes specifically target this, its movement away from being a systems language where the programmer is very close to the underlying action that the computer is doing. One of Javas greatest strengths is its ability to get deep into the bits (like C), and while this is not going away this seems to be where alot of the thinking is.

    3. These 'improvements' will be all that some newer programmers learn. I think this will lead to a much greater number of java programmers who don't really understand whats going on and we will have a lot of confusion out there.

    All of this because some people wanted to save a few keystrokes.
  • compiled java? (Score:2, Interesting)

    by dipierro (672203) on Friday May 09, 2003 @01:35PM (#5920065)

    When it comes down to it, once the code is compiled, it's the same.

    If you're compiling, shouldn't you use a language which wasn't designed to be interpreted?

  • Personal comment (Score:1, Interesting)

    by Anonymous Coward on Friday May 09, 2003 @01:35PM (#5920074)
    Well having to use java day in day out and mostly loving it, here is a personal comment.

    The generics and the autoboxing are heaven sent from a language standpoint. The other stuff mostly is syntatic sugar and the static imports I really don't know if that is a good extension to keep the code readable. But the biggest gripes with java are not the language but two other things:

    a) long loading times caused by the class loader class verifier mechanism
    b) huge memory footprint thanks to mem hungry hotspot optimizations

    What I really couldn't find is if those two issues will be adressed or postponed again.

    Btw. if you like java but think that swing is slow in X check out the latest blackdown release, it is amazing what the blackdown guys did to swing. Also check out the 1.4 JDK for the mac, no difference to a native mac app speedwise.
  • Re:enumerators (Score:5, Interesting)

    by iabervon (1971) on Friday May 09, 2003 @01:42PM (#5920145) Homepage Journal
    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...
  • by MarkWatson (189759) on Friday May 09, 2003 @01:51PM (#5920223) Homepage
    I have complained here before on this issue:

    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:

    • memory footprint
    • runtime efficiency

    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

  • by Henry Stern (30869) <henry@stern.ca> on Friday May 09, 2003 @01:52PM (#5920240) Homepage
    I've been using Java for most of my projects for years because it didn't let you get away with many of the confusing things that you can do with a preprocessor. I may sound like a big geek for this, but I was actually weeping while I read the article. JDK 1.4 broke the ice with the assert keyword and now everything bad about C++ is going to pollute Java.

    To the many cooks who spoiled the broth: "Thanks a lot, assholes."
  • Re:Generics (Score:3, Interesting)

    by MillionthMonkey (240664) on Friday May 09, 2003 @02:01PM (#5920339)
    Actually I believe all objects are type-checked at run-time, even if the casts were determined to be safe at compile time, but maybe there's a way to optimize that out.

    The JVM executes a checkcast bytecode instruction wherever there is a cast. It either does nothing or it throws a ClassCastException at you. (The instanceof instruction works the same way, except it puts a boolean on the stack instead.) But with generics, a runtime cast is never required IIRC. The compiler generates a one-shot collection class based on the generic that ONLY handles members of the type you've specified (e.g. String) and returns objects of that type, so the type checking is done statically. The entire purpose was to eliminate the runtime cast.

  • by avalys (221114) on Friday May 09, 2003 @02:09PM (#5920434)
    Aside from the opportunities for abuse of operator overloading, I don't think it's really that important in Java since it was never intended as a language for anything heavy on calculation (being interpreted and all).
  • Re:enumerators (Score:5, Interesting)

    by ProfKyne (149971) on Friday May 09, 2003 @02:13PM (#5920469)

    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:

    public class SenseEnumeration {
    // the action associated with this enumeration
    private java.lang.reflect.Method sense;

    private SenseEnumeration(Method m) {
    this.sense= m;
    }

    // assuming we've already created some
    // Method instances to use here
    public static SenseEnumeration TASTE
    = new SenseEnumeration(myTasteMethod);
    public static SenseEnumeration HEAR
    = new SenseEnumeration(myHearMethod);
    public static SenseEnumeration SMELL
    = new SenseEnumeration(mySmellMethod);

    ...etc...

    public Method getSenseMethod() { return this.sense; }
    public void invokeSenseMethod(Object target) {
    sense.invoke(target, null);
    }
    }

    You get the main idea. No, not as fast as an int, but far more powerful.

  • Re:enumerators (Score:5, Interesting)

    by slagdogg (549983) on Friday May 09, 2003 @02:17PM (#5920512)
    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 ;)
  • Maintenance (Score:2, Interesting)

    by ruriruri (566567) on Friday May 09, 2003 @02:18PM (#5920520) Homepage
    Unlike some people, I feel using programming shorthand leads to increased maintenance.

    Do you like seeing "public void setX()...public int getX().." a hundred thousand times to implicitly declare a bound property? Or would you rather see "published int x;" (to steal a line from C#) and be able to refer to x by field name rather than accessor method? I think simplifying code like this is a good idea. However, there is a dilemma created herein, as the example below will illustrate!

    Thought Experiment #1
    Assumption: Maintenance cost is directly correlated with program size.
    Therefore: The more terse the language grammar, the easier programs written in the language are to maintain.
    Thus: Perl.

    At that moment, the programmer was enlightened.

  • by jlusk4 (2831) on Friday May 09, 2003 @02:26PM (#5920611)

    The gist is, you'll never need to use ... "synchronized" anymore, but rather you'll execute Runnables, use Locks and Semaphores, etc.


    I'm not sure how locks and semaphores are a step forward from monitors, which is what "synchronized" represents.

    Are you claiming "synchronized" is inefficient? Did you see the developerWorks article [ibm.com]?

    Are you claiming that such a high-level structure as a monitor is unnecesary for real programmers, who know what they're doing and will never screw up using synchronization primitives?

    John.
  • by autopr0n (534291) on Friday May 09, 2003 @02:33PM (#5920685) Homepage Journal
    It's interesting the problem they were having with unboxing. Right now a null pointer would return a int value of zero, rather then throwing an error.

    Actually, I think that's a bad idea, since you wouldn't be able to tell a zero you put in a collection with one that you didn't. Personally I'd like to see this as an option, somewhere. perhaps as a parameter to Integer, so you could do Integer<0> or Integer<null> to chose the behavior of the class. The problem there is that it's not obvious what a parameter to integer would do. Although I suppose you could use an if statement.

    Personally, I wished they would have thought up a more interesting way to do generics then the C++ model. I wonder if this is going to give us the full range and power of C++ templates in java.
  • by Chromodromic (668389) on Friday May 09, 2003 @02:45PM (#5920812)
    "Generics"? Castrated templates.

    Enhanced "for" loop? Syntactic sugar. Oh and for God's sake, don't use new keywords. It'll be destabilizing.

    The "split type system" in Java has always compromised Java's status as a true OOP platform. Seriously, this is supposed to be exciting? Java is how many years old and they've finally made it oh-so-easier to convert between primitive and class types? Aren't there enough conversions in a strongly typed language?

    Typesafe Enum pattern, Constant Interface antipattern ... Whenever I see this corporate programming designspeak crap I thank God that Apache wasn't written in Java.

    Metadata programming. Now Java will have code that emits code before the compiler emits code. Well, there goes Java having no pre-processor. But in true Java fashion, it looks like this "framework" will be much, much harder to use than a pre-processor, so that's good.

    Bottom line, Java is Byzantine, slow, bloated, and now playing catch-up. Want to avoid all this verbose, camel-cased code? Go C++. Yes, you'll have to learn how to write secure code, and yes, you'll have to use pointers, which are supposedly EXTREMELY DANGEROUS, and yes you'll have to learn about how your computer works a little more to be an expert. Of course, Java requires none of these things.

    If you must go with some absolutely proprietary platform, then go C#. At least it's standardized. Oh, oh, Sun was going to do that with Java but then, you know, didn't.
  • by dasmegabyte (267018) <das@OHNOWHATSTHISdasmegabyte.org> on Friday May 09, 2003 @02:45PM (#5920819) Homepage Journal
    "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.
  • by CharlesEGrant (465919) on Friday May 09, 2003 @02:46PM (#5920824)
    Hmm. I could understand your reaction if they were adding operator overloading, but assert seems pretty benign. Can you give an example of a confusing use of assert?
  • by divec (48748) on Friday May 09, 2003 @02:53PM (#5920900) Homepage
    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.


    Interestingly, ISO C defines shorthands for people with crap keyboards. You can type <% instead of { and %> instead of }. Also:


    <: means [
    :> means ]

    %: means #
    %:%: means ##


    You get even more if you include iso646.h. Of course, the old compiler you were using may not have had these :-)
  • Re:enumerators (Score:4, Interesting)

    by Mindbridge (70295) on Friday May 09, 2003 @03:35PM (#5921333) Homepage
    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 :)
  • Needed feature (Score:3, Interesting)

    by quantaman (517394) on Friday May 09, 2003 @03:46PM (#5921426)
    They need to include an option to not include bounds checking in arrays. Right now Java is becoming very popular in physics because it's easy to use and portable across systems. I know a lot of people in physics who program in Java and I've worked the past two summers as a summer student writing code for physicists. The biggest complaint both they and I have in the bounds checking it does. It's a great option for debugging, testing, and for running most applications. But when you are running a large program the overhead of bounds checks in arrays can be prohibative. Ideally I would like either a runtime or compiler option where you can specify to run it without bounds checks. Obviously this wouldn't be a good idea for a great many apps but it would be extremely useful when running an array heavy application that takes hours or days to complete.

  • Re:enumerators (Score:4, Interesting)

    by Mindbridge (70295) on Friday May 09, 2003 @03:47PM (#5921438) Homepage
    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.

  • by Anonymous Coward on Friday May 09, 2003 @03:53PM (#5921500)
    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.
  • Re:Retro... (Score:3, Interesting)

    by jeremyp (130771) on Friday May 09, 2003 @03:58PM (#5921544) Homepage Journal
    I agree with that. Following the backward compatibility rule blindly can lead to some serious abortions. In this case, they are sacrificing a nice elegant construct for the person who has a variable named "foreach" (unlikely) and the person who has a variable named "in" (their fault for choosing a stupid non descriptive variable name). A "java 1.4" switch would sort that out plus any reasonable search and replace facility.

    If they'd said "i" is now a keyword, that would have been more of a problem.
  • by g4dget (579145) on Friday May 09, 2003 @04:33PM (#5921843)
    Sun is finally rolling this out because of competition from Microsoft and C#. Until C# looked real, Java had mostly stagnated.

    Unfortunately, this doesn't quite make Java competitive with C# yet. Major missing features are:

    • JVM support for generics. Lack of JVM support makes generics not type-safe across compilation units, and it also makes them less efficient. The result is that the current generics implementation for Java is a stop-gap measure that isn't a good long-term solution. C#/CLR doesn't have generics yet, but Microsoft is planning on CLR changes to support them.
    • Lack of value classes. Value classes are essential for scientific programming, and automatic optimization cannot infer them reliably.
    • Lack of operator overloading. Again, that's essential for scientific programming. Some people worry that they lead to unmaintainable code. Of course, andy feature can be abused, but that's really a problem with overloading, not operator overloading.

    Also, Sun's patents on core Java technologies and the lack of a well-defined, open Java standard are still serious problems. The fact that Swing is de-facto part of the Java standard but that Swing is as ill-defined as the Windows API is another problem because it makes it hard to create open source implementations of Java.

  • by Gorimek (61128) on Friday May 09, 2003 @10:22PM (#5923747) Homepage
    My example in the general form is the fairly common "pattern"

    if (fooIsSafeToDo() && foo())...

    This is guaranteed to work in C and Java, and to 99.9% in C++. So as a C++ developer you're forced to either always write

    if (fooIsSafeToDo()) {
    if (foo())...


    or to keep writing code that will almost always work. That is, if you're even aware of the issue, which I'm sure most programmers are not.

    If I understand your point, this can't happen in the common case where 'fooIsSafeToDo' is a null check, which is good, but doesn't really change the principle. And no, I haven't seen this one bite anyone, but I've seen plenty of other really obscure C++ traps wreak havoc.

    Here's an other pet peeve, while I'm whining. Why is this unsafe C++ code?

    getResource(); // memory, file, whatever
    foo();
    releaseResource();


    because foo() may throw an exception, so this is a resource leak.

Programmers do it bit by bit.

Working...