Discussions

News: J1 Day 3: Tiger Poem, Generics, MDA, JSF, CMP beyond the spec

  1. Joshua Bloch and Neal Gafter presented a packed session on new language features and a satircal poem about the Tiger Release. Study shows MDA to be 35% more productive than code centric approach. The "Beyond CMP" talk looked at pluggable PM's and transactional issues. Also covered were sessions on adding Generics to Java, JAX-RPC and WS Security, and a BoF about JSF and Struts.

    A detailed synopsis on the new J2SE 1.5 'Tiger Release' language features has been provided.

    Read Day 3 JavaOne 2003 Coverage

    Threaded Messages (90)

  2. Comment on editors note[ Go to top ]

    4. Autoboxing

    >
    > * Editors Note: You may be wondering why the distinction between int and
    > Integer was preserved in the language at all. Performance isn't the reason,
    > as the code can be optimized at the byte-code level. Neal kindly explained
    > for us that since "==" has different semantic behavior between int and
    > Integer in the present language, changing this could theoretically break
    > backwards compatibility with existing code.

    Simple reason - space.

    In the project I'm working on we have to store loads of longs (64bit integers). Now the long itself takes exactly that (8 bytes each) space, but a Long as an object takes 12 + 8 = 20 bytes. Now consider that you'd have to store 2000000 of those objects: ArrayList of those would take ~ 38,2MB whereas plain array would take only ~15,3MB.

    And the situation gets worse for smaller primitives. Short object 12 + 2 = 14 bytes, short primitive 2 bytes... 7 x times the space...

    Luckily, it's fairly straightforward to implement custom LongArrayList specialized in long primitives + you get the 1,5..3 x performance increase in addition to space savings.

    But, still - having only object containers in standard distribution bugs me. Sebastiano Vigna's fastutil package has solutions for primitives in the Map container space (loads of generated code from common framework) but this kind of functionality is much better supported with generics. I'm *so* disappointed that the generics in 1.5 don't cover primitives.
  3. Comment on editors note[ Go to top ]

    Simple reason - space.


    No no no. You misunderstand. Eliminating int from the language wouldn't eliminate int at the VM level. Rather, the VM would box and unbox as needed to make it work correctly. Most arrays would be of int's not Integers, based on compiler optimization.
  4. Memory issue[ Go to top ]

    Simple reason - space.

    >
    > No no no. You misunderstand. Eliminating int from the language wouldn't
    > eliminate int at the VM level. Rather, the VM would box and unbox as needed
    > to make it work correctly. Most arrays would be of int's not Integers, based
    > on compiler optimization.

    Last time I heard the generics don't cover primitives. So there's not going to be generic containers for primitives. However, if they manage to optimize containers (to contain primitives) based on their contents I'd be very happy.

    I don't care if it's Integer or int, I don't care if it's someInt + otherInt or someInt.add(otherInt) but the memory issue is big. Storing every boolean, short, int, etc as an object is bloated. They are not objects - they're just numbers.
  5. Struts GUI Today =[ Go to top ]

    If you like GUI tools, this is one of a dozen Struts tools today.

     http://www.scioworks.com/scioworks_camino.html

    JSF GUI plan, AFAIK,is in 2004, that is based on NetBeans on RowSet, with support for EJB and Soap later.
    .V
  6. Oracle is looking at providing a form of event notification to the application server to notify it of data changes from the database.

    Wow! If they can get this done, I predict OC4J will vault over WLS as the leading app server, and entity beans will come back in vogue.
  7. Cache[ Go to top ]

    Eric,
    Open source does this feature NOW (in a better design) for any J2EE:

    http://jakarta.apache.org/turbine/jcs/

    hth, .V
  8. Cache[ Go to top ]

    I don't know the details on how Turbine JCS works, but I assume the middle/caching layer needs exclusive read/write to the database - i.e., if another application writes to the same database without going through the caching layer, all bets are off. In the real-world, a database is seldom accessed strictly through a single middle-tier, and if the database can notify all middle-tier listeners, the benefit has to be tremendous IMHO. I don't know whether the JCache JSR tries to solve the problem, but I would say if Oracle can provide a clean proprietary solution, a lot of people will be very happy.
  9. Cache[ Go to top ]

    We’ve been supporting this type of cache (with db-driven invalidation) for 3 years by now in one of our products that is currently sold in Asia markets. We also have US patent on that technology. So, there is nothing particularly new in this type of cache.

    Best regards,
    Nikita Ivanov.
    Fitech Labs., Inc.
  10. Cache[ Go to top ]

    Just curious:

    1. Is your technology database agnostic, or does it require the database to support triggers, message queues, or interprocess pipes?

    2. Is the invalidation mechanism real-time and does it require the caching layer to poll the database at a set interval (not good).

    3. How come you are not marketing the technology/product in the US market?
  11. Cache[ Go to top ]

    Hi Eric,
    1. Db has to have Java support. Currently, we provide support for Oracle 8i/9i and Sybase 11+. Since xTrade is financial-oriented middleware, this is a good enough coverage.
    2. No polling needed. But triggers are required. Db-driven invalidation is only part of the caching technology in xTrade. There are many other aspects to it.
    3. This product was developed for Asia market (it’s sold primarily in Japan). We have a new product – xNova - that we have just released last month that is horizontal middleware and we are starting to market this product world-wide, including US.

    Hope it answers some of your questions.

    Best regards,
    Nikita Ivanov.
    Fitech Labs., Inc.
  12. Cache[ Go to top ]

    So let me take some wild guesses, assuming Oracle8i and WebLogic 6.1 are used:

    1. Upon data change in Oracle, a trigger is fired that invokes a Java stored procedure.
    2. This stored procedure makes an HTTP callout to a WLS servlet, or directly publish a JMS message to a WLS topic.
    3. A MDB proceeds to invalidate the cache.

    Now my questions:

    1. How do you load weblogic.jar into Oracle8i if you want to use WLS JMS?
    2. In a heavy load OLTP system (like a trading system), how does step 2 hold up? I have found the performance of Oracle Java stored procedure making network calls to be inadequate.

    An alternative I like better is:
    1. A trigger uses PL/SQL to enqueue a message into an Oracle AQ queue.
    2. A WLS MDB listens to this AQ queue directly and invalidate the cache.

    BTW, thank you for sharing your product info.
  13. Cache[ Go to top ]

    Hi Eric,
    It is certainly something along the lines you’ve described. Without going into too much of details, we use proprietary highly optimized TCP-based protocol to do the invalidation from the trigger. We used this technology on the leading Japanese online equity trading system with the great success, so it’s holding up pretty well in production systems.

    Thanks for your questions,
    Nikita Ivanov.
    Fitech Labs., Inc.
  14. Cache[ Go to top ]

    Only problem with Oracle AQ, unless they've changed, is that the client runtime is actually polling with a delay using std jdbc calls to the AQ tables. The latency between a publish and a subscribe is visibally noticeable.
  15. Oracle AQ[ Go to top ]

    Which version of AQ are you talking about? How large is the latency? The version I tried (9.2.0.3) seems to be fast between enqueue and dequeue.
  16. Oracle AQ[ Go to top ]

    I've tried it with both 8i and 9i release 2. As I said, it may have changed, but if you *find* a way to get at the source, you'll see what I mean. AQ is great for many environments, but I have found that it is nowhere "near" real time in its latency.
  17. Oracle AQ[ Go to top ]

    OK, I will have a closer look at the code. I agree the current available mechanism consists of too many "hops", and a direct way to invalidate middle tier data cache (trigger calling middle-tier using sockets?) is more desirable.
  18. Oracle is looking at providing a form of event notification to the application server to notify it of data changes from the database.

    >
    > Wow! If they can get this done, I predict OC4J will vault over WLS as the leading app server, and entity beans will come back in vogue.

    Great, then I'll just go along and predict that you are wrong...on all accounts...

    A standardized mechanism for doing this, that would, however, be a big thing...

    Br - J
  19. You can already do this in terms of deploying Java in the database.

    At the end of the day Oracle should lick its wounds and get out of the App Server business. I don't care if they give their application server away with all the free consultancy you can handle it is not going to gain any real market share. If I needed something good that was not expensive I would use JBoss.

    David
  20. > You can already do this in terms of deploying Java in the database.

    Problem is, last time ORCL tried that, the EJE (Enterprise Java Engine) was a dog - the performance and scalibility were so bad, the product was practically unusable.


    > At the end of the day Oracle should lick its wounds and get out of the App Server business.

    It is logical (to IT management) that each major RDBMS vendor also has a significant app server offering. IBM and MSFT are there already. ORCL wasted 2 years (1999 to 2001) trying to embed the EJB container in the database, and this helped BEAS to become the dominant player it is today. OC4J is No. 3 or 4 in every analyst's app server ranking. You can bet Larry Ellison will not back down from the challenge. Adding proprietary extensions to their OC4J app server is a natural course for them to take. The feature they proposed sounds great to me.
  21. > You can already do this in terms of deploying Java in the database.

    >
    > Problem is, last time ORCL tried that, the EJE (Enterprise Java Engine) was a dog - the performance and scalibility were so bad, the product was practically unusable.
    >

    Well, embedding the entire J2EE stack was not a good idea, reason why we've discontinued EJE, in favor of iAS/OC4J; however running pure J2SE data logic in the database as well as extending database capabilities with standard Java libraries, is an established and growing trend and we are improving the embedded Java JVM in this respect including keeping up with latest J2SE standards, improving performance and usability.

    Middle-tier cache invalidation (through JSP/Servlet call-out) is one of the various data-driven things you can do with OracleJVM, including calling-out J2EE components as well as consuming data from external Web services.

    See code samples @ http://otn.oracle.com/sample_code/tech/java/jsp/content.html

    Kuassi Mensah -- Oracle
  22. Middle-tier cache invalidation (through JSP/Servlet call-out) is one of the various data-driven things you can do with OracleJVM, including calling-out J2EE components as well as consuming data from external Web services.
     
     See code samples @ http://otn.oracle.com/sample_code/tech/java/jsp/content.html


    This works, but the efficiency is not that great. You have to do trigger(PL/SQL) -> Java Stored Procedure (Java) -> Servlet -> JMS -> MDB. I hope Oracle can come up with a better solution.

    BTW, can you provide a bit more details on the JavaOne talk by Sastry Malladi?
  23. Middle-tier cache invalidation (through JSP/Servlet call-out) is one of the various data-driven things you can do with OracleJVM, including calling-out J2EE components as well as consuming data from external Web services.

    >  
    >  See code samples @ http://otn.oracle.com/sample_code/tech/java/jsp/content.html
    >

    >
    > This works, but the efficiency is not that great. You have to do trigger(PL/SQL) -> Java Stored Procedure (Java) -> Servlet -> JMS -> MDB. I hope Oracle can come up with a better solution.

    Not exactly, as you can see in the code sample, JSP/Servlet -> Java Cache
    this solution, makes sense (is efficient) for maintaining semi-static web pages -- I called it "Database-Assisted Web Publishing"; i was inspired by an article on TSS about maintaining semi-static web pages, however in my solution, the trigger garantees tracking of changes to the underlying table no matter the origin.


    >
    > BTW, can you provide a bit more details on the JavaOne talk by Sastry Malladi?

    the powerpoint slides will be available at the JavaOne site, however you can get more information from OTN @ http://otn.oracle.com/tech/java/architect/content.html

    Kuassi
  24. Middle-tier cache invalidation (through JSP/Servlet call-out) is one of the various data-driven things you can do with OracleJVM, including calling-out J2EE components as well as consuming data from external Web services.

    > >  
    > >  See code samples @ http://otn.oracle.com/sample_code/tech/java/jsp/content.html
    > >

    > >
    > > This works, but the efficiency is not that great. You have to do trigger(PL/SQL) -> Java Stored Procedure (Java) -> Servlet -> JMS -> MDB. I hope Oracle can come up with a better solution.
    >

    PL/SQL in this case is just a wrapper to bridge SQL with the Java world
     
    if MDB is your target, you can call it out directly from a Java/JMS client within the database, using RMI/IIOP (requires a db with J2SE 1.3 compatible OracleJVM - 9iR2 or upcoming releases)

    Kuassi
  25. I can't wait to see Sun adding the new enhanced for loop ("foreach"). However, it drives me nuts that Sun claims using foreach as a keyword breaks backward compabiltility. Come on guys. Who in the right state of mind is using foreach as a variable?

    Please, let your marketing folks work it out with some surveys. If you find any lunatic on this planet. May I suggest that you tell him to change the offending line and try a recompile.

    If Sun wants Java to succeed I tell you Sun needs to show more courage instead of playing chicken.

    I also don't get why Sun leaves out get and setters and event handlers (delegates). Is it because the server side guys run the show?

    - Gerald
  26. I can't wait to see Sun adding the new enhanced for loop ("foreach"). However,

    > it drives me nuts that Sun claims using foreach as a keyword breaks backward
    > compabiltility. Come on guys. Who in the right state of mind is using foreach as
    > a variable?

    Maybe noone, but the basic problem is valid: how many uses "enum" as variable? I know I do that A LOT (e.g. "Enumeration enum = ..."). That's what worries me more than "foreach".

    /Rickard
  27. Foreach as a keyword[ Go to top ]

    Come on guys. Who in the right state of mind is using foreach as a variable?


    I didn't use it as a variable, but I used it as a method name when I implemented a form of the STL for Java. IIRC, so did all the other libraries out there that did essentially the same thing (for example, JGL).

    God bless,
    -Toby Reyelts
  28. Foreach as a method name[ Go to top ]

    Come on guys. Who in the right state of mind is using foreach as a variable?


    > I didn't use it as a variable, but I used it as a method name when I implemented
    > a form of the STL for Java. IIRC, so did all the other libraries out there that
    > did essentially the same thing (for example, JGL).

      Shame on you. Just because of some weirdos Sun makes me and twenty million fellows to use for instead of foreach for the rest of my life. Get real. If I have to I will fork off a new language.

      Who is using your libraries anyway. Please, don't kill off Java 1.5 with your short-sighted pseudo backward compatibility.

       I'm sure you can easily fix up your code using a bytecode patcher. Feed it a jar and it changes your foreach symbols to something different without requiring any sources. Big deal.

      - Gerald
  29.    I'm sure you can easily fix up your code using a bytecode patcher. Feed it a jar and it changes your foreach symbols to something different without requiring any sources. Big deal.

    >
    >   - Gerald

    I find it quite funny that a person like yourself can come up with such a lowlevel flame as the comment on the usage of foreach and enum and so on. Have you written any code youself or do you really just want to pick a stupid fight.

    If you weren't so damn ignorant you should know that the difference between a foreach keyword and a foreach variable in terms of the bytecodes that gets generated is quite different.
  30. Foreach as a method name[ Go to top ]

    Please, don't kill off Java 1.5 with your short-sighted pseudo backward compatibility. I'm sure you can easily fix up your code using a bytecode patcher.

    As I understand it, legacy bytecode is compatible with the 'foreach' keyword, but the source code isn't. Ie, the old source no longer would compile, but the old classfiles would still run. So the vendor could use JDK 1.4 to build and the customer could use JRE 1.5 to run. Sun, jus' friggin' add foreach! Have it take a Collection, Iterator, Enumerator, or Object[] as its argument.
  31. Foreach as a keyword[ Go to top ]

    Given that the grammar could still differentiate between the foreach() loop and foreach() method call fairly easily (at a cost of one lookahead), I really don't understand this..
    If you wanted to optimize a bit, and the new grammar would prefer foreach() loop construct expansion (and roll back if necessary), it should not even have that a big impact on the compile speed.

    I think you'd need more lookaheads for enum but can't say as I haven't seen the grammar for them yet (can you define inner enums?)

    What I'm more worried about, is that Sun is introducing some changes that noone has been really asking for a lot (for example variable arguments).
    Just because some other language has it, doesn't mean everyone needs it (Ada/Eiffel anyone?)
    Regards,
    Vlad
  32. What I'm more worried about, is that Sun is introducing some changes that noone

    > has been really asking for a lot (for example variable arguments).
    > Just because some other language has it, doesn't mean everyone needs it
    > (Ada/Eiffel anyone?)

      I guess the core problem here is Sun's monopoly replay by tricking developers into believing only Java the language is pure and noble and all other languages using the Java runtime and its libraries are bastards and worse.

      Let's bury the Java language myth and let's welcome new languages build on the Java runtime. Who cares about syntactic sugar? Let's focus on interop.

      Trying to serve different markets (Ex-C++ Hackers, Ex-VB-Script Kiddies, etc.) with a single bloated language called Java is not going to work. I guess it's time to turn the table and "steal" an idea from the Redhell playbook.

      I will kick off the coming Golden Age for language designers with my very own entry code-named Shark @ http://shark.sourceforge.net

      - Gerald
  33. languages for the JVM[ Go to top ]

    Enjoy:

    http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  34. \Bauer\
    I guess the core problem here is Sun's monopoly replay by tricking developers into believing only Java the language is pure and noble and all other languages using the Java runtime and its libraries are bastards and worse.
    \Bauer\

    I wasn't aware the JVM was monopolized - gee, I've used IBM JVM and HP's in the last week. It must have been another of those hallucinations. And I could've sworn I heard of JPython and a few other languages that aren't Java but run on the JVM. Certainly someone's getting tricked around here.

    \Bauer\
    Let's bury the Java language myth and let's welcome new languages build on the Java runtime. Who cares about syntactic sugar? Let's focus on interop.
    \Bauer\

    Um - go ahead.

    \Bauer\
     Trying to serve different markets (Ex-C++ Hackers, Ex-VB-Script Kiddies, etc.) with a single bloated language called Java is not going to work. I guess it's time to turn the table and "steal" an idea from the Redhell playbook.
    \Bauer\

    I wouldn't call Tiger bloated against C++. Or C. Or Perl. Or C#. Or...

    Certainly I'm not cheering for everything coming down the pike - Generics are of very limited usefulness given Java's runtime checking (necessary in C++, not so much in Java). And the varargs facility looks like a royal pain due to method overloading conflicts. But beyond that, the language is still ridiculously easy to understand and use compared to any other popular language.

    \Bauer\
     I will kick off the coming Golden Age for language designers with my very own entry code-named Shark @ http://shark.sourceforge.net
    \Bauer\

    If I had a buck for every Golden Age I've personally experienced...I'd probably have enough money to try and create my own :-)

        -Mike
  35. "Certainly I'm not cheering for everything coming down the pike - Generics are of very limited usefulness given Java's runtime checking (necessary in C++, not so much in Java). "

    Generics would give compile time checking - which in most cases is highly preferable to runtime checking. Generics would greatly improve Java...
    No more ridiculous clone() methods that return Object, etc.... It's time for Java to become a big boy or go the way of VB.
  36. \Snopes\
    Generics would give compile time checking - which in most cases is highly preferable to runtime checking. Generics would greatly improve Java...
    No more ridiculous clone() methods that return Object, etc.... It's time for Java to become a big boy or go the way of VB.
    \Snopes\

    Sounds good in theory, not so much in practice.

    C++ desperately needed generics, because the language lacks a single root for class inheritance (Object), and at the time the lack of run-time-type-information and safe casts meant that you had to _unsafely_ cast from a (void *) and back. If you got it wrong, you got a core dump or managled memory some where.

    In Java, we already have a very well defined and safe checking mechanism. Yes, it's at runtime - but ClassCastException isn't fatal, and instanceof has been available from day one.

    The difference to me is striking - in C++, generics were _vital_ (and too bad such a vital need was fulfilled by such an ungodly syntax :-/). In Java, they're mostly a nicety. In fact, in day to day use, the only gain you're going to get is not having to always cast. And backwards compatability means that you still may need to cast for a long time to work with non-generic code, and therefore also still have the possibility of a ClassCastException. And the downside of the nicety is that code which implements generics is going to be harder to read.

    In short, returning or taking Object everywhere seems hokey, until you use it so often and find it almost never causes a real problem - and those are easily spotted by looking at what the ClassCastException tells you.

         -Mike
  37. C++ and Java templates[ Go to top ]

    Mike writes:
    C++ desperately needed generics, because the language lacks a single root for class inheritance (Object),


    Actually, C++ has this root: void *. I don't see much difference between void* and Object, except for the few methods that the Object class offers, and which are irrelevant here.

    The difference to me is striking - in C++, generics were _vital_

    I don't understand why they are more vital than in Java. Granted, a type error in Java ends up with a non-fatal error, but it is quite likely that your application is hosed at this point anyway.

    (and too bad such a vital need was fulfilled by such an ungodly syntax :-/).

    Well, the Java Generic syntax is awfully similar to that of C++. The reason why it is inelegant in C++ is because of the *rest* of the grammar, which conflicts with the angle brack syntax pretty bad ("> >" comes to mind).

    In Java, they're mostly a nicety. In fact, in day to day use, the only gain you're going to get is not having to always cast.

    I disagree. One of the major gains with Generics is that API's will be much easier to read. No more "/** @returns a Collection of Name", it's all statically typed now.

    --
    Cedric
    http://beust.com/weblog
  38. C++ and Java templates[ Go to top ]

    \Beust\
    Actually, C++ has this root: void *. I don't see much difference between void* and Object, except for the few methods that the Object class offers, and which are irrelevant here.

    [...]
    I don't understand why they are more vital than in Java. Granted, a type error in Java ends up with a non-fatal error, but it is quite likely that your application is hosed at this point anyway.
    \Beust\

    There is a world of difference. A (void *) literally means "pointer to don't know what". It doesn't even have to point to an object:

        int x = 5;
        void *nuthin = (void *)&x;

    Couple that with the early lack of RTTI and safe-casts (in fact, I'm not sure if they apply to non-object pointers at all) and you have a problem:

        int x = 5;
        void *nuthin = (void *)&x;
        MyClass *uhOh = (MyClass *)nuthin;
        uhOh->member = "hi there";

    As for why it's my vital - uhOh->member won't necessarily hose your program (but I'm sure you knew that). If 'x' is global, you'll just possibly scribble over some other global variable (depending on where 'member' is in class MyClass, and the happenstance location of 'x'). If 'x' is on the heap, you may corrupt the heap but not know it until thousands of calls later. If 'x' is on the stack, you may have created yet another stack overflow exploit :-)

    In real programs running in dev/test/production: a single thread for a given "invocation" can give you a ClassCastException. This may be fatal for the whole program - or it may just mean one type of request on one thread doesn't work. In C++ - your program may core (sooner or later). Or your data might just get scrambled.

    And finally - in Java, the ClassCastException tells you _exactly_ what the object really was, meaning you can easily fix it. In C++ - does the core dump tell you what the object was? Does it tell you it wasn't even an object? Does your program even crash at the mis-use point, or does it crash 10 minutes later somewhere unrelated?

    The overall problem of course is simple - to make a "generic" library pre-templates, you had to use (void *), with all of the downsides listed above. Generics practically eliminated such problems. But in Java, you always know it's an object, and you can always find out the true identity of the object. That's the difference between vital and just nice.

        -Mike
  39. C++ and Java templates[ Go to top ]

    Ditto Mike's comments. Sorry, Ced.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  40. C++ and Java templates[ Go to top ]

    \Beust\

    > Actually, C++ has this root: void *. I don't see much difference between void* and Object, except for the few methods that the Object class offers, and which are irrelevant here.
    >
    > [...]
    > I don't understand why they are more vital than in Java. Granted, a type error in Java ends up with a non-fatal error, but it is quite likely that your application is hosed at this point anyway.
    > \Beust\
    >
    > There is a world of difference. A (void *) literally means "pointer to don't know what". It doesn't even have to point to an object:
    >
    >     int x = 5;
    >     void *nuthin = (void *)&x;
    >
    > Couple that with the early lack of RTTI and safe-casts (in fact, I'm not sure if they apply to non-object pointers at all) and you have a problem:

    RTTI has been in C++ for at least a decade. So sleazy of you to make C++ look
    bad just to prove your point. If you include RTTI in C++, your argument falls
    flat.

    Kalyan
  41. C++ and Java templates[ Go to top ]

    \Kolachala\
    RTTI has been in C++ for at least a decade. So sleazy of you to make C++ look
    bad just to prove your point. If you include RTTI in C++, your argument falls
    flat.
    \Kolachala\

    Generics, ala templates in C++, were first proposed in The Annotated C++ Reference Manual (aka ARM) by Ellis and Stroustroup. Most of the basics of templates were codified in that edition, although there have been some signficant changes since. This was the "ANSI Base document" for C++, and my first edition copy was (c) 1990.

    The relevant part for this discussion is the following bit from "The Design and Evolution of C++": "Run-Time Type Information, often called RTTI, was the first major extension beyond the features mandated for the standardization process and presented in the ARM". That is - templates were added to the language before RTTI was seriously considered.

    Design & Evolution was (c) 1994, and it was many years after that before compilers actually reliably implemented RTTI. So it's been considerably less than a decade that RTTI has been actually available for regular use. But the point is that templates were designed well before RTTI was ever available.

    Finally, I believe RTTI still doesn't work universally across all types, for performance and space reasons (my RTTI in C++ _is_ a bit fuzzy - if anyone has more complete details, please let me know). And at least as of a few years ago, when I last seriously considered the topic, the compilers I was using required you to use a special option to just plain enable RTTI (it was turned off by default).

    Incidentally, this is not a sleazy attempt by me to make C++ look bad. The ARM & DnE clearly spell out the order that features were added to the language, and why they were added, and are the definitive works on the early history of C++. And those works match what I've stated here fairly accurately. So if you want to vent your angst, please vent it at Stroustroup and not me!

         -Mike
  42. Mike wrote:

    [i]I believe RTTI still doesn't work universally across all types[/i]

    RTTI works on any type that has a virtual destructor. If we were to draw analogies to Java, that would be every non-primitive type, since every type in Java is virtual. RTTI is a mandatory feature of the C++ language, and any compiler which doesn't support it isn't standards conforming.

    I personally own a copy of the ARM, D&E, and TC++PL, and have been programming for a good decade in C++, so I'm pretty well versed on the reason d'aitre for templates in C++.

    In any case, your argument against generics in Java is fallacious. Your excuse is that we have run-time type safety, so why do we need compile-time type safety? In that case, I propose we immediately drop all static typing from Java. I hope you would know better than that.

    God bless,
    -Toby Reyelts
  43. \Toby Reyelts\
    RTTI works on any type that has a virtual destructor. If we were to draw analogies to Java, that would be every non-primitive type, since every type in Java is virtual. RTTI is a mandatory feature of the C++ language, and any compiler which doesn't support it isn't standards conforming.
    \Toby Reyelts\

    Thanks for the clarification - as I said, my fringe C++ knowledge has deteriorated a bit. However, your analogy doesn't completely hold - there are many cases of C++ classes which are non-polymorphic (such as plain old structs). This is more of a nitpick than anything else.

    As for standards conforming - last time I checked Visual Studio/Visual C++ has RTTI disabled by default.

    \Reyelts\
    I personally own a copy of the ARM, D&E, and TC++PL, and have been programming for a good decade in C++, so I'm pretty well versed on the reason d'aitre for templates in C++.
    \Reyelts\

    ...And that is?

    \Reyelts\
    In any case, your argument against generics in Java is fallacious. Your excuse is that we have run-time type safety, so why do we need compile-time type safety? In that case, I propose we immediately drop all static typing from Java. I hope you would know better than that.
    \Reyelts\

    That's not at all what I'm proposing. My point is one of cost in terms of language complexity and readability/maintainability of future code vs. what we have today. I would simply _love_ to have a generics mechanism that was simple, easy to understand, and added no large extra complexity to Java. Unfortunately, that's not what this proposal encapsulates. And at the same time, the real safety this provides isn't much greater than what we already enjoy under Java.

    I stand by my original arguments, which I haven't seen refuted yet (other than one-liners such as saying it's "fallacious"). Generics in a language like C++ made sense when it was added, because there was _no_ safe alternative at the time. The case within Java is entirely different - and it's not clear that the benefits outweigh the cost.

    As for ARM and D&E references - those are there strictly for the large number of people in this forum who don't seem to know - or mis-recall - the actual reasoning behind templates in C++ way back 13 years ago, and who are (IMHO) erroneously extrapolating that Java "of course" needs generics.

        -Mike
  44. Generics in a language like C++ made sense when it was added, because there was _no_ safe alternative at the time. The case within Java is entirely different - and it's not clear that the benefits outweigh the cost.

    It's the most voted for ticket in the history of Bug Parade, and that suggests your cost/benefit analysis is wrong about Java generics.
  45. \Miller\
    It's the most voted for ticket in the history of Bug Parade, and that suggests your cost/benefit analysis is wrong about Java generics.
    \Miller\

    It is certainly an area where opinion weighs heavily, and you can't objectively "prove" a right or wrong case.

    With that in mind, quantity doesn't always equate to quantity. As someone somewhere once said, the truest form of democracy with a universal voice for the people will result in the majority voting themselves bread 'n' circuses until the state is bankrupt - or a revolution replaces it. And "Number 1" by votes in this case is almost meaningless...from the bug parade at:

      http://developer.java.sun.com/developer/bugParade/top25rfes.html

    Generics is right at the top with a _whopping_ 1,359 votes :-) What's that as a percentage of Java developers?

    Personally, I believe we've already seen a language designed-by-committee, it's called Ada, and I don't want Java to go there :-) Much of "Tiger" appears harmless and will add minor conveniences to the language. Other areas will IMHO make it much harder ot maintain Java programs in the long haul (like generics, varargs) without a big enough payback.

    Please also note how the voice of the people operate in general - real items that are really hampering real software ("Need ability to set socket options on URLConnection", "(fs) Add unmap method to MappedByteBuffer", "Memory Use Problem", "Improve Java VM startup time", "No way to reload a ResourceBundle for a long-running process") have much lower vote counts than Generics do, even though they're actually pretty serious problems for people facing them.

         -Mike
  46. "Generics in a language like C++ made sense when it was added, because there was _no_ safe alternative at the time."

    Generics in C++ is much more than what you state. Templates better enabled the STL to be what it is to be sure. But generics are much more than that. In fact, they could have easily created some base class in the STL for everything that was to be put in a collection.
    There are bunches of libraries that were created to do just that sort of thing before the STL was standardized and supported: MFC, Borland's OWL, RogueWave, etc.
    I've used templates to do many things totally unrelated to the STL over the years. I think Java would be much better if it to had generics.

    "As for standards conforming - last time I checked Visual Studio/Visual C++ has RTTI disabled by default. "
    RTTI adds some overhead. You really don't need it for most applications...just like you don't need dynamic_cast<>.

    "...real safety this provides isn't much greater than what we already enjoy under Java. "
    I disagree but appreciate your opinion. To me, however, it can be more than just type safety.
  47. \Snopes\
    Generics in C++ is much more than what you state. Templates better enabled the STL to be what it is to be sure. But generics are much more than that. In fact, they could have easily created some base class in the STL for everything that was to be put in a collection.
    \Snopes\

    Actually, no. As I'm sure you're aware, the original STL name (Stepanov, <can't remember> and Lee) was changed to Standard Template Library. The _entirety_ of STL is based upon templates, and would not exist at all without it.

    As for "some base class" - C++ has no single root, so what base class would that be exactly? I sincerely doubt that C++ developers would use multiple inheritance solely to stick an object in a collection. Short of that, their alternative was...(void *).

    \Snopes\
    There are bunches of libraries that were created to do just that sort of thing before the STL was standardized and supported: MFC, Borland's OWL, RogueWave, etc.
    \Snopes\

    Prior to templates, every attempt at creating a standard collections package quite frankly sucked. They either forced you to subclass a class foreign to your implementation, or used (void *). MFC and OWL hardly count, being severely tied to a very specific platform. RogueWave was the standard for years, but since it wasn't a "true" standard the end result was a mismash of code - some that used Rogue Wave, some that "did it on its own", and some that did things too bizarre and hideous to mention here :-)

    \Snopes\
    I've used templates to do many things totally unrelated to the STL over the years. I think Java would be much better if it to had generics.
    \Snopes\

    I never meant to imply that generics or templates were restricted to collections duties. And I've also seen some of the hideous code "unrelated to STL" that individual developers have foisted on their colleagues over the years which took _full_ advantage of template features (and confused the holy hell out of everyone, including the original implementors).

    \Snopes\
    I disagree but appreciate your opinion. To me, however, it can be more than just type safety.
    \Snopes\

    For me, having worked in both product environments and very mixed "business" environments, it always comes down to other people's code that I'm going to have to maintain and enhance. I won't speak to maintaining other people's template code - I'm afraid my constitution just isn't up to it at this moment in time.
    But I can say that the current generics proposal for Java has me worried. I'm not convinced either way 100% yet, but it looks to me like the complexity we're going to see is going to outweigh any convenience. And _that_ means I'm going to get to take ownership of some "clever" bit of generics code someone passes off to me in the near future.

         -Mike
  48. "Actually, no. As I'm sure you're aware, the original STL name (Stepanov, <can't remember> and Lee) was changed to Standard Template Library. The _entirety_ of STL is based upon templates, and would not exist at all without it. "

    That's my point. Templates are "vital" to the STL but not necessarily to the C++ language itself.

    "As for "some base class" - C++ has no single root.."

    I know, but a root class could have been added to the STL, like MFC did with CObject, RougeWave, etc. If you want to put an object in an STL container, it must be of type CObject, or whatever....
  49. To me, however, [Java generics] can be more than just type safety.

    Totally. Readability's at stake here. Even javadocs get more specific with generics.
  50. <Miller>
    Totally. Readability's at stake here. Even javadocs get more specific with generics.
    </Miller>

    Readability is indeed at stake - but not in the way I think you mean :-)

    Certainly, using the prebuilt Collections package will be easier and more readable. But have you considered the readability of new code built explicitly using generics aggressively? I guarantee you're going to see an explosion of code from many people using generics, and alot of it isn't going to be pretty. And even you may have maintain someone else's rad-cool generics-heavy code sometime in the near future :-)

         -Mike
  51. I guarantee you're going to see an explosion of code from many people using generics, and alot of it isn't going to be pretty. I guarantee you're going to see an explosion of code from many people using generics, and alot of it isn't going to be pretty. And even you may have maintain someone else's rad-cool generics-heavy code sometime in the near future :-)

    I agree that lacking typedefs, Java generics can get ugly. And obviously generics are only worthy if they reduce human error. But like almost every change ever to the Java Language Specification, you can forgo the new feature where you don't see benefit to maintenance. If your coworkers are incapable of such discretion, then what a bummer. I accept that risk.
  52. \Brian Miller\
     But like almost every change ever to the Java Language Specification, you can forgo the new feature where you don't see benefit to maintenance. If your coworkers are incapable of such discretion, then what a bummer. I accept that risk.
    \Brian Miller\

    I've never worked in a situation where I could control who I worked with, and certainly never worked anywhere that allowed me to control what features someone else used in their own stuff. And I learned a long time ago that if it's there, someone will use it (no matter what "it" is).

    Perhaps many people have the luxury of only working on their own code that they alone authored, or they've been incredibly blessed and only work closely with great software developers with a mountain of experience. On every team I've worked on with >3 people, the talent level has ranged from complete incompetent to genius. On projects using C or C++ this has often been catastrophic without draconian discipine being enforced. With Java, it's been far less of a problem because the language is small enough and designed in such a way that even the most twisted or just plain bad developer can only do a moderate amount of damage. Oh, really bad code can and does get written, but not on the same sheer scale as some other languages.

    But I think the specifics of the generics proposal is opening the door for a whole new set of twisted code coming down the pike. Whatever gains good developers may get from it are going to be pretty small in the end, and those small gains are going to be wiped out by the avalanche of unreadable/unmaintainable code from others.

         -Mike
  53. "With Java, it's been far less of a problem because the language is small enough and designed in such a way that even the most twisted or just plain bad developer can only do a moderate amount of damage."

    There's a lot of truth to that. But don't you get frustrated with Java's shortcomings? Every day I write code in Java (which for the last 2+ years is 40+ hours a week) I get aggravated at the language. It's usually things that are not in the language; most of them simple things. I can live with the idiocy of allowing constants in interfaces, etc. But there's some things that if added would make life som much easier,
  54. \Snopes\
    There's a lot of truth to that. But don't you get frustrated with Java's shortcomings? Every day I write code in Java (which for the last 2+ years is 40+ hours a week) I get aggravated at the language. It's usually things that are not in the language; most of them simple things. I can live with the idiocy of allowing constants in interfaces, etc. But there's some things that if added would make life som much easier,
    \Snopes\

    I'm of two minds on that. On the one hand, it's such an enormous relief working on Java-based products that I truly don't mind. Occasionally I have to work harder to get the performance or feature-set I need, but overall the plusses are so enormous that I don't sweat the down side too much. The majority of the other work I've done in the past 14 odd years has been in C, C++, and perl, and those projects don't hold a candle to the Java work. When considering a project as a dynamic, living code base that is touched by many hands, the Java based ones stand out in the most positive light. The C projects have always been plauged by people who just didn't "get" the intricacies of working that close to the machine, and coupled with the very procedural aspect lead to huge functions, a highly polluted global namespace, and core dumps everywhere. C++ projects got rid of the huge procedural functions, and replaced it with the inevitable impenetrable code that C++ so encourages - plus all the core dumps everywhere.

    Perl stuff jettisoned the core dumps, a big plus in anyone's book, but it is truly the modern champion of write-only languages (even, I admit, for my own code - I seem to re-learn perl every year).

    Java projects haven't suffered these sorts of problems because it's powerful enough, and still small enough.

    On the other hand, I do occasionally get frustrated with the very smallness of the language. Some designs are harder than they need to be to implement, and I dislike slogging through brittle boilerplate code as much as anybody. As I've mentioned a time or two before, I would embrace a really elegant generics mechanism in a heartbeat, along with some other things (such elegantly incorporating a few Eiffel features). Unfortunately, from where I sit, the new most ambitious language additions aren't very elegant, and whatever benefits I might gain to assuage my frustrations are heavily counter-balanced by the fact that the additions don't fit the original language well, and are going to lead to coding atrocities commited by the unwitting.

         -Mike
  55. "C++ desperately needed generics, because the language lacks a single root for class inheritance "

    Where did you get that?

    "In Java, we already have a very well defined and safe checking mechanism."

    What is safer, compile-time or run-time?

    "- in C++, generics were _vital_"

    Baloney. Generics are not vital....they are very useful but not at all vital.
  56. "C++ desperately needed generics, because the language lacks a single root for class inheritance "

    \Snopes\
    Where did you get that?
    \Snopes\

    Please read the Annotated C++ Reference Manual and Design and Evolution of C++, then get back to me.

    "In Java, we already have a very well defined and safe checking mechanism."

    \Snopes\
    What is safer, compile-time or run-time?
    \Snopes\

    Actually, it's been proven beyond a doubt that run-time safety is ultimately safer than compile-time safety, for the simple reason that compile time safety isn't always possible. The advantage of compile-time safety is that it catches certain classes of errors earlier, but it is _less_ safe than runtime safety because programs are dynamic, not static.

    \Snopes\
    Baloney. Generics are not vital....they are very useful but not at all vital.
    \Snopes

    Stroustroup has repeatedly stated (sometimes emphatically) that adding generics to C++ was in fact vital, and he regreted the fact that he hadn't added them earlier than he did. And the reason why generics were so vital is that without them, C++ provided _zero_ type safety in a wide variety of common programming situations, such as a generic collections package, which were forced to use (void *) pointers for members and static casts by client code - which are neither compile time or runtime safe. And, again, if you doubt this, please actually read the ARM and DnE, which explains in extreme detail why generics/templates were added to the language, and what holes they were specifically designed to fill.

         -Mike
  57. Foreach as a keyword[ Go to top ]

    Given that the grammar could still differentiate between the foreach() loop and foreach() method call fairly easily (at a cost of one lookahead), I really don't understand this..


    Or, lets just keep the notion of a reserved word exactly the way it is now.


    > If you wanted to optimize a bit, and the new grammar would prefer foreach() loop construct expansion (and roll back if necessary), it should not even have that a big impact on the compile speed.

    *speachless*
  58. printf for java[ Go to top ]

    "The suggestion of adding printf to Java was actually booed by the audience at Tuesday's technical keynote. Seems like the jury is still out on this one"

    I am really supprised by this.
    Firstly why someone would get so emotional about it.
    Secondly it appears to be a good idea.

    I appear to be missing the point here.

    What is so wrong with a printf in java
  59. I felt a little better after the Generics talk. As the speaker remarked I am one of those who have brain damage from the days of using Templates in C++. I have therefore been reserving judgment on the introduction of Generics.

    I was most impressed with the way inheritence and migration had been thought out.

    Nice work,
    David
  60. JDO at JavaOne[ Go to top ]

    I tried posting this as a news article but I guess my unsubstantiated gossip doesn't cut the mustard with TSS! :-) So, following is summary (albeit toned down) of stuff I saw on JDO at JavaOne.
    >>>>>>>>>>>>>>>>>

    It was a dark night in a city that keeps its secrets, where one man is still trying to find the answers to life's persistent questions...OK, OK enough of the Guy Noir quotes, but seriously, there was an air of mystery (or maybe just lack of *official* publicity) surrounding JDO at this year's JavaOne.

    Sun only seems to be able to find JavaOne presentation opportunities for JDO late at night. Spec lead Craig Russel's JDO BOF on Tuesday night started at 10:30 PM and David's BOF began at 9:30 PM. Craig did manage to work plenty of JDO into a technical session entitled "Applying Open Source and Web Technologies Together: Struts and OJB". In fact, this presentation seemed to focus on JDO! It was a great presentation which even included a functioning web application for publishing RSS feeds using Struts and the Sun JDO RI.

    David's BOF presented work he did to implement the Rice University Bidding System (RUBiS). Five different JDO vendors participated; four provided O/R mapping implementations and one provided an object database implementation.

    Designed to benchmark various implementations of an online auction site, RUBiS has in the past been one of the few sources of quantitative comparisons between CMP, BMP, and straight JDBC architectures. So it was with baited breath that the audience anticipated David's results for JDO. After a code review of JDO, CMP and JDBC it was apparent that the JDO code was the most comprehensible, but the audience came to see bar charts and prompted David to push forward. The first quantitative slide showed a "lines of code" count for JDBC, CMP and JDO. No surprises there, JDO had the smallest amount of java source code.

    As David was preparing to move on to the quantitative results, an AV guy from Key3 Media literally shut David Jordan down in mid sentence informing us that the time was up and turning off both projectors. The audience squawked about the iniquity to no avail, and finally trooped into the hallway where David was literally cornered, and availed himself of questions. The big question: was JDO faster?

    It turns out that as with all benchmarks, the 5 JDO participants are squabbling over the results, though that's my interpretation, not what David said. According to David he has no results to present at this time, but in a few months the quantitative results will be available.

    With that, the crew of JDO implementers and users made their way to the local pub. Over a few beers, conversation turned to the political questions of the day: Why are the big database vendors against JDO? Why was David Jordan's mike shut off during Oracle's presentation, effectively silencing his defense of JDO? Was "The Smoking Man" behind it all?

    Answer: it doesn't matter. There seems to be a genuine groundswell of developer interest in JDO. In David's words, "Once you try JDO, you're hooked."
  61. Incorrect Formatting[ Go to top ]

    When I first saw this on tha summary of JavaOne (Day 3) :
    List deck = new ArrayList(52);
    for (Suit suit : Suit.VALUES)
       for (Rank rank : Rank.VALUES)
          deck.add(new Card(suit, rank));
          Collections.shuffle(deck);

    it took 2 seconds for me to realize that Collections.shuffle is incorrectly indented! Natural the shuffle must occur after the deck contains all the cards.
  62. If we can move away for a moment from the totally trivial (for or foreach: What's the difference? 4 extra characters to type, IMHO. Like anyone really gives a monkey's...).

    I'm very interested by this MetaData facility. However there seems to be a distinct lack of follow-up material on this proposal... Questions:

    1. Does anyone know of a source for a detailed analysis of the proposal?

    2. Does it overlap, interfere with, or complement the work already done by the XDoclet crowd? (e.g. are Sun going to do a 'Logging package' here, and give us a three-quarters baked version of something that already exists within the community?)

    TIA
      /david
  63. Metadata[ Go to top ]

    currently compuware has the implementation of the MetaData facility according to OMG's standard. It has been integrated into a tool called OptimalJ. you may check Compuware's web site to find more information.
  64. Static Import[ Go to top ]

    Hi all

    The thing I hate most in the Tiger is the introduction of static import. It is extremely confusing in a bigger problem where you static imported a few more classes/packages. I think people who have worked with C++, VC would know this and especially true for those who are not good at C++/VC like me but have to work it because of the job :-(

    I strongly disagree the introduction/use of static import and it is like asking people to use short but meaningless variable names. It is a very shortsighted decision!! Have any voiced out this issue to the JCP?


    Edmond
  65. Static imports[ Go to top ]

    First of all, I posted a quick defense of static imports on my weblog:

    http://freeroller.net/page/cbeust/20030616

    Second, I don't understand your objections:

    The thing I hate most in the Tiger is the introduction of static import. It is extremely confusing in a bigger problem where you static imported a few more classes/packages.

    Can you expand on what the "bigger problem" is exactly?

    I strongly disagree the introduction/use of static import and it is like asking people to use short but meaningless variable names.

    I don't see the connection between static imports and asking people to use shorter names. Or maybe you are saying that you prefer to read

    Math.sqrt(x)

    rather than

    sqrt(x)

    ?

    In which case, I think it's really a personal matter. If the name is clearly non-ambiguous, this practice improves readability. And if you are not quite sure what symbol is being invoked, finding the definition of the said identifier is usually one key away with an IDE (and if you are using a text editor, all you have to do is to search the identifier on the import lines).

    --
    Cedric
    http://beust.com/weblog
  66. Static imports[ Go to top ]

    Hey, look, its Perl:

    use POSIX qw/getpgrp tcgetpgrp/;

    No, no, wait....its Python:

    from sys import argv

    No! its Java!!!:

    import static Math.*;

    Sorry, rather cheeky of me, I know. :)

    <Cedric>
    In which case, I think its really a personal matter. If the name is clearly non-ambiguous, this practice improves readability...
    </Cedric>

    Methinks this is exactly the point of the poster, mate. The name is already clearly non-ambiguous as 'Math.sqrt', que no? At least in this girl's mind, its the same principle as operator overloading. Nobody wants to read 'a + b = c' in some source code somewhere and have to determine what '+' means in this context. Similarly, why should I now have to stop and (grep/lookup/wait for my IDE to tell me) what or where sqrt comes from? Sorry, mate. I am all for readability, but if its a personal matter, why does it need a language extension?

    Kinsley
  67. Static imports[ Go to top ]

    <kinsley>The name is already clearly non-ambiguous as 'Math.sqrt'
    [snip]
    Nobody wants to read 'a + b = c' in some source code somewhere and have to determine what '+' means in this context.</kinsley>


    Exactly. Thanks for taking the words right out of my mouth. I cannot see any significant gain in this proposal, and the loss of unambiguity has to be a real concern.

    Should this make it into Tiger, I will then have to spend time adding guidelines for my development team to our coding standards. Something along the lines of "Use only when the import is clearly unambiguous - i.e. very rarely or not at all".

    All this to save a search and replace should the class be renamed? I'm not convinced at all. Cedric - put me down as a no!

    /david
  68. Static imports[ Go to top ]

    <David Hamilton>Should this make it into Tiger, I will then have to spend time adding guidelines for my development team to our coding standards. Something along the lines of "Use only when the import is clearly unambiguous - i.e. very rarely or not at all"</David Hamilton>

    I agree completely. Also we might witness more poor code where private methods will be prefixed with a "pr_" or something like that to differentiate a private method from a global (static) method. Also changing the static import from one to another could result in a different method being called (of a different class). This new feature has many annoying side-effects and should be re-evaluated.
  69. Static imports[ Go to top ]

    <kinsley>The name is already clearly non-ambiguous as 'Math.sqrt'
    [snip]
    Nobody wants to read 'a + b = c' in some source code somewhere and have to determine what '+' means in this context.</kinsley>
    \Hamilton\
    Exactly. Thanks for taking the words right out of my mouth. I cannot see any significant gain in this proposal, and the loss of unambiguity has to be a real concern.
    \Hamilton\

    The difference between the two is worlds apart. 'a + b = c' has a world of ambiguity problems inherent in operator overloading. By contrast, tracking down sqrt() via static import is rather trivial. I personally think the two should be considered entirely seperately from each other.

         -Mike
  70. Static imports[ Go to top ]

    <Mike> The difference between the two is worlds apart. 'a + b = c' has a world of ambiguity problems inherent in operator overloading. By contrast, tracking down sqrt() via static import is rather trivial. I personally think the two should be considered entirely seperately from each other.
    </Mike>

    The point isn't whether its trivial or not, mate. The point is whether its necessary. Good artists always steal (or however the old quote goes), and we are all colored by our experiences with other languages/environments (as I am sure from reading your posts you would have some interesting C++ stories to share with us).

    But my point is, if it ain't broke, don't fix it.

    The "need" for static import appears to be driven by the same "need" driving most of these other features: "Well, [insert language here] has [insert feature here], so Java must be able to benefit from it somehow." Thus we have enums, generics, "foreach", autoboxing, etc. I don't see the "problem" that static import attempts to address, and the "convenience" doesn't register with me. So, right, its a tool issue (hey, we gotta keep the folks at IntelliJ employed), it only takes a moment to scroll back up through the source to locate the import, or, my favorite, "You don't have to use it if you don't want to".

    I certainly am in favor of stealing good ideas and adapting them. After all,
    There's More Than One Way To Do It. But at what point is there enough icing on the cake?

    Cheers,

    Kinsley
  71. Static imports[ Go to top ]

    \Burton\
    But my point is, if it ain't broke, don't fix it.
    \Burton\

    Well, that's certainly a valid viewpoint that I really can't contradict. My own view is that it's not harmful and maybe helpful in some situations. I surely don't understand some extreme objections to it, but you're right that it's not strictly necessary.

         -Mike
  72. Static imports[ Go to top ]

    <mike>The difference between the two is worlds apart. 'a + b = c' has a world of ambiguity problems inherent in operator overloading. By contrast, tracking down sqrt() via static import is rather trivial. I personally think the two should be considered entirely seperately from each other.</mike>

    While they are not identical, they are different faces onto the same problem. And the Math methods are good examples. I was initially irked by what I saw was excessive verbiage, but now I find the likes of Math.abs() very comforting in their clarity.

    After all - the Math methods use very terse names (which reflect the culture from which they come), which, if your mind is not in 'Math-context', can be quite unhelpful. Using 'Math.abs()' does exactly what it says on the tin, and I like that.

    /david
  73. Static imports[ Go to top ]

    \Hamilton\
    After all - the Math methods use very terse names (which reflect the culture from which they come), which, if your mind is not in 'Math-context', can be quite unhelpful. Using 'Math.abs()' does exactly what it says on the tin, and I like that.
    \Hamilton\

    For occassional users, I agree, but it's a bit different for hardcore Mathers (as just one example). The reason math terms are terse in the first place is so forumulas are as readable as possible, and you don't get lost in all the text. If you're doing heavy trig in a class, seeing Math.sin() Math.tan() constantly is going to make forumulas very hard to read. Being able to get rid of the <Math.> prefix goes a very, very long way towards readability.

    The same applies to other domains as well. And the overall advantage is that it adds very little added complexity or ambiguity. The actual "cost" in terms of the language and adding in problems is extremely low.

    Operator overloading, on the other hand, gives you even more notational convenience, but at a much, much higher cost. You cannot easily give the language operator overloading without a very high cost.

         -Mike
  74. Static imports[ Go to top ]

    <mike>For occassional users, I agree, but it's a bit different for hardcore Mathers (as just one example). The reason math terms are terse in the first place is so forumulas are as readable as possible,</mike>

    Hmmmm - I've worked with some mathematicians code over the years, and readability usually seemed a low priority. A sweeping generalisation, I know, but they were very much of the one and two character variable name brigade, and usually their code readability was extremely poor.

    I would be extremely concerned if this change was being driven but a small (but vocal) minority, for whom terseness is an overriding priority.

    [Holds up red rag, and prepares to jump aside as the trampling hooves approach!]

    /david
  75. Static imports[ Go to top ]

    David writes:
    Exactly. Thanks for taking the words right out of my mouth. I cannot see any significant gain in this proposal, and the loss of unambiguity has to be a real concern.


    I think the main reason why people are turned off by this feature is because they are looking at the wrong way.

    The power is not in the source, it's in the import line.

    Please reread my weblog entry.

    --
    Cedric
    http://beust.com/weblog
  76. Static imports[ Go to top ]

    <cedric>
    I think the main reason why people are turned off by this feature is because they are looking at the wrong way.
    The power is not in the source, it's in the import line.
    Please reread my weblog entry.
    </cedric>


    Yup, take your point. Which begs a question:

    Can we have static import not allowing wildcard imports? I'll drop my objections to it if the * syntax for statics is deemed illegal.

    /david
  77. Static imports[ Go to top ]

    David: Can we have static import not allowing wildcard imports? I'll drop my objections to it if the * syntax for statics is deemed illegal.

    The "*" thing in imports is a language hack to start with. It's the only place in our entire Java compiler that we had to put a "bridge" (hack). Furthermore, it assists in the moral decay of fine code everywhere. I am currently organizing a group called the Society for Limiting Asterisks in Programming (SLAP) whose goal is to eventually eliminate "*" imports altogether. In our coding conventions, we have completely disallowed the use of the "*" import.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  78. Static imports[ Go to top ]

    The "*" thing in imports is a language hack to start with.

    All import statements are a language hack. But syntactic sugar is the primary benefit of any language.

    In our coding conventions, we have completely disallowed the use of the "*" import.

    Your loss. Source style's for weenies.
  79. Weenies[ Go to top ]

    <brian>
    > In our coding conventions, we have completely disallowed the use of the "*"
    > import.

    Your loss. Source style's for weenies.
    </brian>


    No. Source style is for those who assume the code may have to be edited/viewed some day by people without access to an IDE that will do dependency tracking for you.

    The source is all you've got - be explicit in it. It's the only guide you've got to what's happening.

    If source style is for weenies, then source laziness is for losers!

    /david
  80. Static imports[ Go to top ]

    One extra thought here:

    When creating a set of constants such as RED, YELLOW, GREEN example in the past you knew (unless they're in an interface and somebody extends it) that they will be referenced by the fully qualified name...

    TrafficLight.RED for instance.

    However, for a programmer creating a constant and knowing that it may well be statically imported, RED then becomes a very poor constant name (when deprived of the TrafficLight context). I think it is quite likely that programmers, in this situation will start naming the constants more specifically in order to compensate for what may well be removed. So you're likely to get

    LIGHT_STATE_RED
    LIGHT_STATE_YELLOW
    LIGHT_STATE_GREEN

    which means that we're effectively back to square one, except that the user of the constants is then pretty much forces to use the static import to avoid the ugly

    TrafficLight.LIGHT_STATE_RED

    So, I'm not convinced that we're making any progress here... apart from offering more ways of writing ugly code.

    /david
  81. Static imports[ Go to top ]

    David writes:

    > Exactly. Thanks for taking the words right out of my mouth. I cannot see any significant gain in this proposal, and the loss of unambiguity has to be a real concern.

    >
    > I think the main reason why people are turned off by this feature is because they are looking at the wrong way.
    >
    > The power is not in the source, it's in the import line.
    >
    > Please reread my weblog entry.
    >
    > --
    > Cedric
    > http://beust.com/weblog

    1. Normally, I don't read weblogs, truly they are the white noise of the Internet. However, since this seems to be your solution to the comments, I took your advice. This prompted a few questions:

    /weblog/
    2. Static imports allow you to decrease the amount of coupling between your classes.
    /weblog/
    --May I ask what the basis is for this statement? How will the static import of select members of a class decrease coupling as opposed to importing the entire class? One line or a hundred, you are still dependent on a class if you import any of it--it still makes a reference in the constant pool.

    --If, as you say, the true power of this feature is in the import statement, not in the source, why does the static import section of the JSR list its motivation as mathematical functions and named constants, and specifically refer to "undesirably verbose" (I assume I should read that as "fully qualified") references to the same in source code?
    Importing Static Members in the Java Programming Language

    /weblog/
    You are only using the identifiers RED, YELLOW and GREEN from the class TrafficLight, we recommend that you create a specialized class containing only these identifiers.
    /weblog/

    --And the specialized class will do....what? How will this reduce coupling?

    --Do you really want to extend the syntax of the language so that dependency analyzers can suggest more refactorings? Do I need a dependency analyzer to tell me that I have a reference in my class to the class Math when I read "Math.sqrt()" in my code? Can't dependency analyzers do this already?

    --Is it really necessary to extend the "power" of the import statement and at the same time allow less readable code in the source?

    Sorry if I seem antagonistic--that's not my intention. I just don't "get" the need for this, and telling me to "read your weblog" for the answer didn't help either.

    Thanks,

    Cristian
  82. Static imports[ Go to top ]

    David writes:

    > > Exactly. Thanks for taking the words right out of my mouth. I cannot see any significant gain in this proposal, and the loss of unambiguity has to be a real concern.

    > >
    > > I think the main reason why people are turned off by this feature is because they are looking at the wrong way.
    > >
    > > The power is not in the source, it's in the import line.
    > >
    > > Please reread my weblog entry.
    > >
    > > --
    > > Cedric
    > > http://beust.com/weblog
    >
    > 1. Normally, I don't read weblogs, truly they are the white noise of the Internet. However, since this seems to be your solution to the comments, I took your advice. This prompted a few questions:
    >
    > /weblog/
    > 2. Static imports allow you to decrease the amount of coupling between your classes.
    > /weblog/
    > --May I ask what the basis is for this statement? How will the static import of select members of a class decrease coupling as opposed to importing the entire class? One line or a hundred, you are still dependent on a class if you import any of it--it still makes a reference in the constant pool.
    >
    > --If, as you say, the true power of this feature is in the import statement, not in the source, why does the static import section of the JSR list its motivation as mathematical functions and named constants, and specifically refer to "undesirably verbose" (I assume I should read that as "fully qualified") references to the same in source code?
    > Importing Static Members in the Java Programming Language
    >
    > /weblog/
    > You are only using the identifiers RED, YELLOW and GREEN from the class TrafficLight, we recommend that you create a specialized class containing only these identifiers.
    > /weblog/
    >
    > --And the specialized class will do....what? How will this reduce coupling?
    >
    > --Do you really want to extend the syntax of the language so that dependency analyzers can suggest more refactorings? Do I need a dependency analyzer to tell me that I have a reference in my class to the class Math when I read "Math.sqrt()" in my code? Can't dependency analyzers do this already?
    >
    > --Is it really necessary to extend the "power" of the import statement and at the same time allow less readable code in the source?
    >
    > Sorry if I seem antagonistic--that's not my intention. I just don't "get" the need for this, and telling me to "read your weblog" for the answer didn't help either.
    >
    > Thanks,
    >
    > Cristian
  83. Static imports[ Go to top ]

    [Sorry for my previous posting, bad copy/paste]

    Sorry if I seem antagonistic--that's not my intention. I just don't "get" the need for this, and telling me to "read your weblog" for the answer didn't help either.

    Yes, sorry about that, but I thought it was just one click away and avoided me to repeat myself.

    1. Normally, I don't read weblogs, truly they are the white noise of the Internet.

    The whole Internet is mostly noise, the secret is to use tools that let you filter it out :-)

    May I ask what the basis is for this statement? How will the static import of select members of a class decrease coupling as opposed to importing the entire class? One line or a hundred, you are still dependent on a class if you import any of it--it still makes a reference in the constant pool.

    True, but by listing all the methods you are using from a class, you can actually see right away how much you are coupled to the said class. You can imagine that it might make you realize that a class you import is too big (breaking the single-responsibility principle) and that some refactoring might be in order.

    I agree this is all theories right now, but I think I explained my point better.

    If, as you say, the true power of this feature is in the import statement, not in the source, why does the static import section of the JSR list its motivation as mathematical functions and named constants, and specifically refer to "undesirably verbose" (I assume I should read that as "fully qualified") references to the same in source code?

    Ah, good point. This is actually something on which Josh and I disagree. His main motivation for including this feature in the JSR was his realization that a lot of developers were abusing the "implement an interface so you don't have to fully qualify the constants" trick (see item... 17 I think from his Effective Java).

    I think the fact that Josh and I are seeing two different good things in this feature shows that there is value in it.

    --And the specialized class will do....what? How will this reduce coupling?

    It will only contain the constants, because that's all your class relies on. If further changes are made on the other class, your own class will not risk to be broken.
     
    Do you really want to extend the syntax of the language so that dependency analyzers can suggest more refactorings? Do I need a dependency analyzer to tell me that I have a reference in my class to the class Math when I read "Math.sqrt()" in my code? Can't dependency analyzers do this already?

    I agree, it's not "necessary". None of the features offered by JSR 201 are "necessary", but I think the emphasis is on readability.

    My intent is just to clarify what is going on so that everybody can reflect on these features. My goal is not to convince. As I just said, since none of these features are "necessary", it is predictible that they will face some resistance from the developer community. I believe that overall, they will improve the readability and the robustness of the code we write every day.

    Just my opinion...

    Thanks for taking the time to read thus far...

    --
    Cedric
    http://beust.com/weblog
  84. Static Import[ Go to top ]

    The thing I hate most in the Tiger is the introduction of static import. It >>is extremely confusing in a bigger problem where you static imported a few >>more classes/packages.


    >>Can you expand on what the "bigger problem" is exactly?

    Sorry, I mean in bigger programs that have static imported more classes/packages.


    >>Can we have static import not allowing wildcard imports? I'll drop my >>objections to it if the * syntax for statics is deemed illegal.

    Is the wildcard import disallowed? If so, it is not consistent with the normal import and seems to be very strange for people who don't understand the reason behind it - those VC, C++ programmer.

    Edmond
  85. Static Import[ Go to top ]

    <edmond>
    Is the wildcard import disallowed? If so, it is not consistent with the normal import and seems to be very strange for people who don't understand the reason behind it - those VC, C++ programmer.
    </edmond>


    Not at the moment. Surely the better way would be to deprecate the wildcard in the normal import (Cameron - can I join 'SLAP'?).

    If we did that calm would be restored and all would be well...

    /david
  86. Static Import[ Go to top ]

    I am disappointed with the static import feature. The JSR quotes the motivation
    as having to use the abs command instead of the Math.abs equivalent And the ability to import constants instead of creating an interface to implement constants as reasons.

    IMHO, the ability to add constants to an interface should have been forbidden in the first place. This will result in global methods making maintenance more difficult. This was a huge problem when programming in VB because developers found it very convenient writing many of their methods in .BAS files making the code kludgy. The language should encourage good coding practices, not have weaknesses (like Constants in interfaces) and patch solutions like these.

    Anyway, if they are to add this feature, it should be limited to only importing constants and static methods in the java.lang package. This should satisfy both of their above motivations.

    V
  87. Static Import[ Go to top ]

    I meant thet methods that are not in the java.lang package should not be available for static import. Only methods in the java.lang package should be available for static import. We should however be able to import constants/enums from any package.

    V
  88. Static Import[ Go to top ]

    \V K\
    IMHO, the ability to add constants to an interface should have been forbidden in the first place. This will result in global methods making maintenance more difficult. This was a huge problem when programming in VB because developers found it very convenient writing many of their methods in .BAS files making the code kludgy. The language should encourage good coding practices, not have weaknesses (like Constants in interfaces) and patch solutions like these.
    \V K\

    I think you're overstating the danger here. static import is an _import_ mechanism, not an export mechanism, which means its up to the "calling class" to use it. If the reverse was true - that you could export into the global namespace - then you'd have a problem.

    As such - its use is localized and very, very convenient for both readability and just getting code out. If you've ever worked on a complex piece of code which is tightly focused on one domain - doing complex calculations, implementing a specific version of a generic state machine, etc - then your code is going to be using alot of statics and constants. In those instances, not having to qualify names greatly improves readability. And the downside is relatively small. Certainly small enough that I think it's very worthwhile.

    On the flip side - something like operator overloading also gives you notational convenience, but at a heavy cost for readability and maintainability. In that case, the minuses I think far outweight the convenience. But here, the opposite is the case for me.

         -Mike
  89. Static Import[ Go to top ]

    I am not convinced about the import mechanism - export mechanism difference. Even in VB, we can explicitly call a method in a BAS file qualifying it with its filename. However, it was hardly done that way. A static method will be a global method. Developers will be tempted not to qualify their calls. Java will lose a great advantage which is its dependability. A method call can be traced to be either in the current class or its superclass. Now it could be in any of the statically imported classes. I personally feel this just hampers readability. Also when I add a new method, I must make sure that it has not been used statically. I feel all this pain is not necessary. At a minimum the JSR team must wait for more feedback before introducing such controversial features. Until then, this feature should not be opened up for regular method calls, but only for Constant variables and methods in the java.lang package.

    I would very much like to know how much of developer support is there for such syntactic sugar? I would much rather see core improvements in the language like support for DBCs, support for Event Delegates like .Net.
  90. Static Import[ Go to top ]

    On the ability to add constants to interfaces - personally I think this is a case of purists and academics shouting about something that has been a non-problem in actual usage of the language. I've seen people go on bitterly about name space pollution - but it's on such a small scale, and still done in a fairly controlled matter, such that it's just not something that's going to bite real developers writing real code very often. And when it does, working around it is less than trivial.

         -Mike
  91. Static Import[ Go to top ]

    I am disappointed with the static import feature.

    JavaScript has a 'with' keyword. Static import seems even better.