10 Reasons We Need Java 3.0
Subject:   a bunch of amateur ideas...
Date:   2002-08-05 08:20:29
From:   morbid
There are many more important areas than need fixing before "all property files become XML" etc:

- clone() needs to work with inner classes;
- clone() needs to work with final fields;
- clone() needs to be a public method of Clonable;
- the language needs built-in typesafe enum support;
- the language needs support for generic types (List<int>));
- it should be decided once and for all whether final fields could be changed via reflection or not;
- Externalizable should work with final fields;
- it should be decided once and for all whether the current or the thread context classloader is used for implicit dynamic resource loading;
- API needs cleaning up;
- custom URL schemes need better support;

Full Threads Oldest First

Showing messages 1 through 4 of 4.

  • a bunch of amateur ideas...
    2002-08-12 11:16:43  jacyg [View]

    mostly good, but clone() should not be a public method. See
    for a better solution. The reason clone() should not be public is that it you may not *want* to externally expose the ability to clone an object, and having a clone() that is protected allows you to accomplish this. My proposed solution still gives this ability when truly wanted, without sacrificing the ability to keep clone() restricted.
  • more...
    2002-08-05 08:28:33  morbid [View]

    - .class custom attributes should be accessible programmatically, via ClassLoader API;
    - covariant return types should be supported;
    - the language should support a proper notion of const-correctness;
    • Even more...
      2002-08-06 05:31:22  styro [View]

      Most of the points mentioned by Rusty Harold are things that you stumble over when you write books, whereas you point out things that seem to stem from experience in using Java in large scale project (especially the const problem is my prime candidate when debugging).

      I 'd like to add a few ...

      - synchronous destructor/finalizer (in order to use powerful idioms such as allocate/lock-in-ctor, dealloc/unlock in destructor/finalizer). N. B. this does not have anything to do with GC and meory management, there are way more sresources to manage than memory
      - replace String and StringBuffer with String and MutableString (both supporting + operator etc.)
      - operator overleading (I want to define operators for my value types)
      - Fast GUI (move event dispatch to native code)
      • Even more...
        2002-08-12 11:30:44  jacyg [View]

        I agree, though I hadn't thought about it, that Rusty's issues are realy more of an author's, rather than developer's problem. Well said.

        I do take issue, however, with the operator overloading. It's sugar, and it can seem sweet, but it's not good for you. In a large application that uses different libraries, if those different libraries have different operator overloads, keeping track of them can be difficult, and your code can have very well hidden errors (such as could result from using the operators in the wrong order). Now, you may say, "I would do better." but it's really not a good thing for the language. It would not enhance the stability and reliability of the general code-base. And it doesn't add any functionality that doesn't already exist with methods. *And*, if you do implement the funtionality with methods (.add(TypeA, TypeB)), there is a much lesser chance that a programmer could goof and inadvertantly use the wrong method. Operator overloading is just a different method syntax, but it puts the burden of figuring out which method on the compiler rather than the developer, and that's just bound to cause problems.