java going in the wrong direction (1.5)

Discussion in 'Java' started by les ander, Feb 28, 2004.

  1. les ander

    les ander Guest

    I just read the "whats new" feature at

    http://java.sun.com/developer/technicalArticles/releases/j2se15/

    and I think that even though templates (generic) gives a lot more
    flexibility,
    I am not happy that so many new features are being added to java.
    I know c++ and I really hate it because it is very hard to understand
    (I don't care if it gives more flexibility)--maintainance is more
    important.

    just ranting
     
    les ander, Feb 28, 2004
    #1
    1. Advertisements

  2. I read that a while back (well, the first half).
    Felt the same way.
    But I eventually decided it is more a question of a poorly written article.

    Here's my rant ^_^

    http://forum.java.sun.com/thread.jsp?forum=4&thread=488882
     
    Thomas Schodt, Feb 28, 2004
    #2
    1. Advertisements

  3. I disagree, I welcome those features (with open arms). I think they target
    ease of development and maintenance. They make code less bloated, ergo more
    readable. The features themselves are very straightforward imho, and a
    natural extension of the java language. They will prove invaluable (imo).
    And I don't think that there are a lot of new features. I only counted 6
    major changes.

    To motivate:
    (1) boxing : finally produce readable code instead of boxing / unboxing code
    (2) template/generics : finally produce readable code instead of
    casting-code all the time when you work with collections
    (3) improved for-loop : makes iterations over data more concise, and easier
    to read; hides the iterator-code
    (4) enums : finally! no more public static final int WHATEVER times 10 for
    specifying a set of values

    I have my doubts about the static import facility, and the unboxing of null
    (what to do with that?).

    Anyway, I'm a big fan of templates & generics, and I think Java will become
    more widely accepted because of this feature. For instance, C++ developers
    will have less difficulty making the transition to Java.

    The only thing that I keep missing is a typedef utility.
     
    TT \(Tom Tempelaere\), Feb 28, 2004
    #3
  4. les ander

    Dale King Guest

    The benefit is like you describe is less repetitive typing. They give
    examples of members of the Math class, but that only saves 5 characters. Try
    these lines on for size with static methods with longer names. See if you
    can fit them in 80 character lines:

    AffineTransform rotate45 = AffineTransform.getRotateInstance(
    Math.toRadians( 45 ), x, y ) );

    GraphicsEnvironment environment =
    GraphicsEnvironment.getLocalGraphicsEnvironment();

    And also with the enums you seem to like so well, how do multiple classes
    use those enums without having to qualify them with the class name where the
    enum is defined and with the type name of the enum. Without static import
    you have to do something like:

    ClassDefiningTheEnum.TheEnumType.theEnumValue

    any time you want the enum value. With static import you can import the enum
    type with:

    static import ClassDefiningTheEnum.TheEnumType.*

    and then you can just say

    theEnumValue
    I assume that should throw an exception.
     
    Dale King, Feb 28, 2004
    #4
  5. I was thinking of name clashes. But indeed there is less typing which is ok
    for me.
    An enum is a special form of a class. Why implement it inside another class?
    Again, I fear for possible name clashes. But it is less typing indeed.
    Cheers,
    Tom Tempelaere
     
    TT \(Tom Tempelaere\), Feb 28, 2004
    #5
  6. les ander

    Doug Pardee Guest

    Static import is a "lesser of two evils" situation. It is intended to
    replace the even more evil practice of "implementing" an interface in
    order to allow a class to access constants defined within the
    interface without naming the interface.

    An example is javax.swing.SwingConstants. Rather than type
    "SwingConstants.LEFT" to access a constant, classes commonly claim to
    "implement SwingConstants" and then use simply "LEFT" to access the
    constant.

    Now they can do an "import static javax.swing.SwingConstants.*;' and
    remove the misleading "implements SwingConstants".

    It also provides simpler access to utility methods, especially those
    in java.lang.Math.
    Already decided. After considerable discussions, the final decision
    was to throw a NullPointerException. From the proposed spec change for
    JLS 5.1.8:
    "If r is null, unboxing conversion throws a NullPointerException."

    Specs for JSR-201's "Enumerations, Autoboxing, Enhanced for loops and
    Static Import" are available for download at
    http://jcp.org/aboutJava/communityprocess/review/jsr201/index.html
     
    Doug Pardee, Feb 28, 2004
    #6
  7. les ander

    Dale King Guest

    And more readable, because having one line line for the statement is more
    readable than multiple lines.
    class?

    Becuase it usually is associated with the interface for some class. For
    example as the parameter and/or return value for one or more methods for
    that class, it makes sense to define it in that class.

    Oops, got the order wrong it should be:

    import static ClassDefiningTheEnum.TheEnumType.*
    Sure there can be name clashes and in those cases the compiler will not let
    you use the name unqualified.
     
    Dale King, Feb 28, 2004
    #7
  8. Yuck indeed. I wouldn't even dare trying something like that. And then the
    import static comes in handy indeed.

    [....]
    Can I download the java specs for 1.5?
    Thanks,
    Tom Tempelaere
     
    TT \(Tom Tempelaere\), Feb 28, 2004
    #8
  9. I believe that generics and enums are going to make more maintainable
    code, not less.

    I have seen some truly evil templates in C++, but the Java generics do
    not seem prone to the more egregious problems I saw there. There are
    some flaws, like being able to downcast then upcast, but as Bjarne put
    it about c++, we mean to stop accidents, not sabotage.

    Enums, similarly, are something that are needlessly complex in current
    java code. The new syntax is at least no more complex, and it will mean
    only one preferred way to handle the problem going forward.

    I do not have an opinion on the other new features as yet.

    Scott

    Java, Cocoa, and database persistence consulting for the life sciences
     
    Scott Ellsworth, Feb 29, 2004
    #9
  10. les ander

    Jim Guest

    Because this form of Enum is like String; Java knows about them, so
    you can use an Enum constant in switch statements!
    Jim
     
    Jim, Feb 29, 2004
    #10
  11. Certainly welcome. But IIRC, the casts are still there in the bytecode.
    Surely this could have been implemented without casts?
    Not very useful in my opinion. I'd rather see the java APIs taking more
    advantage of the iterator concept. So, just put a forEach(Iterator,
    Function) method in Collections instead. Oh, and give me first class
    functions instead of lame syntactic sugar :)
    The static import OTOH is nice syntactic sugar. One feature that you
    didn't mention is variable arguments. Moderately useful I guess, but the
    rationale for this, implementing printf, is rather weak.
     
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Feb 29, 2004
    #11
  12. Usually, indeed. But up till now, you didn't have a choice. There were no
    enums, and people coded them into classes (as static final). Now, java
    designers decided to go one step further than the current view of what an
    enum is. They made it a class. If the class definition is complex enough, or
    if the class is used in different contexts (eg shared between client <->
    server) then I would definitely make it a seperate class. But that all
    depends on the situation.

    [...]
     
    TT \(Tom Tempelaere\), Feb 29, 2004
    #12
  13. As I read through the specs, I noticed that their intention was not to
    change the JVM too much, instead force the compiler to produce existing
    bytecode for new constructs/features. But to be honest, I do not know the
    relation between Java code and the Java VM (which executes bytecode).
    IMO they are useful, because the intention is much clearer. Coding a for
    loop using explicit iterators is tedious.

    Again, IMO, I would have preferred other iterators. Iterators like they are
    used in STL (C++). There is no special for-loop but the way to go about that
    is (pseudo-code):

    tyepedef std::vector< std::string > stringVector;
    stringVector sv; /*...*/
    for( stringVector::iterator iter = sv.begin(); iter != sv.end();
    ++iter )
    {
    // iter points to current element in vector
    // *iter is a reference to the current object
    }

    But I guess that is a matter of style. The algorithm-header defines a
    template function 'foreach' which allows executing a function for each
    element in the collection.

    [...]
    Indeed moderately useful, and a chance to introduce bugs that can't be
    checked at compile time. This seems like a feature that is targeted towards
    new Java developers that have C++ knowledge.
     
    TT \(Tom Tempelaere\), Feb 29, 2004
    #13
  14. Agreed. C++ allows more complex template code (eg partial specialization,
    template template parameters, non-class type template parameters (int, char,
    pointer, ...), along with rather complex lookup rules. C++ does not allow
    the "T extends ..." construct as in Java. This is a question of style.
    I don't see how that relates to templates. What stops you from downcasting
    and then upcasting?
    Complete agree here. Imho, it is better than in C/C++.
     
    TT \(Tom Tempelaere\), Feb 29, 2004
    #14
  15. les ander

    Chris Uppal Guest

    Or at all. That's very important. The stability of the JVM (spec) is central
    to building and maintaining momentum for Java. If they lost track of the
    importance of total backward comapatibility then (in my opinion) Java would die
    rather fast.
    Please don't take this personally, but that's a good example of the problems
    that I see with all this new stuff being added to Java. It breaks the link
    between what Java is doing (or pretends to be doing) and what the JVM is doing.
    As a result it gets harder and harder for ordinary programmers to understand
    (as I believe they should) what's really going on, increases the complexity of
    the system for those who *do* know what's really going on, and leads to a
    proliferation of awkward corner-cases where the whole system (the Java compiler
    + the JVM) does not behave as a naive understanding would lead one to expect.

    -- chris
     
    Chris Uppal, Feb 29, 2004
    #15
  16. les ander

    Chris Uppal Guest

    I'm inclined to agree.

    Sun are bowing to community pressure (I assume) in this, but I don't think the
    community's well-advised.

    They are adding significant complexity to the language, and (worse in my view)
    adding enormously to the complexity of the mapping from Java-the-language to
    the underlying reality, which is the semantics of the JVM.

    Other people have disagreed with your point, but I think they are focussing on
    the trees, not the wood. Its true that the new stuff will allow simpler
    expression of some idioms, and as far as it goes, I agree that that's a good
    thing. Unfortunately it's bought at the expense of an increase in the
    complexity of the system as a whole, and I don't think the extensions justify
    that.

    You can't add simplicity *afterwards*, yet that's just what Sun are trying to
    do.

    (My only reservation in this, is that Java was already so complicated, though
    not in the same ballpark as C++, that maybe most of the damage had been done
    already, and so the extensions may not make things much worse. We shall
    see...)

    -- chris
     
    Chris Uppal, Feb 29, 2004
    #16
  17. I would really love to have the new BigDecimal class. I was wondering: is
    this going to be in the new version? It still seems to be in draft phase.
    When I work with BigDecimal now, I can't help feeling like I'm walking on
    eggs.
     
    TT \(Tom Tempelaere\), Feb 29, 2004
    #17
  18. les ander

    Dale King Guest

    Right but that doesn't mean that just because it is a class it should be a
    top-level class.

    Keep in mind that every top-level public class must be declared in a
    separate source file. Making every enum a top-level class would create a
    whole bunch of little files that hold nothing but the enum. That creates a
    lot of "conceptual weight" for something that may be nothing more than named
    constants. You can certainly do some things with enums that warrant making
    those top-level classes, but usually that won't be the case. Luckily with
    static import that is no longer a problem.
    And typically it would be part of the server class.
     
    Dale King, Feb 29, 2004
    #18
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.