Article: 10 Reasons We Need Java 3.0

Discussions

News: Article: 10 Reasons We Need Java 3.0

  1. Article: 10 Reasons We Need Java 3.0 (67 messages)

    Elliotte Harold has sparked a lot of debate with his article on scraping the ugly stuff that exists in Java (for the name of backwards compatibility). Read this to find out his reasoning on why we need to look to the future, and some things that can be changed.

    View the article at: http://www.onjava.com/pub/a/onjava/2002/07/31/java3.html

    Some questions for discussion:
    ------------------------------
    Should we make everything an Object like he says? (or is auto-boxing OK)

    Would it make sense to do the same in J2EE? If there a need for a J2EE 3, what would you scrap/change?

    Threaded Messages (67)

  2. I looks like these changes fall into two categories:

    Major changes that impact the core of the Java language
    - eliminate primitives
    - extend chars from two to four bytes
    - "fixing" threads
    - ditching AWT
    - redesign I/O
    - redesign class loading

    Nice-to-have changes
    - consolodating collections
    - consistent naming conventions
    - replace other file formats with XML
    - delete deprecated items

    I am all for all of the second ones. Having deprecated methods that are still lingering from 1.0 drives me nuts. So does seeing people still use Vector for any kind of ordered list, even though the Collections API has been around for almost four years.

    As for the biggies - none has bothered me too much. I wouldn't mind moving away from primitives. The I/O classes have never really caused a problem for me (once I figured out how to use them). The others I don't really care one way or the other.

    However, IMO the time will come when Java needs to be consolodated/revamped/fixed now that it has been around long enough for everybody to have a good sense of what needs to stay, what needs to change, and what needs to go. It could be a painful migration period, but I think it has value.

    Ryan

    P.S. When did Java 2.0 come out? Did I miss something ;-)
  3. IMHO this discussion should be split up in exactly the 2 categories Ryan proposes:
    - major changes that impact the core of the Java language (long term, whatever the name);
    - nice-to-have changes/extensions (short term, J2SE 1.5).

    For the latter, there is JSR 176 (J2SE 1.5 code-named "Tiger"), targetting end of 2003 for final release. Especially Collection and naming issues, removal of deprecated items, and allowance of XML file formats instead of property files should be proposed to them. I would really like to see J2SE 1.5 become THE consolidation release of the 1.x series!

    Juergen

    P.S.:
    Oh well, JDK 1.2+ aka J2SE = "Java 2 Platform Standard Edition". I wonder how Sun will call a JDK 2.0 - J3SE = "Java 3 Platform Standard Edition"? Sun has introduced some long-lasting numbering confusion here...
  4. Another URGENT flaws!!!![ Go to top ]

    I've some other flaws to point out:

    1)static method declaration in interface.So I can use Object.equals(Object a,Object b) without having to type "if ((null!=a)&&(a.equals(b))"...

    2)4 byte char.Need it urgent,we asian apps have to translate String between GBK,ISO-8859-1,UTF-8,....every line of code from JSP to JDBC to XML,these ugly design just annoying me to kill!!

    3)strong thread funtionality.Why just employ some real multithread experts to rewrite the java concurrent API?

    4)deep clone.When writing multi-layered app,cloning VOs is a real strengh-work,not mentally

    5)more tightly integrated RE with String.String.replaceAll() in JDK1.4 is not quity enough, it does not support group replacement.

    6)polish other API(like can't computing gap between two Calendar,<Java CookBook>)
  5. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    The primitives part is not very well thought out IMHO.

    He references C# as an example of a language whose compiler maps primitive types to object types.

    C# calls this job boxing, and indeed does automatically box and unbox primitive types into their object wrappers. This means you can do

    int p = 1;
    int i = 2;
    object r = p + i;
    textBox1.Text = ((Int32) r).ToString();

    However what he doesnt discuss is HOW this is handled by the VM in C#. It is INCREDIBLY expensive. If you read any of the newsgroups for C# you will see very quickly that boxing and unboxing are extreemly expensive operations. Worse then expensive they are hard to predict when they will happen. Boxing and unboxing also leads to the implicit need for operator overloading so you can arithmetic operations with both the boxed and unboxed instances.

    This is far from the simple compiler trickery Elliot discusses.

    Dave Wolf
    The Scupper Group
    dave at scuppergroup dot com
  6. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    How long in this thread before somebody asks for generics in Java 3.0? :-)

    --
    Cedric
    and then operator overloading, and then properties, and then...
  7. How about adding in pointers and explict memory management! ;)
  8. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Hmmm... Yes

    While there a some convincing and yes even compelling technical reasons to revamp Java. I think we must be pragmatic about what we want. The reason we have programming languages is for us to develop useful software for end users, not to have the coolest language ever!

    For a platform to be of real benefit in the long term it must be stable and yes wait for it backward compatible. No one wants to invest in software they will have to completely re-factor because some things have been taken out since the last version in favour of cooler things no matter how cool they are. People realise this, one example is how generics will be implemented in Java. Generic enabled containers will work unchanged with current code which is based on the Object class.

    So in conclusion cool features good, stability and longevity essential.
  9. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Cedric,

    It took quite some time. Generics were mentioned first time in the 16th message. Jim never got an answer(for some reson people who ask for generics are not so eager anymore for pointer arithmetic -- wonder why?).

    DODO
  10. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    <quote>
    It took quite some time. Generics were mentioned first time in the 16th message.
    </quote>

    Yup. Call it a self-defeating prophecy :-)

    --
    Cedric

  11. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    I was very dissapointed: The SIXTEENTH message! And NO pointers, no new and delete(like in PB)! Where's this world going to?:-)))
    DODO
  12. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Hmm.. how do pointers/delete (I would like to remind you that you do have new in Java :) relate to generics (except that they are in C++, together with inheritance, virtual methods etc..) - I would think operator overloading would be more appopriate :). (oh, to have an ability to compile
    Map<Thing,String> map = getMapOfThings();
    String name = getName();
    Thing thing = map[name];
     :)))
    )
  13. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Vlad,

    Your code specimen(was it sarcasm, I wonder?:-)) is much better.
    Chapeau!

    DODO
  14. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Amen,

    everytime I have to cast something coming out of a collection class I want to scream.

    Speaking of delete I'd love to see it in Java. Either that or stack based objects. delete would not be mandatory but when I'm done with a resource I want to get rid of it, now. And deterministic destructor calls would be oh-so-nice.

    GC causes as many problems as it solves.

    I agree also that const objects would be very nice. That would allow many bugs to be caught at compile time.

  15. <sartoris>
    everytime I have to cast something coming out of a collection class I want to scream.
    </sartoris>

    You want to scream, but how many times has it *really* been an issue? (i.e. ClassCastException)

    </sartoris>
    Speaking of delete I'd love to see it in Java.
    </sartoris>

    You can't mix a garbage collector with deterministic destruction of objects. I'll pick GC over explicit deletes any day, I have wasted way too many hours in C++ hunting for memory corruption to pine for those days.

    --
    Cedric

  16. <cb>
    You want to scream, but how many times has it *really* been an issue? (i.e. ClassCastException)
    </cb>

    It's a potential issue every time it's done. We should endeavor to move as many problems to compile-time as we possibly can.

    <cb>
    You can't mix a garbage collector with deterministic destruction of objects. I'll pick GC over explicit deletes any day, I have wasted way too many hours in C++ hunting for memory corruption to pine for those days.
    </cb>

    We can send people to the moon this should be a piece of cake;-)
    I don't see it as an either-or proposition. If I call delete someObject I want the destructor called for someObject then I want that sucker deleted(or GC invoked on that object) right now. All other objects can be GC'd as done now.

    Or, let me create stack based objects with the destructor called before the stack pointer is moved back (the frame removed). I can close connections, files, release resources at that time.

    GC just kind of shifts problems it doesn't really solve anything.

    Paradoxically explicit deletes along with deterministic destructor calls make it easier to manage correctly resources including memory: smart pointers, etc.
  17. Sartoris: “If I call delete someObject I want the destructor called for someObject then I want that sucker deleted(or GC invoked on that object) right now. […] I can close connections, files, release resources at that time.”

    If it’s just to release some resources associated with the object, you can provide, e.g., releaseResources() method to do just that. Would you care to clarify how ‘delete object + destructor()’ is better than ‘object.releaseResources()’ (that you can do in Java now)?

    -- Igor
  18. <sartoris>
    We can send people to the moon this should be a piece of cake;-)
    I don't see it as an either-or proposition.
    </sartoris>

    Of course it's technicaly possible, the question is: does it make sense?

    If you allow the programmer to explicitly delete some objects while others are taken care of automatically, you are basically removing all the benefits that a GC brings and re-introducing a host of problems that we, former C++ programmers, used to have nightmares about (I am not kidding).

    Suddenly, programs start dereferencing memory that has been free or double-deleting objects, and hell breaks loose.

    I know that you probably only intend for this feature to be used in local scopes, but trust me, it will be bent out of shape in no time and next thing you know, we are all spending more time fixing memory bugs than focusing on our business logic.

    Besides, you are also neglecting the fact that GC's have become very good. Both in how little impact they now have on the execution of your program, but also how good they are at leaving less and less dead objects lingering.

    Just say no to explicit garbage collection :-)

    --
    Cedric

  19. "you are basically removing all the benefits that a GC brings and re-introducing a host of problems that we, former C++ programmers, used to have nightmares about (I am not kidding). "

    I was exclusively a C++ developer for many years 94-2000. And a C developer from 1988- 94. I am well aware of resource management problems in C and C++. They are overstated a bit in C++, though, I think. There are many good techniques to help manage resources.
     
    GC helps in some areas but hurts in others. The lack of stack based objects is the #1 problem. The overhead of creating and managing heap based objects is not negligable.
    If you've ever profiled a Java app (like a web app) that has very high number of execution cycles and you'll see the massive amount of heap resources that are created and left to be managed. Waving your hand and saying "GC will take care of this just fine" is whistling past the graveyard.

    Java needs to grow to have a chance to survive long term. It is deficient in many ares.

  20. Sartoris wrote:
    >
    >If I call delete someObject I want the destructor called for
    >someObject then I want that sucker deleted(or GC invoked on
    >that object) right now.

    You want the sucker deleted even if it's still reachable elsewhere?!?

    >Or, let me create stack based objects with the destructor
    >called before the stack pointer is moved back (the frame
    >removed).

    But what if those stack-resident objects were also added to a heap-resident Collection?!?

    >GC just kind of shifts problems it doesn't really solve
    >anything.

    Garbage collection solves several problems:
    - leaks
    - stale references
    - client code bloat
    - reclamation stealing cycles from high priority work
  21. A Layer on top of J2EE[ Go to top ]

    I think we need a tool/layer on top of J2EE that helps build out software automatically. We all spend way too much time building stuff manually...Check out http://www.bowstreet.com/downloads/

    - Akash
  22. A Layer on top of J2EE[ Go to top ]

    Are you paid by boxstreet? This is already the second thread on theserverside i see you mentioning their product. Maybe you should move your ads to /dev/null
  23. A Layer on top of J2EE[ Go to top ]

    Are you paid by boxstreet? This is already the second

    >thread on theserverside i see you mentioning their
    >product. Maybe you should move your ads to /dev/null

    And if you go the site half the links don't work. Real good advertising for a company purporting to sell a J2EE framework that makes things easier.
  24. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Wow... yeah... I've got to agree with the pro-gc people. I spent much of the last couple years writing database drivers (JDBC, SQLJ, etc) that were combinations of Java and C/C++ code.

    Its incredible how sickening it is to try to figure out where the the problem is when you have 10,000 threads pounding a database as hard as they can and your code causes a system crash after 7 days of running because you were not freeing just a little something every once in awhile.

    Objects are a beautiful thing in nearly all application domains. The system taking care of the objects life cycle is a beautiful thing in nearly all application domains. I'd go so far as to say that if you have a problem that needs more explicit control of deletion than GC (given the releaseResources() suggestion earlier), it probably isn't suitable to Java.
  25. You want the sucker deleted even if it's still

    > reachable elsewhere?!?

    I think what he was referring to was giving the garbage collector a hint that now is a good time to get rid of this object if possible and anything else it references that can be removed. This should invoke a limited garbage collection cycle to clear the object and any children in the graph. It could either do nothing if the object is referenced elsewhere or raise an exception.

    A lot of this revolves around GUI processing where the user expects pauses in particular spots. For example, if I close a dialog why not give the GC a hint, hey get rid of this dialog now because the user is epxecting a small pause rather then wait until the user is in the middle of typing something and you have to GC to free space.

    Gerald
  26. <Gerald Nunn>
    ...giving the garbage collector a hint that now is a good time to get rid of this object if possible and anything else it references that can be removed.
    </Gerald Nunn>

    System.gc(); -> you mean something like this?

    later,
    Dan
  27. System.gc(); -> you mean something like this?


    Yes but more specific and pratical. System.gc() rarely does anything at all, I'd like to see something where you can go System.gc(SomeObject) where it guarentees to gc the object and it's graph if the reference passed in is the only reference to that object.

    It's possible that setting the object reference to null and calling the normal System.gc() may clear it, however it may also do nothing or do to much. What I am suggesting is giving a more explicit hint to the gc.

    Gerald
  28. "...I'd like to see something where you can go System.gc(SomeObject) where it guarentees to gc the object and it's graph if the reference passed in is the only reference to that object." -- Gerald

    So, what would the following program do?

    public class Test
    {
       public static void main (final String args[])
       {
          final Object obj=new Object();
          System.gc(obj);
          System.out.println(obj); // Already garbage collected!
       }
    }
  29. So, what would the following program do?


    Why not throw an exception? Perhaps when the object is GCed have the GC set the reference to null.

    Gerald
  30. "I think what he was referring to was giving the garbage collector a hint that now is a good time to get rid of this object if possible and anything else it references that can be removed." -- Gerald

    Garbage collector throughput is measured by the number of bytes it reclaims in a given amount of time. I think it more likely that a garbage collector would have less throughput if it's frequently jerked away from system-wide collection by an application obsessed with immediate attention to local crumbs. I have a hunch that explicitly targeted synchronous collection is inherently degrading to asynchronous system-wide collection. The thread coordination might be too costly.

    One possibility would be for the Java developer to optionally flag local variables with the 'transient' keyword. The JVM could be amended to stack-allocate transient locals. The JVM could throw a RuntimeException if a stack-allocated object's reference were ever assigned to a heap-allocated object's field. That guarantees heap integrity. The JVM would also have to throw an exception if the reference of an object residing in a younger stack frame is assigned to the field of an object residing in an older stack frame. That guarantees stack integrity.
  31. Garbage collector throughput is measured by the number of > bytes it reclaims in a given amount of time. I think it > more likely that a garbage collector would have less

    > throughput if it's frequently jerked away from system-
    > wide collection by an application obsessed with immediate
    > attention to local crumbs. I have a hunch that explicitly
    > targeted synchronous collection is inherently degrading
    > to asynchronous system-wide collection. The thread
    > coordination might be too costly.

    I suspect that in overall throughput you would be correct in that it would be slower. Many small gc operations would likely take more time then a single large one. The benefit though is controlling when it occurs, which is huge for GUI apps. As mentioned previously, the user expects to see pauses in certain places, this idea simply leveredges that expectation. Additionally, the developer can program against it by showing an appropriate UI element like setting the cursor to an hourglass.

    For example, when I open and close a dialog in JBuilder, I expect to see a small pause on the close. However, I don't expect JBuilder to be locked up for ten seconds when I'm in the middle of typing code which JBuilder did frequently the last time I used it.

    Java currently tries to help minimize these pauses with by enabling incremental GC, I'm suggesting taking it a little further and putting some optional control over the process in the developers hands.

    Gerald
  32. "Garbage collection solves several problems:
    - leaks
    - stale references
    - client code bloat
    - reclamation stealing cycles from high priority work "


    - Leaks still exist.
    - Stale references still exist.
    - Code is still bloated in cases where finally must be used to be sure to close/free some resource.
    - deleting resources sometimes should be high priority work.
  33. <Cedric>
    How long in this thread before somebody asks for generics in Java 3.0? :-)
    </Cedric>

    How about a REAL meta objects? Revisiting Smalltalk would be a good idea.

    The sun no longer sets me free,
    Greg
  34. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Regarding expensive of OO primitives:

    That was really interesting information that I did now know. Thanks Dave. Previously I had been thinking that Java may have screwed up here, but now I'm thinking they were right on in finding a balance.
  35. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Here is a great example of the real issues with boxing/unboxing in C#.

    http://www.geocities.com/csharpfaq/box.html

    Dave Wolf
    The Scupper Group
    dave at scuppergroup dot com
  36. Dave Wolf wrote:
    > Here is a great example of the real issues with
    > boxing/unboxing in C#.
    > http://www.geocities.com/csharpfaq/box.html

    Thanks Dave,
    When I first read about boxing/unboxing I thought it might have undesired side effects, but all the C# guys seemed to think it a boon. Nice to see an article that debunks that...


    OK, my 0.5 euros on the 10 points - top three first:

    6 (fix threads) - YEEEEEESSSSS. WE MUST FIX THE MEMORY MODEL ASAP. IT IS UTTERLY BROKEN. (Yes I am shouting - this is important! I am also banging my fist on the table!). I cannot believe that no-one on this thread has mentioned this.

    Why is this important: Because it is generally reckoned that nobody on the planet actually understands the current spec! Where has the JCP committee on that gone to? Come on Doug and the others, you can do it!

    8 (remove Primitives) - Definitely NO. I do financial software in Java. No primitives == excess object allocation == bad performance == I go to C#!

    2 (redesign I/O) - Yes, but for different reasons. The main problem with IO classes (and AWT for that matter) is that the base entities are classes, not interfaces. Look at collections for the correct approach - the contract specifications are all done as interfaces. Using abstract base classes as a specification of functionality is wrong and makes reuse even slightly outside of the original designers vision almost impossible. WHY are Reader and Writer abstract classes - they shouldn't be...


    As for the rest...

    10 (remove deprecations) - Yes.
    9 (fix naming) - No. It's all subjective anyway...
    7 (4 byte char) - not worth the pain.
    5 (convert files to XML) - spoken like a true XML book author! Do we really want properties file in XML? Only if they need to be hierarchical...
    4 (ditch AWT) - Yes, but in favour of SWT! ;-)
    3 (rationalize collections) - that's just 10 repeated.
    1 (redesign classloading) - Sorry, no sympathy. Any half decent Java programmer should understand at least the basics of classloading. I don't think a redesign would be possible... the requirements already placed on classloaders apply too many constraints to allow much change.

    /david
  37. I pray they always manitain backwards compatibility - at least in the runtime, if not in the SDK. Otherwise we are in for two years of multiple JVM's for your Oracle JDBC v's Weblogic v's IDEA v's Tomcat v's Jboss v's jaxp v's JCloak etc etc. i.e. they would all upgrade at different rates screwing up all but the greenfield projects who reinvent the wheel.

    Jonathan

    p.s.I hate templates. They are always overused and abused. Java's initial simplicity was superb.

  38. well my 2 cents worth -

    i think depending on where u are applying the language u need different feature

    1. currently i am writing software where i need to plug in to different kinds of algorithms etc and i could kill for generics and function templates coz my basic steps of function remain the same

    2. I have previously written financial apps and i can tell you it is a horrible torture to make primitives to objects. Rather we need objects to behave like primitives something c++ was adept at doing on account of operator overloading. At the very least we need to overload cast operators

    3.i think we need rules built into language - something prolog like because some rules just involve numerous objects

    4. most java programmers dont understand modularity - every c++ guy understands it due to exposure to dlls etc - so java programs end up huge object oriented monolithic wholes

    5. mda is going to be unpopular among developers - especially contractors - they want to copyright mda s they generate just like engineering blueprints were copyrighted
    or licensed or whatever.I mean the model u generate is your IP - ( anyway i have heard loads of mutterings to the effect)- especially now with maintainance getting outsourced etc contractors simply dont leave around documentation
  39. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Well, that's quite misleading. The expense of a boxing operation is due the creation of a managed object. In other words, it's as expensive as creating an instance of a reference type. In other words, not very expensive.

    Unboxing consists of computing the address of an existing value. In other words, not very expensive.

    The point is that by treating value types as reference types, you simply negate the performance benefits of using them in the first place. This doesn't mean that there aren't benefits to treating value types as objects (code readability and simplicity being two), but the performance gains of value types come when they are treated as value types.

    (And to use the inverse of your argument, it is INCREDIBLY expensive to create a new object, which is why value types exist).

    Jim
  40. Boxing is actually not expensive at all.

    First of all, a reasonable compiler will optimize out most of the boxing operations.

    And secondly, one can use the old Lisp fixnum trick. Fixnums are (typically) 30 bits and so can be stored in a pointer directly. They can be distinguished from pointers given that objects are 4 byte aligned, and so must have 00 (say) as the last two bits.

    This technique can make boxing more efficient that Integers or equivalents in C++.

    And the Sun Sparc (at least) has special instructions that can manipulate fixnums efficiently.

    There is more to life than C primitives and basic PDP-11
    architectures!

    A similar argument can be made for detecting integer overflows. This costs virtually nothing if done properly using even i86 architectures.

    In general, I hope that C# will put a rocket under the Java language.
  41. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Well, what should change may be debated but change is required, if aging of java is to be avoided to keep it young. Time always comes when history should be put in museum and new & better should be adapted.
  42.     Harold misunderstands some important things when he says "The floating point operations are defined by IEEE 754 and, for compatibility with other languages and hardware, it's important to keep that." First of all, Java isn't IEEE 754 compliant. In fact for serious numerical work Java is practically useless. Java doesn't even do formatted IO for numeric types.

        This leaves two options when it comes to fixing Java:

        1) Make Java suitable for numerical work. This means leaving primitive types in the language, making it fully IEEE 754 compliant, and adding support for formatted IO. (Look at how FORTRAN does formatted IO for guidance, not C.) In addition a primitive type and wrapper type should be added for complex numbers.

        2) Make Java more of a pure OO language by dropping the primitive types and forget about using it for serious numeric work. You can forget about IEEE 754 compliance in this case.

        Harold's suggestions do the latter, but it is ridiculous to invoke IEEE 754 in this case. Most modern hardware is optimized for IEEE 754 arithmetic so it makes no sense to wrap numeric types inside objects just to unwrap them to get to the optimized hardware only so you can wrap the results back up inside objects again. If you want to make use of that IEEE 754 optimized hardware don't put the clutter of object wrappers in the way. Only Smalltalk programmers think this is a good idea.

        Right now Java doesn't do either of these, displeasing both numeric programmers and pure OO enthusiasts. It would be more beneficial and less traumatic to change Java along the lines of 1) instead of 2).
  43. First of all, java is IEEE 754 compliant. If you read the language specification in http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9208 , you can see that all VM are required to support IEEE 754 compliant float and double sets. Nevertheless, all VM can have a second set, which is not standard. If you need to use the IEEE 754 compliant set (for compatibility, or any other reason, you can use "strictfp" where you declare your classes.

    For formatting of numbers, you can use NumberFormat subclasses. For instance, with DecimalFormat you can format float and doubles. It's much better than C-style. I have not used Fortran, so I don't know how formatting is done in that language (by the way, is it the same for all versions of Fortran?).

    That's all. I don't want to bother anybody, but you cannot say Java is not IEEE 754 compliant without checking the language specification. It's explicity written that it is :)
  44. Hi Daniel,

    Visit http://http.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

  45.     It looks like Java's numerics have improved in recent versions, but is strictfp actually implemented in the JVMs? I'm also not sure if Java implements the different kinds of NaNs properly.

        As far as using NumberFormat as a base class for formatted I/O do you have some sample code? When I had to do formatted I/O in Java I found NumberFormat to be useless as a base class and wrote the whole thing myself. One of the Java books also has code in it to do C style formatted I/O and if I remember correctly it doesn't use NumberFormat.
  46. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    latest java API
    http://java.sun.com/j2se/1.4/docs/api/

    java.text.DecimalFormat nb = new java.text.DecimalFormat("0.##");
    double num = 1111.1111111;
    System.out.println(nb.format(num));

    If you take a look at your console you'll see
    1111.11 printed.
  47. In what respects to J2EE, A newer version should be considered if a significant part of the Community believes in one or more of the following observations:

    1. J2EE should take into account new Software Engineering initiatives, specially those proposed by OMG around the MDA.

    2. J2EE requires optimization to better exploit resources
    from high-end servers and deliver the expected performance and no less. This may include major involvement of the JCP in the implementation and not only in the interfaces; not that they should rule specifically on what the implementation would contain, but to advice on best practices to assure improved performance.

    3. Although J2EE is not supposed to be an all-purpose platform(the panacea sort of speak) it should consider new tendencies of the industry, and not merely middleware. Specifically, the inclusion of DataWarehousing concepts, and Metadata driven development. (Of course, this would be nice in a nearer future, when the whole WebServices Mumbo Jumbo is definitely set)
  48. "J2EE should take into account new Software Engineering initiatives, specially those proposed by OMG around the MDA." -- Adolfo

    I agree that the JCP should standardize MDA, but I doubt J2EE is the right kit. Modeling has value on every tier, so MDA belongs in J2SE.
  49. <quote>
    ...removing confusing and unnecessary classes like StringTokenizer...
    </quote>

    I don't see why StringTokenizer,I find it quite useful especially when it comes to parsing data
  50. <quote>
    likely to encompass fictional scripts like Tolkien's Tengwar and dead languages like Linear B
    </quote>

    At last ! This really is a critical requirement for my current project.

    :-)
  51. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Having recently spent a fair amount of time mentoring the guy next to me in moving from Fortran (yes people still us it) to Java, the main problems that came up and which I would add to any refactoring of Java are:

    - Sort out the whole Date / Calendar / DataFormat stuff. This caused him no end of confusion.

    - API simplification so that there is a single, clear and obvious way to achieve each thing you want to do. As the API has grown it has become far too confusing for those who havn't been following it from the beginning.
  52. I totally agree that the Date / Calendar classes should be replaced with something more intuitive and consistent. However, at least once you have an understanding of these classes you can achieve what you want without too much effort.

    I find the most infuriating problems with Java are the ones that affect you most often, on a day-to-day basis. The extra time and effort (and frustration) required to work around these issues really adds up... So here are my five pet peeves:

    1. Lack of generics (touted, finally, to be included in JDK1.5). I am sure most people are, like me, tired of either having to write their own type-safe collection wrapper classes, convert back-and-forth to arrays when they need type-safety, or put up with the type-unsafeness of the standard Collection classes...

    2. Sort out cloning - There are a number of problems with using the Cloneable interface (see Effective Java, Joshua Bloch for details). IMHO cloning/copying is a very basic and frequently used operation which should be achievable with the minimum of effort. I'd like to see deepCopy() and shallowCopy() methods automatically available from all objects unless they explicitly flag that these should not be available. The deepCopy() method would automatically call deepCopy() recursively on its child objects. Only mutable objects would be copied (see item 3 below).

    Currently you frequently get into the situation of defensively copying objects that are mutable before you pass them to a method as a parameter and then that method copies them again. This is inefficient and requires diligence by the developer.

    However this could potentially be alleviated by the following two items:

    3. Explicit language support for immutable objects (and for obtaining an immutable ‘copy’/view of a mutable object). This would appear to be relatively simple to add to the language. A class with an immutable modifier would not be allowed to have any methods marked with the mutable (/mutator) modifier. Similarly requesting an immutable copy of a mutable object would only allow the client access to methods marked with the immutable (/accessor) modifier (I use the world ‘copy’ loosely; producing an actual memory copy of the object should not be necessary as the JVM could instead just control access rights to the existing mutable object). The compiler could then ensure that classes adhere to this contract by disallowing immutable (/accessor) methods from accessing the mutator methods of any non local scope objects or from changing any member variables.

    4. The addition of a new modifier for method parameters which would allow you to specify that method parameters (objects) should be passed by value (and when I say ‘by value’ I mean a real copy of the object, not just copying the reference).

    5. Type-safe constants are currently too much like hard work. Anything so basic and used so frequently in a language should not require the developer to have read books like ‘Effective Java’/’Practical Java’/’Java In Practice’ before they can do it right... How many other people did (do) not realise the implications of not implementing readResolve() for type-safe constants in a distributed app? Language support is required here.

    From my own point of view as a server-side J2EE developer, I also think that the language could be changed to offer more support for components, component-based development, and distributed computing... Any ideas here?

    I agree that language stability and backward compatibility is very desirable. However, if this means that Java is not allowed to evolve to meet developers’ needs then it will inevitably be superseded by new languages which better meet those needs. Personally, I would rather have a better Java language and take the hit on having to do a bit of refactoring...

  53. <q>
    3. Explicit language support for immutable objects (and for obtaining an immutable ‘copy’/view of a mutable object)
    ....
    </q>

    Yep const references (immutable) and const methods (immutable accessors) (as in C++) would be very nice feature in java. Right now for example getBounds in many GUI related components returns cloned copy of bounds (instance of Rectangle). What's happens if some mofo will call it in a loop ?
    But of course we don't need const_cast in Java :)

    Giedrius

  54. Gavin, some thoughts about your post...

    - Yes, I have always found the Data/Calendar stuff to be god awful. Muy confusing until you have worked with it for a while.

    - Generics will be great. I don't like casting all of the time, and type-safe wrapper classes lose the abilitity to take advantage of the Strategy pattern the collections gives you in the first place - applying sorting/filtering algorithms to a collection. Generics should take care of both of these things.

    - I don't use clone() much (ever). But it seems like deepCopy() supported at the object level could lead to some nasty problems. Seems you would be better handling this based on the app.

    - Ditto for the pass-by-value thing. I don't see this being of much use, and it looks like the impacts would be large for this as well.

    - I don't see why you would want language support of a type-safe enumerations. This pattern gives you a lot more than other languages enumeration (AFAIK), and I think it is "high-level" enough not to warrant build-in language support. Perhaps a better solution is to create a type-safe enum template in your IDE provides a skeleton class that uses this pattern (readResolve method and all). Just because something is common, useful, and complex at the same time doesn't mean it should be build into the language to that everybody can use it.

    Ryan

    P.S. I am all for a "major" release (2.0, I mean Java 3, I mean 3.0, ...nevermind) that "reworks" some core language things that everybody agrees are bad. Nobody gets it right the first time. This is not a reason to let crappy APIs linger for all of eternity.
  55. Hi Ryan,

    In reply to your post:

    “I don't use clone() much (ever). But it seems like deepCopy() supported at the object level could lead to some nasty problems. Seems you would be better handling this based on the app”

    It is hard to tell from your post, but I am presuming that you do defensively copy mutable objects before passing them to methods owned/written by other developers (see Effective Java, Joshua Bloch, item 24 “you must program defensively with the assumption that clients of your classes will do their best to destroy its invariants”). If so, and you do not use clone(), how do you make copies? Do you write your own copy constructors for each class you might need to copy?

    The basis for my comment was that, if you agree that defensive copying of mutable objects is a good thing, then having built-in language support for copying (and allowing you to override it if for some reason you need to do something different from the norm), instead of having to code it everything by hand, seems like it can only be a good thing? Surely copying is one of the most basic, fundamental operations you can perform on an object and therefore should be properly supported by the language? Perhaps I am missing something, but I can not see why you have an issue with this?

    “- Ditto for the pass-by-value thing. I don't see this being of much use, and it looks like the impacts would be large for this as well.”

    This falls under the same arguments as above: defensive coding, etc.

    “- I don't see why you would want language support of a type-safe enumerations. This pattern gives you a lot more than other languages enumeration (AFAIK), and I think it is "high-level" enough not to warrant build-in language support. Perhaps a better solution is to create a type-safe enum template in your IDE provides a skeleton class that uses this pattern (readResolve method and all). Just because something is common, useful, and complex at the same time doesn't mean it should be build into the language to that everybody can use it.”

    I think my argument is the exact opposite of yours here... I am of the belief that if something is common, useful, and complex then it SHOULD be built into the language. There are a number of reasons I take this stance:
    1. Numerous studies have been done which show that the greater the number of lines of code, the greater the number of bugs – therefore any language feature which helps to reduce the amount of code required to implement a feature must be a good thing.
    2. It is frustrating having to type extra code. Whilst I agree that templates can help here, it is still easier to make errors amending the template code than if using a standard language construct.
    3. Surely the whole idea is to make languages more high-level? The better a language is at abstracting common problems, the more useful it is. A higher-level language makes life easier for the programmer, is quicker to program in, makes code safer/more robust, easier to maintain, etc, otherwise we would all still be programming in machine code...

    Regards,
    Gavin
  56. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    someone else wrote:
    <quote>
    5. Type-safe constants are currently too much like hard work. Anything so basic and used so frequently in a language should not require the developer to have read books like ‘Effective Java’/’Practical Java’/’Java In Practice’ before they can do it right... How many other people did (do) not realise the implications of not implementing readResolve() for type-safe constants in a distributed app? Language support is required here.
    </quote)

    Can someone please enlighten me why you need to implement readResolve() for type-safe constants in a distrubuted app.? I am familiar with the type-safe Enum pattern, but I don't see how that relates to the readResolve() method.

    Thanks.
  57. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    Hi Mike,

    Please see the following JavaWorld article and 'letter to the Editor' for a full explanation:
    http://www.javaworld.com/javaworld/javatips/jw-javatip122-p2.html
    http://www.javaworld.com/javaworld/jw-01-2002/jw-0125-letters.html

    These explain the use of readResolve and also why classloader issues mean that the type-safe enum pattern is effectively unusable in J2EE apps.

    The author of the article, Vladimir Roubtsov, states "The typesafe enum pattern may require too much work to be truly safe in all situations, especially if your runtime involves serialization or a complex classloader structure -- typical elements of Java 2 Platform, Enterprise Edition (J2EE) applications. In certain cases, it won't work at all. As such, the pattern is an unreliable substitute for a basic feature that the Java language lacks: a compiler-supported enum feature. In many cases, you're better off using the good old set-of-static-primitive-values enumeration."

    Regards,
    Gavin.
  58. The "static final primitive" approach works fine for dummy type values. But what if you actually want an enumeration of OBJECTS. This is very powerful.

    If you want to have different behavior for each value in your enum, you don't have to have some stupid, fragile switch statement. You can have all of the enum'd objects implement a common interface and implement their own specific behavior. OO - what a concept!

    To me, this is where a type-safe enums (how they currently have to be implemented in Java) really pays off. Can THIS type of structure be built into the language, not just the dumb C-style enums? If not, it really doesn't buy you anything if you ask me.

    Ryan
  59. Java 2 - 1.2, 1.3, 1.4, 1.5
    Java 3 should just start from 3.0

    After all, we've experienced versioning systems that followed no particular order before. (3.1 -> 98 -> me -> xp.)
  60. Enumerated Types[ Go to top ]

    There has a new enumerated type in jdk5.0 to solve this problem(generally referred to simply as an enum). http://www.developerzone.biz/index.php?option=com_content&task=view&id=127&Itemid=36
  61. Enum types[ Go to top ]

    Are not unsafe only from the serialization point of view, but also from classloader point.
    For example, if your app server's web-layer has an entirely different class loader from the ejb (as most of them do by default), and you switch on optimization of local calls (i.e. the parameters don't get serialized and de-serialized), you have the problem back.
    I think that the classloader stuff should be better explained in general, as it seems that even though it's much more widely used than it was, not too many people understand it (and wonder why their enums, stateful singletons etc. don't work).
    Regards,
    Vlad
  62. I've never heard of the strange class loading behavior he describes in his article ( the fact of an object of class B implementing interface A not an instance of interface A when A and B are loaded by two different class loaders)

    Can anyone here describe more fully this behavior and possibly give a sample code that reproduces it ? I made a simple test and it does not seem to work :

    1 - I load the interface, say A, via the default class loader by just calling Class cl = A.class ;

    2 - Then i load the class B implementing A via an URL class loader (wich parent is the default class loader). I manage to keep B.class unavalaible by the default class loader - to enforce class loading via http)

    3- Create an instance of B. ... and ... And it **is** an instance of A!!!!

    Any enlightenment on this issue would be highly appreciated.

    /hermann
  63. I got it !

    Now i can make my example run and i correctly reflects this class loading behavior .... (B implements A and, say b an instance of B, (b instanceof A) return false)

    /hermann
  64. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    And no one has mentioned deterministic cleanup? Or was that implied by the discussion of explicitly deleting objects.

    The point isn't to reclaim memory; any decent garbage collector can do that. It's to free up other resources (database connections, sockets, etc.) in a predictable manner.

    Requiring try/finally blocks is too error-prone. .Net offers the IDisposable interface; if your object implements it, the Dispose() method is called immediately when the reference count drops to zero.

    IMO, this is the biggest weakness of Java relative to .Net.
  65. Interesting. What happens if code in dispose() results in exception? Where (in code) will it be reported?

    -- Igor
  66. Article: 10 Reasons We Need Java 3.0[ Go to top ]

    ".Net offers the IDisposable interface; if your object implements it, the Dispose() method is called immediately when the reference count drops to zero."

    No, that's not quite how it works. For a start there's no reference counting. Dispose() has to be called explicitly by client objects, although C# has syntax to make it less painful.

    A Finalize() method can be called automatically during GC, but that's a last resort in case clients fail to call Dispose().

    In short, unmanaged resource disposal in .Net is really just a pattern with some bolted-on support in the class library (IDisposable) and in C# (the 'using' statement). No magic bullet.

    Jim
  67. Just dropping the deprecated stuff and fixing/simplifying the confusing date classes would be a great start.
  68. <quote>

    how long will it be before some one asks for generics in java 3

    </quote>

    well we have gone ahead and done the whole stuff in c++
    jdk1.5 for a robust generics impl was just too late for us
    and we could not take the chance of slowishness etc etc
    i wonder how many firms with tight time to market and with the added pressure of having to impress the customers first time right are taking that decision - and once u ve done it smart pointers , custom gui componernts .. the whole shebang
    ....