Showing messages 1 through 102 of 102.

• ADA like subtyping
  2007-08-18 07:12:24 rjilani [Reply | View]
  
  Personally I am against any more changes to core Java language at least for quite some time; but one feature that I really like to be part of Java is ADA like subtyping.
  
  A subtype is a type whose values are a subset of the values of some type. So a subtype is characterized by:
  • A base type
  • A set of values which is a subset of the set of values of the base type
  • The same operations as the base type
  
  It is a very elegant and clean way of checking the values of types at compile typing with out throwing lot of exception. E.g. instead of throwing an ArithmeticException inside your method because in parameter is less than 0; you can create a subtype of Integer with Range from 1..1000.

• Closures once again...
  2007-08-16 13:25:32 scotty69 [Reply | View]
  
  In Javaland, we should sometimes look over the rim of our coffee cup. It's not only Ruby or Groovy going for closures:
  
  

  
  
  class Program
  
  {
  
      static void Main(string[] args)
  
      {                    
  
          List<string> names = new List<string>();
  
          names.Add("Dave");
  
          names.Add("John");
  
          names.Add("Abe");
  
          names.Add("Barney");
  
  
  
          string abe = names.Find(name => 
  
                             name.Equals("Abe"));
  
          Console.WriteLine(abe);
  
      }
  
  }
  
  

  
  
  (hope the formatting works, no preview...)
  
  Looks a lot like Java, but in fact it's C# 3.0, where they call it Lambda Expressions. And they aggressively go even further (have a look at the LINQ stuff)
• Closures once again...
  2007-08-17 02:46:18 aehrenr [Reply | View]
  
  C# has now an immense amount of features. This will pose a problem in real projects. Given that Java works very fine in its current state, I think the best strategy for Java would be, to observe which of the many features of C# are actually used, what the side-effects are and if they prove to be really useful. Then, if seen as sensible, it could be integrated in Java some versions later and you would get only the good things. C# is currently looking like a excessively decorated christmas tree, something Java should avoid.
• Closures once again...
  2007-08-17 03:13:49 scotty69 [Reply | View]
  
  Well, I just wanted to point out that closures are not an exotic language feature. They are old, well understood, and a lot of mainstream languages have them. They're nothing scary, just one sharp weapon more in our toolbox...
• Closures once again...
  2007-08-17 04:08:13 aehrenr [Reply | View]
  
  My main point is not to oppose specifically closures, but the sheer amount of suggested language changes all together and that there is no end in sight. But anyway I think the closure proposal from Mr Gafter is overly complex and would repeat the story of Generics where much to much complexity has been added for too little gain.

  I think language changes should be an exception not a rule and should be thought about very well. Therefore I do not think that it is clever to quickly include language changes in Java 7. This release should focus on deployment and removal of bugs. Meanwhile we can observe C# how the numerous features behave in the wild.

• What About Software Engineering?
  2007-08-16 09:02:28 dhafenstein [Reply | View]
  
  A lot of these discussions are too focused on language syntax as if the compiler will solve all my problems. If only the language could check this, or prevent me from doing that, and so on. I don't think that anyone is stepping back and seeing the big picture here. It doesn't matter what the language checks or doesn't check, nobody would ever forget about engineering discipline, right? So, you implement walkthrus, reviews, and feedback between marketing, product management, design, construction, QA, support, documentation, and other groups to make sure that you have 1) solved the right problems, 2) have a quality and supportable implementation, and 3) that everyone is working from the same understanding. That said, the development team unit tests their code, and the QA team performs verification to the design materials. Even in an informal setting, nobody in their right mind would not test to verify behavior.
  
  So, my worry is that a lot of these features, while syntactically interesting, do not really amount to a hill of beans. Are we making the language overly complex and essoteric for any net gain in the big picture? Combine that with the overwhelming use of modern IDE's and tools to check, cross-check, fill-in boiler-plate code, suggest alternatives, enforce stylistic standards, and to test the code, do we NEED the compiler to do any more? We have never needed these things in the past and have built major systems, with high levels of complexity and quality. Why now are these "problems" raising their heads?
  
  Just because it is possible to do something does not mean that it is a good idea to do it. The compiler can't possibly save a programmer from doing something wrong. So, if the justification for these additions is to "protect the programmer" from making silly mistakes, then I suggest that this is a bad reason. There is a very old saying in software, "you can't make software foolproof because fools are so @&$% ingenious". That goes for languages too.
  
  If you want to solve problems in the language, then lets try some of these:
  
  1. Allow us to use an object reference in a switch, not just a primitive. Allow the case to be an expression instead of a constant.
  
  2. Add serial I/O support that is portable across platforms and supports USB as well as traditional serial devices.
  
  3. Add cross-language capabilities so that we don't always have to build our own bridges in JNI
  
  4. Adopt SWT as another GUI standard. It can coexist with Swing! It's just another tool in the toolbox.
  
  5. Add labeled breaks and continues. That would allow me to jump out of nested loops to any level in one statement rather than adding bizarre logic to detect when to break out.
  
  I'm not posting this message to suggest any specific changes, although I could. There are other features and capabilities that could be of value to a developer. However, of these, only a very small amount would be language changes. Almost all are added support, additional packages and implementations, etc.
  
  The java language (at 1.4 level) is a great language. As it stands, the language itself is very mature, and needs very little tweeking. The problem that I see is one of it being a mature product. As a product develops, it is basically a clean slate. Allmost all of the input is from every level of user of the product. As the product matures, the users that are getting their needs met stop being vocal, and the "majority" of the comments are being generated by the "minority" of the users. So, as a product matures, it is extremely important to make sure that you are not getting driven by a vocal minority, that will cause you to loose your silent majority. Also, the silent majority had better not remain silent, or else this is exactly the outcome that will happen!

• reified generics
  2007-08-16 06:55:14 pprun [Reply | View]
  
  reified generics : http://www.artima.com/weblogs/viewpost.jsp?thread=208860

• One Language change to end all language changes
  2007-08-15 22:49:26 xylifyx [Reply | View]
  
  Provide hooks into the compiler so that you can extend java with a sub languages. Useful small sub languages could be
  
  
  
  
  • multi line strings
    
  • embedded sql statements
    
  • reflection based dynamic method invocations
    
  • embedded xml
    
  
  
  in the top you would write
  
  import language sql org.bla.sql.EmbeddedSql;
  
  java would then be extended with some syntax to separate java and the extension languge so you could write something like
  
  int zip=12345;
  @xml.stream(System.out){
  <names>
  @java{
  for (String name : @sql.query{select name from people where zip = @java.zip}) {
  @xml{
  <name>@java.name</name>
  }
  }
  }
  </names>
  }
  
  @<language id>.<construct>{ text until '}' }
  @<language id>{ text until '}' }
  @<language id>.<construct>{{ text until '}}' }}
  @<language id>.<construct>{{{ text until '}}}' }}}
  
  this syntax should be enough to separate other languages and java.
  
  Maybe the languages can provide some information to tools so that eclipse can syntax hilight the embedded language.
• One Language change to end all language changes
  2007-08-16 06:10:53 jwenting [Reply | View]
  
  "this syntax should be enough to separate other languages and java." Yes, no other language would want anything to do with such garbage... I've been dreading XML syntax for programming languages for years, and here we have it (and worse).
• One Language change to end all language changes
  2007-08-22 08:21:55 xylifyx [Reply | View]
  
  I think you misunderstood the nature of the extension. The xml syntax was used as an example sublanguage to show how to mix sublanguages inside a loop. If you don't need a particular sublanguage then don't import it.
  
  The sublanguage concept is supposed to be completely generic and has no xml like syntax support at all. That is for a hypothetical xml sublanguage to support.
  
  If you don't like that particular sublanguge, then do not import it. But anybody that has generated xml in java code knows that a shorthand notation could be nice. I don't see it could bother you that a certain sublanguage exists.
  
  You may argue that my proposed syntax using the @ is ugly though.

• Some good changes others bad
  2007-08-15 09:11:53 heathm [Reply | View]
  
  Granted some of the proposed additions seam to have little value. Language level XML support? Do we even want this? Language level SQL has been done a number of times and every time it has resulted in a mess. Do we want to repeat these mistakes with XML?
  
  In my opinion, closures are long overdue. We don't need closures because Ruby has them. We need closures because they solve real world problems. They provide a clean mechanism for eliminating redundant error prone boilerplate code. They simplify creating event handlers and callbacks. I have yet to hear an argument for not including closures from someone who actually understands what closures are.
  
  Strings in switch statements are another feature that are long overdue.
  
  Language level property support might be nice but I think it's too little too late. We already have plenty of tools for working with the getter/setter pattern. I'm not convinced this is needed or wanted.
  
  Lightweight method references (ie. delegates), I'm all for this and honestly I'm surprised Java hasn't included this sooner. We can already do this with reflection so let's add compile time support for it.
  
  Operator overloading only makes sense for numeric types. If we could add support for operator overloading to instances of java.lang.Number, that might be acceptable. Using + for things like adding something to a collection reduces readability in my opinion.
  
  That just my $0.02.
• Some good changes others bad
  2007-08-15 14:13:15 ewin [Reply | View]
  
  

  I have yet to hear an argument for not including closures from someone who actually understands what closures are.

  Lets assume for a moment this would be true. And now we look at the many developers who don't want closures. What would it mean? It would mean that many Java developers are overstrained with such a feature. It would mean that Java has reached a point where the average garden-variety programmer can't handle the language any more. It would mean that Java is becoming a elitists language. I fact, I do think that a lot of the imminent Java changes are suggested because the ones making the proposals want to demonstrate their superiority.

  A side effect of programming becoming a mainstream job is that indeed the average clue-level of programmers has gone down. Outsourcing companies hire everyone with a pulse being able to spell the word Java. Java became successful because it was simpler, not better, than C++.

  Java is finally at a crossroad. Either it will stay simple and manageable or it will become an elitist language. Which side are you on?

• Some good changes others bad
  2007-08-16 10:46:54 heathm [Reply | View]
  
  Thank you for clarifying my point. Closures simplify Java. They're not some elitist feature. Closures are far easier for your garden variety developer to understand than anonymous inner classes. Closures will make it far easier for garden variety developers to use less boilerplate code for everyday tasks and thereby reduce the potential for bugs.
  
  Like I said, I have yet to hear an argument for not including closures from someone who actually understands what closures are.
• Some good changes others bad
  2007-08-17 00:14:20 jwenting [Reply | View]
  
  no, they make for far more obfuscated code. We understand fully what they are, thank you very much. Most of us have used languages that have them or something like them. Many of us have used languages with their progenitors, function pointers, long before anyone even dreamed up the term "closure".
• closures are actually simpler
  2007-08-16 07:18:11 nopjn [Reply | View]
  
  Anonymous inner classes are a lot more complicated than closure.
  Go explain all your newby Java developpers why a variable has to be final to be accessible by an inner class.
• Some good changes others bad
  2007-08-15 12:13:33 aehrenr [Reply | View]
  
  I have yet to hear an argument for not including closures from someone who actually understands what closures are.

  Now come on, you can't argue that people that do not want closures are to stupid to understand them. So they must be to stupid to use Ruby or Groovy!? The problem is not that closures are not a good feature, but that Java gets overloaded with more and more esoteric features that are not needed but greatly extend complexity, bring very little effective gain and do not fit in a very mature language. C++ has very few features that are stupid (in my opinion) but the problem is that it is too overloaded with features to express the same problem in a different way to be really handy. And you can bet that no simple and elegant solution would be chosen for closures in Java (as the one from Mr Bloch). Look what they specified for Generics, just to provide type-safe containers. Closures will add another equally complex chapter to Java, just look at the proposal of Mr. Gafter. And no end is in sight; operator overloading per se is no stupid feature too as is aspect oriented programming and so on. You cannot include every smart feature from some other language because this results in a confusing mess. Java is no elegant but has been a handy and effective language. This was the reason many developers chose Java. (Ruby or Python were already available at this time). I think it is better to have several programming languages, each with some distinct smart features than to have another C++: If you want closures and Java, use Groovy. Why force everyone to use closures just because it is the idiom of the season? In my view closures are mainly an elegant (and currently hip) idiom for iteration but you cannot do anything with them that can't be already done. Yes, they can reduce boilerplate but if examples are given, exception handling should be included! Here the devil is in the detail. Thats different to Ruby or Groovy where you need not to do exception handling.

• Some good changes others bad
  2007-08-16 12:05:31 heathm [Reply | View]
  
  

  
  Now come on, you can't argue that people that do not want closures are to stupid to understand them. So they must be to stupid to use Ruby or Groovy!?
  

  
  
  I'm not arguing that people are too stupid to understand closures. I apologize if my comment came across as such. I am arguing that many people argue against closures without taking the time to figure out what they are and what's being proposed. I can certainly understand people not looking into the various proposals out there because a lot of proposals out there and a lot of them are poorly explained and look very complicated.
  
  

  
  The problem is not that closures are not a good feature, but that Java gets overloaded with more and more esoteric features that are not needed but greatly extend complexity, bring very little effective gain and do not fit in a very mature language... And you can bet that no simple and elegant solution would be chosen for closures in Java (as the one from Mr Bloch). Look what they specified for Generics, just to provide type-safe containers. Closures will add another equally complex chapter to Java, just look at the proposal of Mr. Gafter.
  </blockqute>
  
  This argument that closures complicate the Java language needs to be justified. Look at the examples by Mr. Gafter in this presentation: http://www.parleys.com/display/PARLEYS/An%20update%20on%20Java%20Closures
  
  All the examples presented here simplify the Java language not make it more complicated. There are examples that show how closures can be used to reduce boilerplate code. Boilerplate code is never a good thing. Removing boilerplate code simplifies code. Can you really argue that creating a closure is more complicated than creating an anonymous inner classes? Try to explain to a garden variety Java developer why variables outside an inner class have to be declared final and watch his eyes glaze over. Inner classes are far more esoteric than closures. I would like to see some justifications for closures complicating the Java language when I have seen example after example demonstrating how closures will actually simplify the Java language.
  
  Granted, there are some details to closures that are complicated and arguably esoteric but the fact of the matter is that you will rarely, if ever, need to get into those details. Closures will be used primarily in place of anonymous inner-classes.
  
  

  
  And no end is in sight; operator overloading per se is no stupid feature too as is aspect oriented programming and so on. You cannot include every smart feature from some other language because this results in a confusing mess. Java is no elegant but has been a handy and effective language. This was the reason many developers chose Java. (Ruby or Python were already available at this time). I think it is better to have several programming languages, each with some distinct smart features than to have another C++.
  

  
  
  So because Java has been "a handy and effective language", there is no room for improvement? There are certainly a lot of language features that Java doesn't need or want but my desire for closures do not stem from the fact they're included in other languages. Nor does my desire for closures stem from them being the "idiom of the season." I want closures in Java because they simplify Java. They make it possible to do things that can't be done using inner classes. They reduce boilerplate code which reduces code complexity and reduces common mistakes (especially those made by new developers.) They make my life as a Java developer easier.
  
  

  
  If you want closures and Java, use Groovy. Why force everyone to use closures just because it is the idiom of the season?
  

  
  
  Who's forcing you to use closures? Is someone forcing you to use annotations? What about generics? Is your manager threatening to fire you if you don't use the new for loop syntax?
  
  
  

  
  In my view closures are mainly an elegant (and currently hip) idiom for iteration but you cannot do anything with them that can't be already done.
  

  
  
  What? A hip idiom for iteration? Is that all you see closures having to offer? There are a lot of things that closures can do that can't currently be done. For example, if you have an inner class in a for loop, can you break out of the for loop from inside the inner class? No you can't. Can this be done with closures? Yes it can.
  
  I stand by my original statement: I have yet to hear an argument for not including closures from someone who actually understands what closures are.
  
  

  
  Yes, they can reduce boilerplate but if examples are given, exception handling should be included! Here the devil is in the detail. Thats different to Ruby or Groovy where you need not to do exception handling.
  

  
  
  Watch the presentation at the URL above. It includes plenty of examples with exceptions and closures. It also includes a lot of examples showing that closures are far more than "a hip idiom for iteration."
  

• Some good changes others bad
  2007-08-17 04:35:55 aehrenr [Reply | View]
  
  Can you really argue that creating a closure is more complicated than creating an anonymous inner classes? Try to explain to a garden variety Java developer why variables outside an inner class have to be declared final and watch his eyes glaze over. Inner classes are far more esoteric than closures.

  You are correct. I would have also prefered closures. The specification of inner classes should have been thought about much more careful. They are beside many apects of Generics a good example that one should think very careful on language additions. But now things are like they are and I think it is even more confusing to have several dissimilar ways of formulating the same thing after addition of closures. In my private optinion a version of the language should be defined that is slightly incompatible with the current but that fixes the accumulated problems with inner classes, Generics, the way properties are written and so on (just like Python is going to manage it). Then Java could improve and stay a consistent and hand tool.

• Some good changes others bad
  2007-08-17 00:25:33 jwenting [Reply | View]
  
  I'm not arguing that people are too stupid to understand closures In that case why did you state so?

  So because Java has been "a handy and effective language", there is no room for improvement? No, you're putting words in peoples' mouths. Stating that there's no room for closures or operator overloading doesn't mean stating that there can't be changes that ARE appropriate...

  Who's forcing you to use closures? Is someone forcing you to use annotations? What about generics? Is your manager threatening to fire you if you don't use the new for loop syntax? The person who wrote the code you have to maintain. And yes, my manager would fire me if I didn't maintain the projects I have under my responsibility that use annotations (which I don't care for), generics, new loops, and autoboxing. And he'd have every right to as refusing to do my job is grounds for being fired.

  There are a lot of things that closures can do that can't currently be done. For example, if you have an inner class in a for loop, can you break out of the for loop from inside the inner class? No you can't. Can this be done with closures? Yes it can. Which makes for harder to comprehend code, added obfuscation, in other words, isn't beneficial in the least.

  Closures are function pointers in disguise, which is NOT something that's suitable for Java or any other language not designed from the ground up to have them.
• Some good changes others bad
  2007-08-17 17:18:21 heathm [Reply | View]
  
  

  
  Closures are function pointers in disguise, which is NOT something that's suitable for Java or any other language not designed from the ground up to have them.
  

  
  
  This is a rather obtuse definition of closures. Closures are actually much more than this but if you want to throw dirt at closures, that's a good way of doing it.
• Some good changes others bad
  2007-08-16 06:07:43 jwenting [Reply | View]
  
  It's the only argument the closure proponents have left, after everything else has been shot down. "they're opposed to it because they're too stupid". It's exactly the same argument that European politicians use to push their vaunted "constitutional treaty" down out throats, we're supposedly too stupid to understand that signing over our national sovereignty to a bunch of unelected kleptocrats is "good for us".

  There's no need for closures. If there was everyone'd be screaming for them (or more likely would never have embraced Java in the first place or long since abandoned it). It's just a plaything for some elitist academicians in their ivory towers that have no grasp on the real world.

• Some good changes others bad
  2007-08-16 12:17:24 heathm [Reply | View]
  
  No one is saying that people opposed to closures are opposed because they're stupid. I think there are plenty of people arguing against closures without taking the time to fully understand what closures have to offer.
  
  And you're right. Closures are not needed. There are lots of language features in Java that are not needed. That doesn't been that closures do not have anything to offer and would not improve the Java language.
• Some good changes others bad
  2007-08-17 00:16:37 jwenting [Reply | View]
  
  you said exactly that when you said the only people who don't want them are people who don't understand them. And others have said it in even less veiled terms, stating bluntly that only people too stupid to be top programmers don't want closures.

  Closures aren't bad, in languages designed for them from the outset, but they're inappropriate for Java.

• Some good changes others bad
  2007-08-17 17:21:11 heathm [Reply | View]
  
  

  
  you said exactly that when you said the only people who don't want them are people who don't understand them.
  

  
  
  Now you're putting words in my mouth. I did not say that. I may have been unclear about what I meant and you understood me incorrectly. I basically said that the arguments I've heard for not including closures are based on false assumptions or misunderstandings. Just read this list. People are saying they don't want closures because "closures are just function pointers" or "closures are just a fancy way to do iteration" or "closures will just complicate the language". When people make these kinds of arguments, one can say with reasonable certainty that they don't understand closures. Closures are far more than function pointers and closures can be used for iteration but they're not limited to that and closures can simplify the Java language a great deal.
  
  Instead of trying to put words in my mouth, please explain, why are closures inappropriate for Java?

• How about JDBC Enhancements
  2007-08-15 09:02:06 bgyetko [Reply | View]
  
  So far many of the applications we develop require an observable data. Wouldn't it be nice if JDBC 5.0 would offer an observable interface on the connection? This would eliminate much of the code we develop. Here is what the code would look like (maybe on java.sql.Connection):
  
  public interface Connection
  {
  enum DbEvent{
  DbEventInsert,
  DbEventUpdate,
  DbEventDelete);
  
  // Listen to a particular insert, update and or delete on a particular query
  public void addDbListener(
  String query,
  EventEnum[] eventEnum,
  DbListener DbListener );
  
  // Remove the same listener as above to stop receiving updates
  public void removeDbListener(
  DbListener dbListener );
  
  }
  
  public interface DbListener
  {
  
  public void recordsInserted(
  ResultSet resultSet );
  
  public void recordsUpdated(
  ResultSet oldResultSet,
  ResultSet newResultSet );
  
  public void recordsDeleted(
  ResultSet recordsDeleted );
  
  }
  
  I think this would be a major improvement to make the JDBC connection a 2 way pipe between the client and database. Not all JDBC drivers would be force to implement it, since you could have JDBC 4.0 (like what is available now) and JDBC 4.0observable which adds the observable capability.
  
  
  
• How about JDBC Enhancements
  2007-08-15 09:42:38 heathm [Reply | View]
  
  This is JDBC API enhancement not a Java language enhancement. I very good idea non-the-less.

• Change can be positive
  2007-08-15 08:19:30 scolebourne [Reply | View]
  
  

  As a proponent of language change, reading the arguments against change is always interesting. For me, its all about finding the right language changes.

  Group one is "minor fixes to existing language features". This includes tweaks to the annotation system and reified generics.

  Group two is "features that increase compile-time safety". This includes method references and better null handling. Aspects of closures and properties also increase compile-time safety.

  Group three is "major new features that complement the existing language". This is the most controversial group. It includes possibilities such as limited operator overloading, properties, variable substituted strings, array notation to access collections and closures.

  Personally, I believe that the Java language can quite happily absorb many items in group one. I also strongly believe that group two is vital, as compile-time safety is really the biggest gain for a statically typed language.

  The real debate should be over group three. My own view is that Sun should create an JavaNextGeneration language which is 95% compatible with Java (for easy migration). But as they don't seem to want to do there has to be a choice whether to add group three features to Java. IMHO, I think the benefit is there - of course not everyone will agree.

• we need a complete jvm in mobile os such as linux
  2007-08-14 21:36:19 hooklee2000 [Reply | View]
  
  when we develope a program under a
  mobile phone，the only choice is j2me cldc or cdc. if you try to use swing ,you will find no vendor will provide AGUI recently.
  Under windows mobile,we can use Mysaifu JVM.
  Sybian,oh, nothing.
  I pay attention to a developing jalimo(a project provide jvm support nokia maemo and openmoko) because I really need a pure JVM.
  so we hope we can pay more attention to create a jvm to let "Write once,run anywhere" come true.
  you all works is wonderful, GPL licence is great to improve java.

• we need a complete jvm in mobile os such as linux
  2007-08-14 21:34:30 hooklee2000 [Reply | View]
  
  when we develope a program under a
  mobile phone，the only choice is j2me cldc or cdc. if you try to use swing ,you will find no vendor will provide AGUI recently.
  Under windows mobile,we can use Mysaifu JVM.
  Sybian,oh, nothing.
  I pay attention to a developing jalimo(a project provide jvm support nokia maemo and openmoko) because I really need a pure JVM.
  so we hope we can pay more attention to create a jvm to let "Write once,run anywhere" come true.
  you all works is wonderful, GPL licence is great to improve java.

• Java will become C#'s cheap copy
  2007-08-14 15:54:46 thiagosc [Reply | View]
  
  I think people aren't so excited about it. Why would that be?

  One of the things I would like to see is a better support for dynamic language. Actually I would to see the JVM to become synonym to "a VM to many languages" the same way .Net was marketed since day 0. What's the point of having tens of implementations floating around if only a fraction of them are production ready, and many suffer from performance problems because the VM doesn't have the features those languages need?

  About keeping up Java competitive, perhaps a new languages with all the features you could dream of and without the tons of deprecated stuff from Java would be nice. Not "Java 2" because the version numbers from Sun are unbelievably idiotic, but some other name to show exactly what it is: a departure from Java.

• Enough is Enough!
  2007-08-14 15:20:47 dhafenstein [Reply | View]
  
  I am a self-proclaimed Java bigot, I love the language. It is eligant, easy, but yet deceptively powerful. Exactly what a language should be. It is easy to teach, easy to learn, and produces applications that are rock solid. This addresses real-world concerns, quality and cost of development and maintenance. Languages are not the only culprits here to be sure, but java goes a long way to improve these aspects.
  
  I coded for over 20 years in C and then C++, and they are much more expensive to develop applications. The time to develop code is longer because of more complexity, the testing is longer, and so on. These languages make it too easy to make obscure, difficult to detect, problems that can raise their ugly heads in the field.
  
  So, when it all is said and done, I would agree with any suggestion to change the language to solve REAL problems that we are having in the field. If you look at java 5, the additions to the language do little or nothing to solve the real problems we are having. For example, generics are so unusable that they are a distraction and do not add any value. They are not available to reflection, so I cant use them to discover types at run time. They add clunky syntax, make the language harder to read, etc. What was the problem they were trying to solve, type-safe collections? Ok, thats a good idea, but really anybody that uses a heterogeneous collection should re-think their design anyway. I have NEVER found a reason to have mixed class types in the same collection, ever! So, if I have to cast, so be it. I'ld rather cast than use generics.
  
  We are using 1.5 on out current project, but have disabled the use of everything except annotations (which the jury is still out on). Guys, solve real problems and forget the syntactic wars. Listen to the people really building applications in the field and temper the language syntax and capabilities with that. We want 1.4 back!!!
• Enough is Enough!
  2007-08-18 07:22:51 rjilani [Reply | View]
  
  I couldn't agree more with a little disagreement on Generics; in my personal opinion one way or another strong type languages require Generics. Not to mentioned that Java started to deviate since the inception of C#; it was nothing but a wrong pressure from naive Java community who was and still is so obsessed to add any feature ever existed in any language. I guess it is a C# approach that Java community should not fall for; giving the fact that Java community are more mature than .NET community.
• Enough is Enough!
  2007-08-20 08:31:16 dhafenstein [Reply | View]
  
  The comment that I made re: generics is that the implementation of them is so poor that they are all but unusable. Generics could be a great feature, if it had been fully integrated into the language and not just some sort of compiler-candy-hack-thing-a-ma-bob! I agree that the language could have been enhanced with a good design and implementation. Also, the one thing that irritates me about a lot of the new features is that they have strayed away from traditional Java syntax. Much like the DTD did for XML. The one biggest thing that schemas did to enhance understandability was to adopt the SAME language and syntax for the extension. Guys, don't reuse existing keywords and just put a little @ sign in fornt of them! Thats confusing. Keep the language syntax consistent, that makes it easier to learn and use.

• Clean up among Sun's Java developers
  2007-08-13 12:15:48 ewin [Reply | View]
  
  Give the generics, XML and closure fanboyz the boot. No, wait. Before you kick them out force them to clean up the mess they created during the last decade. And don't forget the hundreds of thousands of open bug reports in the dreaded bugparade.

  In the future hire programmers who have created real-world applications before, not graduates and egg-heads who never wrote more than obscure demos and concept studies. And then keep them busy.

  I have the feeling that a lot of the stupid ideas that come up are because Sun's Java developers are bored. Next time someone comes up with a stupid idea force him or her to fix (not just close, really fix) ten bugs from the bugparade. When they complain give them ten more.

• Clean up among Sun's Java developers
  2007-08-13 15:07:19 alexlamsl [Reply | View]
  
  

  That is just mean :-)

  Although at this point of the game I am not interested in any substantial changes to Java in JavaSE7, rather than forcing these (potentially) bright minds to fix bugs I'd like to divert their attentions onto tools.

  Yes, tools that real-life programmers use in every day's life. If you can implement the anonymous inner class aspect of closure as a BeanInfo-editor-type plugin in IDEs, programmers who like to use it will benefit from it, those who don't think in that path of logic could stick to their old ways, and the Java Language would stay the same.

• Clean up among Sun's Java developers
  2007-08-13 22:16:25 jwenting [Reply | View]
  
  tools you say? Ant, Maven, javac, and IntelliJ are all I use on a daily basis. Maybe pencil and paper to draw some design concepts and take notes, and that's it. One reason to choose Java is to prevent (or reduce) vendor lockin, adapting too many tools that force you to work inside the framework provided by those tools only increases vendor lockin.

  Why do you think Sun is changing all tutorials to be Netbeans specific? It's the only way to get people to lock themselves in to Sun products when using Java, and not realise they've done it to themselves. Mind I don't blame Sun (much) for trying to increase the market share of their baby IDE, though IMO using beginners' tutorials for that is rather unethical for the maintainer of the language, but please don't turn Java into another language that can only be used in the context of a specified set of tools (like VB, Progress, CAVO, and so many others).

• Clean up among Sun's Java developers
  2007-08-14 00:25:43 theanuradha [Reply | View]
  
  "baby IDE" Baby's done grown up http://wiki.netbeans.org/wiki/view/NewAndNoteWorthy
• Clean up among Sun's Java developers
  2007-08-14 00:24:00 theanuradha [Reply | View]
  
  "baby IDE"

• Reified generics
  2007-08-13 09:45:58 simon_lebettre [Reply | View]
  
  - Reified generics

• Reified generics
  2007-08-13 07:23:30 crayzfishr [Reply | View]
  
  Reified generics get my vote.

• Annotation subtyping
  2007-08-13 05:51:01 martinstraus [Reply | View]
  
  There's no way to extend an annotation right now. This would be handy, IMO.

• JavaFx
  2007-08-13 04:49:47 obarks [Reply | View]
  
  inclusion of Java Fx scripts (compiled) in place of Java 2D code would be a nice feature !

• How about named parameters
  2007-08-13 00:34:43 drunken_wizard [Reply | View]
  
  I think 'named parameters' should be easy to do and is a nice feature to have!
• How about named parameters
  2007-08-13 08:43:22 dserodio [Reply | View]
  
  I'd like named parameters too, but it's not so easy to implement.
  There's an old Bug Parade report asking for named parameters, but it was closed as "wontfix" or something (I tried to search for it, but the bug database is currently down).

• Output and reference parameters may also be useful.
  2007-08-12 08:41:02 jmarine [Reply | View]
  
  I'm tired of using arrays of 1 object (and other types of holders), to return more than 1 result from java methods. Aren't you?
• Output and reference parameters may also be useful.
  2007-08-12 23:10:33 jwenting [Reply | View]
  
  -1 No, we're not tired of that. We've seen the disaster such things inevitably lead to.

• Verbatim string literals
  2007-08-12 05:46:23 joeys [Reply | View]
  
  Make it so much easier to embed regular expression, SQL and other scripting languages into java.
  This would improve readability allot.
• Verbatim string literals
  2007-08-13 05:39:09 chris_e_brown [Reply | View]
  
  

  Take a look at Groovy, it adds multiple approaches to writing strings, including the standard approach, and path / regex-friendly approaches. If you're creating a lot of classes like this, might be worth writing them in Groovy.

• Verbatim string literals
  2007-08-12 07:18:54 aberrant [Reply | View]
  
  I actually did a compiler modification to support this. It's really easy. Of course I used the back quote, which is considered in poor taste from what I hear. With all the focus on embedding scripting languages you would think this would be on the top of the list of low hanging fruit.
• Verbatim string literals
  2007-08-13 03:37:07 fuerte2 [Reply | View]
  
  Yeah, this should have been done like 10 years ago. But as Sun said: "This is yet another request for a syntactic sugar to save some user from
  typing. It's not worth it." They are sadistic, they want us to suffer.

• Fix Generics and stabilize the language !
  2007-08-12 04:12:19 aehrenr [Reply | View]
  
  The art of language specification is not to shove any thinkable feature in the language. And it is important that the language should be as stable as possible, what should change and improve are the APIs. The art is to include only features in a language that fit to the concept at hand. And the concept of Java was to have a simple core language and many APIs (and to be very portable). This was the reason of success for Java. There are hundreds of other languages available if one looks for different concepts. And don't forget: Python or Ruby and others where already available for a long time and they never had the prevalence of Java and they never will. The specification of generics was already a demonstration how NOT to design a language extension: Much too much complexity for very little gain. Fix this by using reified generics even when there might be slight incompatibilities.
  And don't supercharge the language: To be a good tool an average programmer must keep the whole language in mind. (I seldom met anyone who really knows the whole C++ language, this is very bad if you work in teams, because every programmer knows a different subset of the language and has a hard time to read the code of the others).
  If one wants to use many features I suggest to learn many languages! Look how goofy C# already looks! It is the next Ada or C++.
  Many of the proposed features are not good for a language that can be used for big projects and code that is maintained by many people. This was the reason to use Java and not because it had the same language constructs as Ruby, Python, C# or whatever.
  There is already a Java with closures and many cool and dynamic features. It is called Groovy. Instead of cluttering the Java language a better support for Groovy should be given. (And sync the syntax of homolog features e.g.. the foreach loop)
• Fix Generics and stabilize the language !
  2007-08-12 23:05:01 jwenting [Reply | View]
  
  +1 You put into words what I can't (at least nowhere near as well).

• Reified Generics
  2007-08-11 18:21:36 cowwoc [Reply | View]
  
  Fix Generics or remove them. Reification is the preferred route.
• Reified Generics
  2007-08-12 19:45:05 prunge [Reply | View]
  
  Agreed. +1 for reification of generics.

  I'd rather catch errors sooner rather than have a cast to List<String> silently succeed and fail possibly much later in an unrelated piece of code.

• Non-Null References by Default in Java
  2007-08-11 10:09:43 artti [Reply | View]
  
  http://users.encs.concordia.ca/~chalin/papers/2006-003.v3s-pub.pdf
• Non-Null References by Default in Java
  2007-08-12 07:07:03 aberrant [Reply | View]
  
  +1, sounds good.
• Non-Null References by Default in Java
  2007-08-11 16:36:26 jhannes [Reply | View]
  
  +1
• Non-Null References by Default in Java
  2007-08-13 08:37:12 dserodio [Reply | View]
  
  +1

• Explanation?
  2007-08-11 05:21:07 aberrant [Reply | View]
  
  Is there a place where these things are briefly explained? Besides closures and Properties I haven't herd much discussion about what they actually entail.
• Explanation?
  2007-08-12 23:04:10 jwenting [Reply | View]
  
  check out the language specs for overhyped languages. Everything's taken from somewhere else for no other reason than that (for example) "Ruby has it so it MUST be good".

• Minimize language changes
  2007-08-11 00:21:24 bharathch [Reply | View]
  
  And most importantly, please keep out hairball proposals like the BGGA closures. Thanks.

• Properties
  2007-08-10 13:20:18 mikaelgrev [Reply | View]
  
  Properties. Not because they should be easier to type, that is totally uninteresting, but so that we can finally get some good IDE support for a Collections of properties, for drilling into a complex property and a better way to listen for property changes.
  It would also mean that it would be much, much, much easier to write advanced components. This means that we can buy what we want off the shelf and not have to roll our own all the time.
  
• Properties
  2007-08-12 23:03:05 jwenting [Reply | View]
  
  I've used properties in Delphi. They're syntactic sugar only. Noone missed them when they weren't there and all they did was make the syntax of the language harder to understand for human readers. For the vast majority of users they're useless because they never work in the very limited scenario of creating components that need to be included in a visual GUI editor, for the few that might profit from them they're useless because those people are (or should be) highly experienced and proficient programmers already that don't need a dumbed down sugarcoated syntax to be able to do their job efficiently and proficiently.

• Not interested in suggested changes
  2007-08-10 13:08:50 mthornton [Reply | View]
  
  While not opposed to further language changes, none of those suggested here spark much enthusiasm in me. I would like to see immutable objects (with value semantics) and a VM that took advantage of them.
• Not interested in suggested changes
  2007-08-12 22:53:13 jwenting [Reply | View]
  
  +1 on your opinion of the laundry list of marketing induced language changes proposed for 7. If by "immutable objects" you mean compiler enforcement, sounds like a good plan as it would detect unplanned breaking of encapsulation in objects meant to be immutable (like direct setting of fields of other instances).

• Delegates
  2007-08-10 12:42:04 ossiejhmoore [Reply | View]
  
  Certainly a must have in modern languages.

• No closures!
  2007-08-10 10:34:39 dserodio [Reply | View]
  
  No closures in Java, please! Closures work great for dynamically-typed languages, not in statically-types ones.
  
  If you want Java with closures, just use Groovy!
• No closures!
  2007-08-15 08:55:52 heathm [Reply | View]
  
  The statement that closures only work well in dynamic languages makes me think that you don't really understand what closures have to offer.
  
  If you want to be convinced about closures, I think Neil Gafters presentation here is very convincing http://www.parleys.com/display/PARLEYS/An%20update%20on%20Java%20Closures
  
  Closures can be used to solve a lot of problems and can be used to greatly simplify code. Frankly I don't understand why so many people are so scared of them. So far the only arguments I've heard for not including closures have come from the ignorant that don't really understand what closures have to offer. Go educate yourself before speaking out against progress.
• No closures!
  2007-08-15 15:19:04 dserodio [Reply | View]
  
  Thanks for the link, I'll read it. But Java is today's programming lingua-franca; practically anyone can read Java code, and adding closures would make it less readable for less skilled programmers.
  
  Closures will probably make you more productive for the initial release, but take its toll at maintenance time. We should be after lowering maintenance costs, not decreasing time-to-market.
• Closures have nothing to do with dynamic languages
  2007-08-13 13:03:12 jhannes [Reply | View]
  
  Closures have nothing to do with dynamic languages, and everything to do with simpler, cleaner, safer code.
  
  Wouldn't you rather write this:
  

  read(new FileReader("foo.txt")) {
  
    |Reader reader|
  
    reader.read(); // etc
  
  } 

  
  
  Than:
  

  FileReader reader = null;
  
  try {
  
    reader = new FileReader("foo.txt");
  
    reader.read(); // etc
  
  } finally {
  
    // Verbose, tricky and error prone
  
    try {
  
        if (r != null) {
  
           r.close();
  
        }
  
    } catch (IOException ignore) {}
  
  }

  
  
  Or even:
  
  

  read(new FileReader("foo.txt"), 
  
    // Verbose and hard to understand
  
    new FileProcess() {
  
        public void doWithReader(Reader reader) {
  
            reader.read(); // etc
  
       }
  
  } );

  
  
  I don't know about you, but this is code that I write many times per day.
• Closures have nothing to do with dynamic languages
  2007-08-13 20:39:22 tompalmer [Reply | View]
  
  The "don't change anything fanboys" love to write hundreds of lines of boilerplate and assume that no one ever gets any of the redundancy wrong. Maybe it is time to leave Java behind. I'm just not convinced of what else to move to (and yes I know of Scala, Groovy, Ruby, Python, ES4, and lots of other stuff - nothing yet convinces me).
• Closures have nothing to do with dynamic languages
  2007-08-14 15:38:13 dhafenstein [Reply | View]
  
  We use IDE's to help us to handle all the tedious coding tasks. the IDE's today are unbeliveably powerful, and are a better solution to this problem.
  
  A programmers productivity and therefore cost to develop code is far better when using an IDE than when not. This is because IDE's can and do a lot for the programmer. Therefore, these issues are moot because they are not REAL problems that most developers face. If you are adding this feature so you can code using notepad, then get an IDE! Eclipse and NetBeans are really very good.
• Closures have nothing to do with dynamic languages
  2007-08-15 08:49:11 heathm [Reply | View]
  
  This is a stupid argument. Boilerplate code is still boilerplate code whether you're using an IDE or not. Yes the IDE can put the boilerplate code in there but you're still regurgitating the same code over and over and that code has to be maintained. Verbose reuse of boilerplate code (something very common in Java) is a problem that IDEs doen't solve.
  
  Closures cleanly fix the problem. Whether people want to admit it or not, Java needs closures. Java does not need closures because other languages have closures. On the contrary, Java needs closures because they solve real world problems and can drastically clean up your code.
• Closures have nothing to do with dynamic languages
  2007-08-14 08:40:01 aehrenr [Reply | View]
  
  So maybe Java isn't that bad :-)
  In the beginning I also thought that Java is to simlicistic until I realized that exactly this is its strength. I enables to write clear code that can be maintained and understood by other average programmers. Much less code review is needed when working in teams. I do not know wether this was intended by its inventors, but this is the main point of Java. Therefore I wish that they do not ruin Java by overloading the language. And call that even a progress. If you have a very smart day, write some Groovy code. It integrates seamless with your Java libs.
• Closures have nothing to do with dynamic languages
  2007-08-14 09:58:39 jhannes [Reply | View]
  
  Please look at the examples, aehrenr. This kind of boilerplate code can neither be "maintained or understood by average programmers."
  
  Java is a great language, but there are some very common things that require much too much code and that are much too error prone. Let's fix them!
• Closures have nothing to do with dynamic languages
  2007-08-15 08:56:54 heathm [Reply | View]
  
  +1
• Closures have nothing to do with dynamic languages
  2007-08-14 12:48:56 aehrenr [Reply | View]
  
  Your code shows the difficulties of a language extension very well: What to do with the required exception handling of Java, which I think is a very good thing? By the way there are much more elegant examples of closures. If you look only at the code without the exception handling there is not much difference, at least not much enough to change the language.
• Closures have nothing to do with dynamic languages
  2007-08-16 04:40:51 jhannes [Reply | View]
  
  Checked exception handling is a very popular feature, even though it is counter productive.
  
  Luckily enough to cluel^H^H^H programmers who like compiler checked exceptions, some of the variations of the closure proposals are fully compatible with forced exceptions. If you pardon my limited understanding of the exact syntax:
  
  

  
  
  void myFun()
  
    throws IOException // <-- Enforced by compiler
  
  { 
  
    read(new FileReader("foo.txt")) {
  
      |Reader reader|
  
      reader.read(); // <-- declared to throw IOException
  
      // This is allowed in the block and revealed in the
  
      // method scope, just as with a while-loop etc
  
    }
  
  } </code>

  

Isn't that all you wanted?

Sadly, checked exceptions forces the technical details of this to be very tricky, but the complexity all belongs to the compiler.
• Closures have nothing to do with dynamic languages
  2007-08-16 08:29:21 aehrenr [Reply | View]
  
  Isn't that all you wanted?

  Not quite. But it brings us to the point: The bad, bad boilerplate code in one example that should have been displaced with elegant closures encapsulated the reading from a file in a try-catch-finally clause. You must do exactly the same in your closure example to be functionally equivalent. My point simply was that in this example the closure would bring nothing to reduce boilerplate, the code you wanted to replace had exactly the same length.

  Usage of closures is often another style to formulate things and is only very hip this season. I use Groovy quite often so I know (and understand) good examples for elegant closure usage but the problem I have with their inclusion in Java is that you must not include every smart feature of some programming language in Java. This season it is closures last season it has been aspect oriented programming next season it will be ??... This would result in something that tries to please 1% of the programmers but would alienate Java from everyday programming which is its soul. It is important to keep in mind that Java is something like a sophisticated VB not a elitist language that can be used to formulate a problem in as few as possible lines od code.

  Checked exception handling is a very popular feature, even though it is counter productive A have completely the opposite opinion: They are not very popular but greatly increase productivity in larger projects because they formalize the reaction to error situations. In fact this was one of the main reasons for me to use Java. Only scripting languages for the short dirty hack should not have this feature in my opinion.

  Just a personal remark in the end: it is almost always wrong to think others are daffy and one belongs to the very few smart folks. If one thinks this it is often a sign that it is the other way around.

• Closures have nothing to do with dynamic languages
  2007-08-20 16:10:25 jhannes [Reply | View]
  
  You must do exactly the same in your closure example to be functionally equivalent. My point simply was that in this example the closure would bring nothing to reduce boilerplate, the code you wanted to replace had exactly the same length.

  Er.... what? Are you saying that I need to write my read() function? But of course. The point is how can you structure your code so that you can create better methods (or reuse better libraries). The encapsulated code is still there, of course. Just like with other functions. That can't be your argument? What don't I understand here?

  I do agree that there are features that can make the language too complex. I think we're also in agreement that AOP is probably one of these features. The thing that makes me nervous about AOP is that you don't see any evidence of them where they are applied, so the unknowledgeable programmer don't even know that they are there. The advantage of closures is that if you don't understand them, you're aware that there's something you don't understand where you need to know it. This is the same as anonymous inner classes. Would you favor getting rid of them, too?

  Unlike</stong> checked exceptions, closures is actually a well understood, tested, and implemented idea. It's not "only very hip this season".

  Sorry about the overly aggressive rhetoric about Checked Exceptions: I have seen a lot of code wrecked by them, and no code saved by them. So I get a bit aggressive when I talk to the people I feel are trying to wreck my software and make my life worse. You are of course entitled to your beliefs.

• No closures!
  2007-08-13 08:40:36 mikaelgrev [Reply | View]
  
  +1 They are great where they fit though...
• No closures!
  2007-08-13 06:09:23 strulli [Reply | View]
  
  Full ACK
• No closures!
  2007-08-13 05:33:15 chris_e_brown [Reply | View]
  
  Agree.

• Other change: Nice, easy layout
  2007-08-10 09:23:08 fredswartz [Reply | View]
  
  The single most useful change for beginning programmers would be a nice, simple, easy-to-use layout manager or container. There are nice grid layouts, or something driven from XML, or ...

  The answer is NOT the unreadable, locked-in NetBeans GUI editor for many reasons. It may be satisfactory in certain circumstances, but not as a general teaching tool.

• Other change: Nice, easy layout
  2007-08-10 12:10:07 atehrani [Reply | View]
  
  Why would a beginner learn to deal with layout managers without the use of tools, when professional developers use them day in day out?
  
  Seems like a backwards way of teaching to me.
  
  If you're doing UI design without a visual editor you must understand the consequences of doing so.
• Other change: Nice, easy layout
  2007-08-14 13:19:47 fredswartz [Reply | View]
  
  

  Beginners have few problems dealing with simple layout managers (FlowLayout, GridLayout, BorderLayout) . Sun's omission of an easy-to-use grid-based layout means that no beginning textbook can make attractive user interfaces, which is a massive missed opportunity in promoting Java, as well as making a number of user interfaces look crappy. Getting textbook writers to promote NetBeans is just not going to happen, even if Sun would allow it to be bundled with textbooks (which I've heard it doesn't).

  A visual GUI editor may be a good choice in the future, but only if it's open source (reduces future risk and vendor lockin) and can easily be used with all IDEs (avoids lockin). Until this utopian editor arrives, a simple grid-based layout would be most welcome in the present-day world.

• Other change: Nice, easy layout
  2007-08-10 19:27:08 aberrant [Reply | View]
  
  If you're doing UI design with a visual editor you must understand the consequences of doing so.
  I've had first had experience. JBuilder 2007 will not let you visually design anything created in JBuilder 2006 and lower. So al the people who had cioded theit GUI the "easy" way now have to maintain them by hand. Lock in is bad. BAD BAD BAD.
  
• Other change: Nice, easy layout
  2007-08-13 04:25:17 jwenting [Reply | View]
  
  "visual" editors have their place, but that place is mainly (or should be) reserved for prototyping. And IMO the language shouldn't be changed just to make it a bit easier for someone to write tools that are useful mainly for creating throwaway prototypes. But of course Sun is going out of their way to push us all into locking ourselves into Netbeans every which way, so I think that one is a given as it makes it even easier for them to make things which are Netbeans dependent.

• leave well enough alone
  2007-08-10 07:11:45 jwenting [Reply | View]
  
  For Java 7, lets just get rid of the marketing team that drives the language development and take the chance to actually get rid of a lot of garbage. Things like StringTokenizer, Vector, and everything deprecated.

  And get rid of all the idiots proposing to add everything and the kitchen sink to the language "because Ruby has it" (or insert someone's favourite language) which is all the reason anyone's ever really come up with for such idiocies as closures, operator overloading, properties, multiple inheritance, embedded SOAP stacks and database servers, and just about everything else added since 1.4

• leave well enough alone
  2007-08-20 16:14:38 jhannes [Reply | View]
  
  For Java 7, lets just get rid of the marketing team that drives the language development and take the chance to actually get rid of a lot of garbage. How about throwing out the new for-loop and synchronized blocks and replacing them with closures (which can do the same and more)

  I would like to suggest doing the same to the while-loop and if-block, too, but then I think people would just start throwing things at me. ;-)

• leave well enough alone
  2007-08-13 08:51:56 iphillips [Reply | View]
  
  +1

  Java 7 should be seen as the next real opportunity to streamline the language and shave off some of the cruft that has built up over the years.

• leave well enough alone
  2007-08-11 07:37:23 cajo [Reply | View]
  
  +1
• leave well enough alone
  2007-08-11 08:10:08 cajo [Reply | View]
  
  The language spec is rapidly turning into a repeat of PL/1: I.e. 99% of the people use 80% of the spec, whilst the other 1% push for the the other 20%; which genuinely offers no new functionality, rather serves primarily to intimidate new adopters.
  
  E.g.: When I see constructs such as:
  
  

  if (boolean.class.equals(x)) {...

  
  
  My blood just boils!
  
  To juxtapose a familiar aphorism:
  
  

  Just because it's legal, doesn't make it right.

  
  
  John
  
  
  
  
  
  
  
  
  
  
  
  
• leave well enough alone
  2007-08-11 22:42:59 tackline [Reply | View]
  
  

  Yeah, the right way to do it is:

  if (boolean.class == x) {

• leave well enough alone
  2007-08-10 12:22:06 aehrenr [Reply | View]
  
  +1
• leave well enough alone
  2007-08-10 10:30:07 davidrupp [Reply | View]
  
  +1.
• leave well enough alone
  2007-08-11 05:27:10 dwalend [Reply | View]
  
  Maybe some cleanup of the mess we've got now, before adding more.

• something else
  2007-08-10 06:08:08 sasdav [Reply | View]
  
  A direct way to read a java.sql.Date value from a ResultSet and convert it to a java.util.Date object.
  
  and vice versa
• something else
  2007-08-10 19:37:57 aberrant [Reply | View]
  
  Wait .. isn't java.sql.Date a decendant of java.util.Date?

  http://java.sun.com/javase/6/docs/api/
  Why do you need to convert them?
  

• something else
  2007-08-10 19:32:35 aberrant [Reply | View]
  
  Sorry, wrong link...
  
  http://java.sun.com/javase/6/docs/api/java/sql/Date.html
• something else
  2007-08-10 07:02:43 invalidname [Reply | View]
  
  That would be an API feature request, not a language change.
• something else
  2007-08-13 04:12:48 jwenting [Reply | View]
  
  a feature request for something that's already been featured since JDBC 1.0 :)