Java's Continuing Evolution

Discussions

News: Java's Continuing Evolution

  1. Java's Continuing Evolution (25 messages)

    "In the face of challenges, can Java solidify its position as the current programming language du jour? Only if it can adapt". An November Java Pro article raises some interesting points about the continuing expansion of the base Java language and framework and comments Jini, the emerging role of Aspect Oriented Programming (AOP), and several new language-changing JSR's.

    Read Java's Continuing Evolution.

    Threaded Messages (25)

  2. Java's Continuing Evolution[ Go to top ]

    O'Reilly post an article a while called "10 Reasons We Need Java 3.0" with some good suggestions to help Java keep up.

    http://www.onjava.com/pub/a/onjava/2002/07/31/java3.html
  3. Java's Continuing Evolution[ Go to top ]

    In addition to O'reillys list it would be nice to see:
    <b>const references and const methods</b>
    Because right now if you want to expose some internal state of object to outside world you need to clone that state. But const references and const methods will elminate that need. It means less work for gc and greater performance.

    <i>
    const Rectange getBounds() const
    {
      return bounds;
    }
    </i>

    Current aproach is to clone bounds and it sucks.
  4. Java's Continuing Evolution[ Go to top ]

    You can get a large amount of the benefit of const objects by simply defining immutable interfaces for your objects. Then, the return values simply use the immutable interfaces.

    By not providing mutating methods in the interface, you make your intentions very clear as to what the object is used for. Contrast this with const objects, where the client developer can overlook the const and try to use a non-const method (with the obvious result).

    Of course, this does not provide the full security of const objects; the client developer can always cast the object to a mutable type. However, if your intention is to prevent casual misuse (as opposed to deliberate abuse), this is a sufficient technique.

    (Note that if you did have const objects, you should still provide the immutable interface anyway...)

    Robert.
  5. Java's Continuing Evolution[ Go to top ]

    Yep I agree, but in most simple cases it's enough const references and methods. And of course in some complex case you need to separate contract (interface) to mutable an imutable. Anyway they should include const stuff into language.
  6. And of course in some complex case you need to separate

    > contract (interface) to mutable an imutable. Anyway they
    > should include const stuff into language.

    At first it seems very nice to have const, but I found in C++ I got into situations where const decisions slowed down the development process and became a pain - having to back out the 'constness' of whole trees of calls because of a tiny internal modification at some point in the process. After all lazy loaders can't be const - even though the outside world views it as a const operation...

    At other solution, of course, is the rather evil 'casting away' of const that can occationally be necessary in even the best code: Tree rebalancing which can occur in const reader methods, etc.

    Having implicit ('getters') read only methods seems (most of the time) to be quicker and easier.


    In terms of immutability - the Read-Only Adapter pattern in Doug Lea's Concurrent Programming in Java, Second Edition (p.132. If you don't have the book, you really should have!) is to me the most elegant solution if you need (say for security) something to be seen as being const in certain circumstances.

    If security isn't a concern (and you trust your developers not to be evil and cast straight to the mutable version), then mutable and immutable interfaces (or even immutable interface with mutable implementation) is more straight forward.

    I guess the other important point to mention is that good naming conventions become much more important in the absence of language constraints.

    /david
  7. <snip>
    At first it seems very nice to have const, but I found in C++ I got into situations where const decisions slowed down the development process and became a pain - having to back out the 'constness' of whole trees of calls because of a tiny internal modification at some point in the process. After all lazy loaders can't be const - even though the outside world views it as a const operation...
    </snip>

    Of course they can, that is what the mutable keyword for internal members is for. Const is language construct to implement the concept of Object const-ness. If the external view state of the object is const for a function, the function is const. That doesn't mean that internal lazy cache attributes or the like may not change within the internal representation.
  8. Of course they can, that is what the mutable keyword for

    > internal members is for.

    <grin/>

    OK, I remember now! My last brush with C++ was 5 years ago (thank goodness: Should we spend the whole day discussing virtual-multiple-inherited constructor call sequences, or should we actually write a program? Hmmmm.) and IIRC that was only just getting compiler support at that time. Or it could be that I didn't know how to use the language ;-)

    This does bring up the issue, though: Java was designed to be simple, to allow the programmer to focus on what they want to write, not how. Adding two new keywords purely to add what you can pretty much do with design seems unnecessary.

    After all, time spent learning design can always be carried forward to new languages, unlike time spent learning syntax. Personally, I feel I've learnt much more about _design_ over the last 5 years with Java than I did in the 9 years before that.

    /david
  9. Creation of immutable interface is design ? Why to write extra code if you can solve it by using language features ?.
    VB was designed to be user friendly too ...
    I don't think that const stuff is complex if it is complex then you should use VB instead of Java.
    I agree that C++ was complex langauge: virtual constructors, copy constructors, type slicing and so on ... But const stuff is simple and elegant in C++ why note use elegant ideas in Java to make it better ?.
    I agree that pereprocessor stuff is nasty feature, because you will end up with code like this:
    #ifdef JAVA_1.1
    #endif
    #ifdef JAVA_1.2
    #endif

    and it sucks. It can be solved easy by using interfaces and different implementations for different JDK versions.
  10. Creation of immutable interface is design ? Why to write

    > extra code if you can solve it by using language features ?

    Putting the getters into one interface and the setters into a subinterface is hardly likely cause you to have to lie down in a darkened room for a while, is in now? ;-)

    > I don't think that const stuff is complex if it is complex
    > then you should use VB instead of Java.

    I think that is a little naive: The const concept introduces three keywords into the language (const, mutable, const_cast), and you have to think through the side effects of this property all of the rest of the system - all of the corner conditions: C++ allows methods to be overloaded on the const attribute. Should Java?

    > why not use elegant ideas in Java to make it better ?

    Because (as C++ found to its cost), combining a number of elegant features together becomes complex, confusing and inelegant. A C++ FAQ that I found had thirteen FAQ entries for const. THIRTEEN? How can that be for such a 'simple' feature?

    Anyway, these people clearly aren't wild fans:

    http://duramecho.com/ComputerInformation/WhyHowCppConst.html
    http://www.cs.duke.edu/csed/cplus/const/

    I'll leave you with a quote from the second article:

    "Programming with const can be painful."

    Cheers
    /david
  11. Java's Continuing Evolution - const[ Go to top ]

    Const correctness in C++ *is* a PITA when your project doesn't **start out with const correctness***, but so is static typing and declaring methods private and protected. If you've ever tried to convert a Smalltalk or Objective C program to C++ or Java you know how much of a PITA it is to add static typing restrictions. However, once you've set it up, static typing and restricted methods are trivial to extend and can save you *a lot* of headaches down the road.

    > > why not use elegant ideas in Java to make it better ?
    > Because (as C++ found to its cost), combining a number of
    > elegant features together becomes complex, confusing and
    > inelegant. A C++ FAQ that I found had thirteen FAQ entries
    > for const. THIRTEEN? How can that be for such a 'simple'
    > feature?

    If you look at the C++ const FAQ:
    http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.11
    You'll see that 10 of the 13 questions deal with pointers and references and with cheating the type system. 3 Java has neither pointers nor references (at least not explicit ones) and it doesn't allow you to cheat the type system so these points don't apply. FAQ questions sounds pretty simple to me. C++ is complex because it tries to mix the low level paradigm with the high level. Java is simple because it doesn't mix paradigms.

    Because Java is high level, it can afford to do things "the right way". Look at templates for instance. C++'s templates are enormously complex and powerful. Java's JSR implementation of templates (from what I've read it's a lot like Eiffel's implementation), aren't as powerful, but they're extremely simple and have far fewer complications. Many of C++'s template problems just aren't relevent to Java's implementation. A const implementation for Java should be just as simple and backwards compatible with existing libraries if you implement it "the Java way" and not "the C++ way".

    I definitely believe it's worth it, if it's done "the right way".

    >
    > C++ allows methods to be overloaded on the const attribute. Should Java?
    >
    Yes. Method overloading with the const attribute is necessary for logical (as opposed to physical) constness. The key problem with supporting only physical constants is that self-optimizing trees would be prevented from readjusting their nodes for quicker access and database connected objects could not keep caches.

    So logical constants are necessary for any non-trivial datastructures.

    > > I don't think that const stuff is complex if it is complex
    > > then you should use VB instead of Java.
    > I think that is a little naive:

    You're correct here. Const has major implications on the design of Java if done "the obvious C++ way". Having submitted two proposals to C++ standardization members (the proposals weren't accepted), I realize how seemingly simple features can have major implications.

    For instance, given:
    MyClass mc;
    const MyClass cmc;
    const Object co;
    Object o;
    Array a;
    const Array a;
    List lst = new ArrayList();
    the following code would be legal:
    cmc = mc ;
    co = o ;
    co = mc ;
    co = cmc ;
    while the following would not be:
    mc = cmc ;
    o = co ;
    o = cmc ;
    Once a class is constant, it can never lose it's constness and thus cannot be assigned to a collection of Objects. That also means that the following are illegal:
    lst.add(cmc);
    lst.add(co);
    This means that const objects could not be added to collections. They couldn't be serialized and be used in thousands of already existing libraries.

    There are two ways to handle this *specific* situation, at run-time or at compile-time.

    C++ handles this at runtime and this leads to the problems you've experienced with const-correctness. If you use the compile time approach then all methods in the Java library that use Object need to also need to be overloaded with an almost idential "const" method. Some classes, like the collection classes, would need to have a complimentary const version of itself since the current collection classes allow you to extract nonconstant Objects. This is an insane amount of work for the JSR committee, Java library implementors, third party implementors, and for developers with their own inhouse libraries.

    So it appears that, while a compile-time approach is important for catching errors early and for optimization, a pure compile-time approach is impractical for many uses.

    Java constants needs an "escape hatch" by allowing you to cast away constants and having the checking done at runtime. It'll take the approach used by serialization and cloning and state that this escape hatch would *only* exist for classes that extended the RuntimeConstant interface. This approach may seem pointless, but it's necessary since runtime constants carry a (small) overhead on non-const methods of the class (see the implementation below). If the non-const method is called of a constant object, a ConstCastRuntimeException would be thrown.

    That means that access to methods declared to be constant would be legal:
    mc = (MyClass)cmc ;
    mc.accessConstantMethod();
    lst.add((Object)cmc); // Cast away the constness
    mc = lst.get(i);
    mc.accessConstantMethod();
    while the following would generate a ConstCast RuntimeException:
    mc = (MyClass)cmc ;
    mc.accessNonConstantMethod(); // Generates an ConstCast RuntimeException
    lst.add((Object)cmc); // Cast away the constness
    mc = lst.get(i);
    mc.accessNonConstantMethod(); // Generates an ConstCast RuntimeException

    IMO, this hybrid compile-time/run-time approach to const would greatly simplify the way Java deals with constants and would allow you to write a const-correct framework that could still work with non-const-correct libraries.

    The implementation of runtime constants would be simple. During compilation, the following class:
    class MyClass : extends RuntimeConstant
    {
    public accessConstantMethod() const
    {
    //....
    }

    public accessNonConstantMethod()
    {
    //....
    }
    }
    would generate the same JVM instructions as this class:
    class MyClass : extends RuntimeConstant
    {
    public accessConstantMethod()
    {
    //....
    }

    public accessNonConstantMethod()
    {
    if (this.IsThisClassConst())
    throw java.lang.ConstClassRuntimeException;
    //....
    }
    }
    Object.IsThisClassConst() would be a new method in Object that would return true if this object is a constant and false otherwise.

    Note that all non-constant methods need to be prefaced with the line:
    if (this.IsThisClassConst())
    throw java.lang.ConstClassRuntimeException;
    to prevent the methods from being run if the object is constant. This adds an additional burden on all non-constant methods. Since *only* classes that extend the RuntimeConstant interface are effected by this overhead, this overhead is acceptable.

    This solve the backwards compatibility issue with existing libraries, but it doesn't yet address how reflection is handled. I'll leave that to other people.
  12. Java's Continuing Evolution - const[ Go to top ]

    Sorry for the formatting. I didn't realize that spaces within lines got removed.
  13. Java's Continuing Evolution[ Go to top ]

    "by simply defining immutable interfaces" - It would be nice if Java allowed an object to marked as immutable. Currently, there's nothing preventing an engineer from adding a set method to a previously immutable object. It's happened many times to me. No matter how many times you tell the team "x is immutable" someone forgets and breaks it.
  14. Java's Continuing Evolution[ Go to top ]

    So Jordon, how would having an immutable option change that? If the issue is a rougue engineering changing an interface he shouldnt, what stop them from changing the core object itself?

    The solution to this is source code control and a management system, not a runtime change.

    How about some innovation, not new ways of skinning the same cat.

    Dave Wolf
    Personified Technologies LLC
  15. Java's Continuing Evolution[ Go to top ]

    Why don't you just create a dummy setter in the super class
    and make it final

    Granted its definitely not elegant but it does the job.
  16. Java's Continuing Evolution[ Go to top ]

    I think he means it should not be able to extend the interface and add mutable stuff
  17. Java's Continuing Evolution[ Go to top ]

    The make the interface final.

    We can do this all today. What we need for tomorrow is stuff we cannot do today.

    Dave Wolf
    Personified Technologies LLC
  18. Java's Continuing Evolution[ Go to top ]

    Dave,

    Assume that you writting some component and you have some method getRectangle which returns rectangle. Good way to do it is to return clone of that rectangle. Another way to create immutable sublass. Bu why bother if I can declare getters in rectangle as const methods and I can return const reference to rectangle. Then it will be impossible to call on this const reference any non const method. Simple and elegant. This is good feature from C++. Another good feature will be double dispatching at language level.
  19. Java's Continuing Evolution[ Go to top ]

    C# has this. But guess what, internally, the runtime still clones. So whats the point? You still have the same clone() overhead.

    Its like boxing and unboxing. Yes it is 'easier' to not have to use the Object wrappers for the primitives, but in boxing/unboxing the runtime still has to do all these GetType() checks.

    So it saves me the cast, but it doesnt save the runtime. In the end, isnt that the most important part?

    Dave Wolf
    Personified Technologies LLC
  20. Java's Continuing Evolution[ Go to top ]

    Roflmao. This is compile time checking not execution time. I mean const references and const methods. And C# does not support const methods. Dave stop reading whitepapers on MSDN.
    Take a look ECMA C# spec document this is better than whitepapers on MSDN.

    Of course they do cloning when you are trying to assign const reference to non const reference. In C++ this was solved by using const_cast<T>. In C# they do it at runtime. But this is different stuff.

    Peace
  21. Java's Continuing Evolution[ Go to top ]

    I'll drop the whitepaper comment in the waste basket where it belongs.

    And I'll also conceded I was mis-understanding your comment on const methods vs const references. Point taken.

    Dave Wolf
    Personfied Technologies LLC
  22. Java's Continuing Evolution[ Go to top ]

    <quote>
    from Dave wolf
    ...So it saves me the cast, but it doesnt save the runtime.
    In the end, isnt that the most important part?
    ...
    </quote>
    The "cast" as you call it, is in the "writing process"; the development I think it is as important than the run time at least !!!
    If I work as an Analyst or Architect , I dont care about that stuff. But when I begin to develop the solution as a developper (programmer) I care about the facilities the langage brings to me.
    The langage is for Human, not the opposite,
  23. Java's Continuing Evolution[ Go to top ]

    If its just interfaces and classes you need to make immutable just declare them as final, a good example is java.lang.String which cannot be extended
  24. Java's Continuing Evolution[ Go to top ]

    The only change not already in progress that the author proposes is conditional compilation.
  25. Java's Continuing Evolution[ Go to top ]

    The need to provide much better (read: native) support for XML, especially as related to communicating with synchronous and asynchronous Web services cannot be over-emphasized. Java has to at least keep up with what Microsoft is going to enable with C#. Check out BPEL Scenarios, for an example of a powerful abstraction for the above.

    BPEL Scenario Abstraction

    Cheers,

    Jill.
  26. Past or future.[ Go to top ]

    Alot of the issues discussed on the page and the orielly page seem to be todo with either tidying up or putting C++ features in Java. These really are bits and bytes - not evolution.

    When we talk about evolution what we really mean is taking Java to the next level - in the same way that C++ evolved from C.

    What we should be looking at is developing more radical features to the language so solve problems of complexity that emerge from building the large scale architectures that Java has allowed to to build.

    In the same way that C struts 'mutated' from C++ classes then we should be 'mutating' architectural concepts to Java.

    A good concept that should be added to Java in the seperation between module and type - so called component oriented programming. This then enables a more meaningfull use of aspect oriented programming (dynamically ading cross cutting features like logging) - because larger scale objects have a more regular structure.

    For more discussion look at http://www.softwarereality.com/programming/component_oriented.jsp