What did you think of this first installment, and what would you like David to cover next time?

Showing messages 1 through 31 of 31.

• good article
  2008-04-21 23:28:10 wiliam6 [Reply | View]
  
  Pass4Sure is your source for the Comptia A+ exam. With our IBM Certification Exam Resources, you can be rest assured that you will Pass your MBS Exam on Your First Try. Our Exams are written and formatted by Top senior IT Professionals working http://www.pass4sure.com/Microsoft-Business-Solutions.htmlin today's prospering companies and data centers. All of our practice exams including the MBS exam guarantee you success on your First Try.
  You will find the great selection of silver Pendants at Tiffany Jewelry Store. All our silver tiffany pendants are stamped with a fineness mark of "925" or "Sterling" or "Ster" to indicate silver purity. Moreover, the tiffany pendant are crafted with the quality of being beautiful and delicate in appearance, and they are inspected for a fineness mark to ensure quality.
  

• inflatables
  2008-04-21 23:21:43 wiliam6 [Reply | View]
  
  Our main manufacture include: Inflatable Bouncers, Inflatable Castle, Inflatable Games, and much, much more! Our products are a great affordable choice and are designed for all age groups. Many of the kid's pools will double as ball pits and are fine for indoor play during winter or stormy days. Our Inflatable Toys are a wonderful alternative to those hard bleachers at the little league games and provide an elevated vantage when watching the kids at the beach. The scuba accessories and pool floats are just the thing for little swimmers and big ones alike. Explore the pages of our site for your gift giving ideas!

• Re: Currency
  2008-04-04 05:07:56 cat [Reply | View]
  
  In my opinion, a few cosmetic changes to java.util.Currency are not enough. And after meeting with a lot of fellow JCP members at QCon I am not the only one sharing it.
  
  Similar to JSR-310's approach towards Date and Calendar there should be a true type and value support for a real Monetary Unit. Not just a few cosmetic changes to the already cosmetic Currency class.
  
  The fact that this class and its native OS support are often faulty became obvious, when I just created a Spring based showcase for JSR-275 and an experimental, but fairly succesful Money and Stock Market example based on it.
  While the JSP tags using Currency badly failed and ended up showing only "?" or similar placeholders on many systems (such as Mac) the JSR-275 based one worked fine in all cases.

• Groovy style of String expression
  2007-12-25 22:14:07 jianwu_chen [Reply | View]
  
  String literal in groovy is a big advantage compare to Java. So one of my big wish is Java can add support of groovy style of string expression:
  
  1. Multi-Line Strings :
  Instead of : “abc” + “\ndef” + “\nghi”, we can simply put:
  “””
  Abcdefghi
  “””
  
  2. Shortcut to embedded variable in String
  Such as “Hello $name” instead of “Hello” + name.
  
  I believe these changes won’t affect much in deep of the language, just the change of the source code parser. But this has great benefit for producing cleaner code.

• what i think on Java 7
  2007-11-22 19:05:53 fachim [Reply | View]
  
  Supporting dynamic language such as Groovy, BeanScript and Jython is good, server side programming become litle bit interesting and live!
  
  Including Java Persistance API into Java SE is perfect! Simplify desktop development from complicated vendor dependent SQL.
  
  Hey you give me such a happiness, I can put String in switch statement, that's cool. I dont like C/C++ style switch that Java adopted so far.
  
  Simplification of JavaBeans properties, setter and getter is fantastic, its really helpful for server side and put it in JSP. Cleaner and simple code. But how about including XML in language is not a goodd idea, language would not as simple anymore.
  
  Last, I dont understand regarding Fork/Join framework but I knew Java best in virtualization, programmer just take a concern on their application development, dont bother about hardware and its complicated architecture. But why we include those complicated hardware architecture into high level programming practise?
  
  
  regards,
  
  fachim

• === operator
  2007-09-20 12:04:26 fast40x [Reply | View]
  
  Is there any chance we'll get === operator?
  before: LHS === RHS
  after: (LHS == null) ?false:LHS.equals(RHS)
  
  If only one operand is a primitive, then the primitive should get autoboxed. If both operands are primitives, then the operator should act like ==.

• Language-level XML support
  2007-08-29 01:18:02 scnnrc [Reply | View]
  
  The only feature that i dislike is the Language-level XML support ,it taints the language with something that it is external to it. What if in 5 years we won"t be using XML anymore?
• Language-level XML support
  2007-12-25 21:59:44 jianwu_chen [Reply | View]
  
  I agree on this point. XML is not something worth to be integrated into a language. It’s not well designed in the beginning from software design point of view. Except big companies support it, I don't think many developers like it after intensively using it. Now a lot of companies have realize the issues with XML (XSLT especially) and move away from XML hell after waste large amount of money. In my opinion, XML will become legacy technology in the near future. People will only use it because the old system needs it. Hope it won't pollute a pure, neat language like java.
  
  Actually we can learn some ideas from groovy builder. Which supports generic tree like hierachy structure build in the language level. But don't need to be specific for XML. XML should just be one use case of this generic builder mechanism.

• Refreshing
  2007-08-28 21:10:20 kyenos [Reply | View]
  
  Honestly, it's refreshing to see it all in a nutshell, instead of deciphering a JSR. Thanks for the great overview. I spent 3 hours trying to figure out what was in java 7 as opposed to what's proposed. In the end it took 10 minutes to read your post, and I feel up to date...
  
  Thanks!

• naive feature suggestion
  2007-08-26 17:24:54 surfer66 [Reply | View]
  
  Im sure this is not the proper way to suggest a new feature but how about improved Exception handling.
  
  try {
  
  // some code here
  
  }
  catch(FileNotFoundException, IOException e) {
  
  // handle either exception here
  
  }
  catch(Exception e) {
  
  // handle any other exception here
  
  }
• naive feature suggestion
  2007-09-07 14:05:08 paipiski [Reply | View]
  
  Yeah, this is very important and now Java supports dynamic arguments to the function so all the other exceptions can be passed as array except the "Exception".
• naive feature suggestion
  2007-08-29 09:48:45 bostx [Reply | View]
  
  +1

• New features .. yes and no.
  2007-08-15 23:51:12 melbeltagy [Reply | View]
  
  or me, I am not sure if adding new major language changes to Java is a pretty good idea or not. But a general idea is that I totally agree with one of the replies who specifically said:"The reason of success for Java was that it was a simple language that can easily be kept in mind, but was powerful enough to get most jobs done.".
  Any way, this is what I think in details:
  
• Language-level XML support : why adding new features that would tide the language to something else other than Java (like we did with Java and Expression Language (EL)). IMHO, I think the way Java community did with the Scripting project (JSR 223) is a much better way of using other things than Java inside Java. It makes it very easy to use, and still have a very high way of abstraction and isolation of dependencies between Java and others, even if it was XML. The reason why I am saying this is because to add XML support you will need to add support for a lot of XML-related technologies. We do have some of them already in the JDK XML packages and classes implementations. But why add them to the Java syntax.


• Closures : I am not sure what closures are. But when I read about it, the first impression I had is that its syntax is complicated.


• Block constructs : don't know.


• Strings in switch statements : Yes. I think it is a very useful feature.


• Language support for BigDecimal : I am not sure what is the feature in this.


• Java property support : I have read a long article discussing this feature right here. And to tell you the truth, my final conclusion is that IT WILL depend actually on how they propose it. I find it very useful, but it really needs to be easy to use.


• Lightweight method references: Not sure what is the meaning of this.


• Extensions to the annotation mechanisms: Yes (if it means annotations inheritance).


Well, one thing I like though and I really hope it would make it to Java 7, the Measures and Units project (JSR 275). I think it is a good thing to have in Java and I think it is something that should have been there along time ago.
• New features .. yes and no.
  2007-08-15 23:46:40 melbeltagy [Reply | View]
  
  ... sorry, i did not know that (li) tag would look like a new comment... :(

• Block constructs?
  2007-08-15 18:51:44 firefight [Reply | View]
  
  What changes are proposed under "Block Constructs"?
  
  I imagine something like Ada and PL/SQL where you can have blocks nested arbitrarily with their own scope and function declarations:
  
  PROCEDURE foo IS
  var NUMBER;
  PROCEDURE bar IS
  .. and so on..
  BEGIN ...
  END;
  BEGIN
  bar();
  END;
• Block constructs?
  2007-08-16 06:29:26 jwenting [Reply | View]
  
  iow an invitation to spaghetti code... Nested methods?

  Well, they're of course a natural result of "closures" which are really nested anonymous methods and function pointers so if you add one you end up opening the floodgates to add the other as well.

  And people're thinking "closures" are a good idea because they make inner classes (which they think are ugly) superfluous (in their mind)...

• Please NOT!
  2007-08-14 05:33:04 linuxhippy [Reply | View]
  
  Please ... the language changes in Java5 already showed how bad later introduced language features can be - please don't do the same for Java-7.
  
  Son't destroy the language just because of the we-too effect.
  
  Wait 10 years and watch what will happen to C#/VB.NET with tons of high-level features only a few developers need.
  Its the same as with C++, just on another level.
  
  lg Clemens
• Please NOT!
  2007-12-25 22:17:33 jianwu_chen [Reply | View]
  
  I don't agree. The language should evolve as long as we take control of the evolution so it will continues improve but still keep it simple. Otherwise, the language will soon be outdated.
  
  For Java5 features, we have already got a lot of benefits from it in our real life projects. The code in Java5 is much cleaner compare to old version.
• Please NOT!
  2007-08-15 18:53:25 firefight [Reply | View]
  
  As someone who codes in Java day in and day in Java I loved the changes release 5!!!
• Please NOT!
  2007-08-17 00:10:57 jwenting [Reply | View]
  
  Generics and autoboxing are nice, though the implementation might have been better in places. Annotations I've never much cared for and again could have been better thought out (I especially miss inheritance of applied annotations to derived classes). Enums are good.

• Java Me2!
  2007-08-09 23:41:48 jwenting [Reply | View]
  
  Let's just call it Java Me2! in "celebration" of adding everything but the kitchen sink that any currently hyped language has without any consideration whatsoever of the consequences or usefulness.
• Java Me2!
  2007-08-13 14:45:10 aehrenr [Reply | View]
  
  +1
  You will ruin Java when every pet feature is going to be included in the language.
  Instead give better support for Groovy. It has many cool features and should be the dynamic companion of Java.
  But do not supercharge the Java language. The reason of success for Java was that it was a simple language that can easily be kept in mind, but was powerful enough to get most jobs done. The code was almost self documenting. Now look at the famous:
  Enum< E extends Enum<E>> {...}
  Because of code like this many developers left C++
• Java Me2!
  2007-08-10 13:44:31 alski [Reply | View]
  
  I couldn't agree more. The only thing I would suggest is possibly extending annotations. It's a way of generically extending the usefulness of the language without polluting it. I would perhaps agree with people that want better introspection on typed collections but I'd argue that that could be done as an annotation too rather than deep in the bowels of the language.

• What about reified generics?
  2007-08-09 08:35:51 crayzfishr [Reply | View]
  
  Are reified generics being considered for Java 7?
  
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5098163
• What about reified generics?
  2007-08-10 09:37:46 davidflanagan [Reply | View]
  
  I don't have any inside knowledge about this. Reified generics are certainly a feature that gets talked about outside of Sun. Maybe not as much as closures, but certainly people are thinking about it. But a look at the calendar and the intended release date of Java 7 should make you skeptical whether such a significant language change could be developed in time.
• What about reified generics?
  2007-08-09 23:45:39 jwenting [Reply | View]
  
  let's just leave well enough alone and don't change something that works just because someone doesn't consider it theoretically beautiful.

  Let's not twiddle with the backwards compatibility of the classfile format. This "proposal" would destroy the capability of running any classfiles compiled to earlier language standards against a JVM implementing it. While not as bad as the flood of senseless new "features" being put forward that will no doubt make it for the sole reason that they look nice to marketing flunkies, it's not the way to go.

• What about reified generics?
  2007-08-11 10:04:14 artti [Reply | View]
  
  > This "proposal" would destroy the capability of running
  > any classfiles compiled to earlier language standards
  > against a JVM implementing it.
  
  I'm not a JVM expert myself, but I find it really hard to believe that there isn't a way to make this change so that older class files could be run with the new JVM also.
  
  Could you elaborate, why would this particular change cripple the new JVM as you mentioned?
• What about reified generics?
  2007-08-12 23:06:44 jwenting [Reply | View]
  
  The old classes wouldn't have the information, so the new JVM wouldn't know what class they were. You'd end up with untyped objects floating around, and suddenly having methods called on them that are part of some specific object without having any cast performed beforehand.
• What about reified generics?
  2007-08-13 10:03:54 artti [Reply | View]
  
  I thought that the main problem is in generic types that are defined "runtime":
  
  new ArrayList<String>()
  
  Hope that renders correctly. Classes that implement generic classes do have generic types already available runtime:
  
  http://www.artima.com/weblogs/viewpost.jsp?thread=208860
  
  It just should be much easier to get to those types.
  
  Runtime generic types compiled with older JDKs should be treated as Objects just like they are currently; nothing changes.
  
  You might end up with an old code that seems to have plain classes with Object generic types, but thats what you have currently anyway?
• What about reified generics?
  2007-08-13 21:56:50 jwenting [Reply | View]
  
  problem is that those old classes would now all bristle with ClassCastExceptions if it's suddenly assumed that the actual type information is correctly supplied at runtime but they're instead hard cast to Object. That doesn't currently happen as the actual type is determined at compilation and used instead.
• What about reified generics?
  2007-08-28 14:36:07 cowwoc [Reply | View]
  
  Sorry jwenting, I don't see it. Can you please supply some sample code that would result in a ClassCastException if we introduced Reified Generics?