Home

News: Java Futures at JavaOne

  1. Java Futures at JavaOne (46 messages)

    Day 3 of JavaOne had Graham Hamilton, VP and Sun Fellow of Sun Microsystems, present on Java futures and Dolphin (Real Audio needed). The 20 minute talk, available at the JavaOne website, described a number of new features that are being discussed for inclusion in Dolphin. There were two points that Graham wanted to be clear on. They wanted to be very cautious about changing the language. Though they have had many interesting suggestions, they needed to be cautious in how they changed the language.
    We want better performance, not going to give up on stability, robustness, compatibility, and push to improve on monitoring and management.
    One of the features currently not on the table is operator overloading. This controversial feature may offer benefits but are these benefits worth the risk? Though Graham was polite about the subject it was clear that he didn’t think so. So just what is on the table? The first item up for discussion was XML literals. The follow code was taken from an supporting slide.
    XML speaker = { mark } ; XML talk = { speaker } { “XML in Java” } { “Wednesday 1:30pm” } ;
    Included in the talk was a discussion of super packages. A super package is a different way to organize your application. It is being designed with support for large application in mind. In particular, super package should fill requirements that currently cannot be meet with the Java ARchive (JAR) standard. That requirement is to provide extra package level scoping that will allow one to hide all the API classes for a particular module. API classes will need to be explicity named before one can use them from another module. There will also be support for versioning and dependency mappings. Super packages will be supported both in language and runtime. Other features included;
    • a new byte code to support the invocation of methods in dynamic languages
    • lightweight method references for GUI event handlers Bean bindings
    • More Java2D expect more hardware acceleration
    • Better support for scripting languages
    • Beanshell seems like a good candidate to be included into Dolphin
    Other languages to be supported are VisualBasic and JavaScript in the web tier. It is expected that you will be able to write a Servlet in JavaScript. However don’t expect to be running your VB application in the JVM anytime soon. While support will exist, the support will not clone the windows platform. However you will be able to call VB from Java and Java from VB. The next question is, when will we be seeing a JSR in the JCP to cover all of this activity?

    Threaded Messages (46)

  2. Re: Java Futures at JavaONE[ Go to top ]

    One of the features currently not on the table is operator overloading. This controversial feature may offer benefits but are these benefits worth the risk?
    Although I am not after general operator overloading, what would be great is to allow math operators to be more widely used to improve code clarity. I want to be able to code a = b + c; where a, b, and c are java.lang.Math subclasses. I can't see any objection to this, but am I wrong? Why should this be a problem?
  3. Operator Overloading History[ Go to top ]

    The experience from C++ is that operator overloading is fine for the easy case of math operations, as you've cited. The problem comes about when people overload operators in less intuitive ways (e.g., making the "dot" operator do odd things). The original Java development decided that operator overloading was one of those C++ features that would be jettisoned for the sake of ease of use. The math operator argument comes up again and again, but that cautionary tale of less intuitive overloads still remains. %
  4. Also one of the big problems with C++ is when you combined features like operator overloading, templates, and multiple inheritence the whole thing became a tangled mess. The one thing I like about Java is it is simple. I am still considering if the inclusion of Generics was worth it when you get to how it works with inheritence.
  5. The experience from C++ is that operator overloading is fine for the easy case of math operations, as you've cited.

    The problem comes about when people overload operators in less intuitive ways (e.g., making the "dot" operator do odd things).

    The original Java development decided that operator overloading was one of those C++ features that would be jettisoned for the sake of ease of use.

    The math operator argument comes up again and again, but that cautionary tale of less intuitive overloads still remains.

    %
    Exactly, which is why I am not after general operator overloading. I am after an extension of Java syntax. I don't consider having to use methods like .add and .subtract for data types that are pretty vital for financial logic as easy to use. It makes more sense to allow '+' for BigDecimal than for String.
  6. The problem comes about when people overload operators in less intuitive ways (e.g., making the "dot" operator do odd things).
    You can't overload the dot operator. http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.5 Overloading the arrow operator is required for making smart pointers. But yes, misused it can make for some really confusing code.
  7. Re: Java Futures at JavaONE[ Go to top ]

    The first problem is the java.lang.Math is final :).
  8. Visual Basic?[ Go to top ]

    Why in the world do we want VB support?
  9. Re: Visual Basic?[ Go to top ]

    Totally agree... is there a serious need for Visual Basic or JavaScript support? What are the benefits of any scripting language support, I'd really like to hear the argument for this.
  10. Operator Overloading[ Go to top ]

    One of the features currently not on the table is operator overloading. This controversial feature may offer benefits but are these benefits worth the risk?


    Although I am not after general operator overloading, what would be great is to allow math operators to be more widely used to improve code clarity.

    I want to be able to code

    a = b + c;

    where a, b, and c are java.lang.Math subclasses. I can't see any objection to this, but am I wrong? Why should this be a problem?
    How about: public interface Addable { T add(T arg); T subtract(T arg); } public interface Multipliable extends Addable { T multiply(T arg); } public interface Divideable extends Multipliable { T divide(T arg); T mod(T arg); } ...and do something similar for the logical operators. This would be consistent with how the new for loop construct can be used with any class that implements Iterable. It would also be more general that forcing extension/implementation of a "Numeric" class/interface, because T could be a class representing an Expression, so you could build expression trees using the overloaded operators.
  11. Re: Operator Overloading[ Go to top ]

    ...and do something similar for the logical operators. This would be consistent with how the new for loop construct can be used with any class that implements Iterable.
    It would also be great if you could use the relational operators with objects that implement Comparable. It's much clearer to write a < b</code> rather than a.compareTo(b) < 0</code>
  12. While we're at it, one additional situation where operator overloading makes sense is for the [] operator and collections. These days its practically not 'overloading' anymore, since almost nobody is using native arrays anymore and therefor the [] is virtually banned from all practical code. Like all others say, we're not asking for generic operator overloading but just for the application of operators to a few well know and understood cases. To sum up, these are: + for String concatenation + / - * % for Numeric math operations [] for Collection access (: for Collection iteration) We already have the first and last one (not sure if : in the enhanced for loop counts as overloading though). Why can't we have the two other cases?
  13. Re: Operator Overloading[ Go to top ]

    Like all others say, we're not asking for generic operator overloading but just for the application of operators to a few well know and understood cases. To sum up, these are: + for String concatenation + / - * % for Numeric math operations [] for Collection access (: for Collection iteration)
    And I'm sure we can find some other uses that aren't brain-damaged if we think hard. Behind the "I hate operator overloading", you all are really saying just put it in. Just fire the numbskulls that abuse it for Pete's sake.
  14. Re: Operator Overloading[ Go to top ]

    Behind the "I hate operator overloading", you all are really saying just put it in.
    My personal requirement for the extended use of operators is clear and restricted: allow use of math operators for math classes. Nothing more. I am not really saying anything else.
    Just fire the numbskulls that abuse it for Pete's sake.
    Unless developers are micro-managed, a considerable amount of bad development has to be dealt with retrospectively. Far better to prevent numskulls from doing the damage in the first place.
  15. Re: Operator Overloading[ Go to top ]

    My personal requirement for the extended use of operators is clear and restricted: allow use of math operators for math classes. Nothing more. I am not really saying anything else.
    Oops, but others are addding to your list, and they all sound pretty reasonable.
    Unless developers are micro-managed, a considerable amount of bad development has to be dealt with retrospectively. Far better to prevent numskulls from doing the damage in the first place.
    Have you ever heard of a code review? And once again Steve, you're not going to prevent numbskulls from writing bad code just because you don't have operator overloading. But it was interesting watching the operator overloading subthread develop. First, you bring up operators for Math functions, then someone else brings up some other reasonable uses, and another poster some more. "Oh, but we still don't want operator overloading". Nice.
  16. Re: Operator Overloading[ Go to top ]

    My personal requirement for the extended use of operators is clear and restricted: allow use of math operators for math classes. Nothing more. I am not really saying anything else.


    Oops, but others are addding to your list, and they all sound pretty reasonable.
    Perhaps they do to you.
    Have you ever heard of a code review?
    I have. But not everyone lives in a ideal world. Many people have to deal with legacy code that has not been developed in ideal circumstances; code that may be years old.
    And once again Steve, you're not going to prevent numbskulls from writing bad code just because you don't have operator overloading.
    True, but the experience of decades of language design is that it can help. People aren't resistant to operator overloading out of stubborness - they have reasons.
    First, you bring up operators for Math functions, then someone else brings up some other reasonable uses, and another poster some more.

    "Oh, but we still don't want operator overloading". Nice.
    Sorry, but this is in no way an argument for operator overloading, as you keep insisting it is. We are having a debate about possible syntax extensions.
  17. Re: Operator Overloading[ Go to top ]

    Have you ever heard of a code review? I have. But not everyone lives in a ideal world. Many people have to deal with legacy code that has not been developed in ideal circumstances; code that may be years old.
    And that's supposed to be an argument against operator overloading - because legacy code exists?
    And once again Steve, you're not going to prevent numbskulls from writing bad code just because you don't have operator overloading. True, but the experience of decades of language design is that it can help. People aren't resistant to operator overloading out of stubborness - they have reasons.
    No, there is no language design authority who claims that removing operator overloading can help. Are Sun's reasons for not overloading operators for Math valid to you? Why is + overloaded for String?
    Sorry, but this is in no way an argument for operator overloading, as you keep insisting it is. We are having a debate about possible syntax extensions.
    You can speak for yourself, but not we. I just noticed that we can add properties to the list of suggestions for operator overloading. But I'm curious Steve, how does your Math-only syntax extension actually work? Does the compiler know about the Math class explicitly and so it's special? Does the Math class get the final modifier removed so that you can subclass it and say implement operators on a Matrix or Vector class? And if Sun open sources Java like they say they are going to do (they just "dont't how to do it"), then all bets are off. But I don't think you can suddenly say, "well, let's just make the Math class special, but don't let anybody else monkey around with operator overloading."
  18. Re: Operator Overloading[ Go to top ]

    And that's supposed to be an argument against operator overloading - because legacy code exists?
    In a way. Legacy code (in my experience) reveals that the ideal practices of how code should be developed are often not implemented. The design of Java was based on real experience of how code is actually developed, not how many of us believe that code should be developed. Java is, in my view, a good language for the real world.
    You can speak for yourself, but not we.
    You are doing that, by implying that what we actually want is general operator overloading.
    But I'm curious Steve, how does your Math-only syntax extension actually work? Does the compiler know about the Math class explicitly and so it's special?
    Not the Math class - the java.math classes (BigDecimal and BigInteger). Yes, the compiler should know about these classes explicitly and knows that they are special. It knows this for String, so it can know this for these classes.
    Does the Math class get the final modifier removed so that you can subclass it and say implement operators on a Matrix or Vector class?
    Not up to me. I'll leave that for others to debate. Each of these potential syntax extensions has their own merits and disadvantages.
    And if Sun open sources Java like they say they are going to do (they just "dont't how to do it"), then all bets are off.
    No, they aren't. Java is still subject to certification, and if others mess about with syntax and java.* classes, the result isn't 'Java'.
    But I don't think you can suddenly say, "well, let's just make the Math class special, but don't let anybody else monkey around with operator overloading."
    Apart from the fact that I am not asking to make the 'Math' class special - (I am asking for java.math classes to be 'special'). I think I say exactly that, suddenly or not. There is no reason why this could not be implemented without allowing general operator overloading.
  19. Re: Operator Overloading[ Go to top ]

    In a way. Legacy code (in my experience) reveals that the ideal practices of how code should be developed are often not implemented. The design of Java was based on real experience of how code is actually developed, not how many of us believe that code should be developed.
    That "real" experience is the experience of programmers that aren't suddenly privy to some bit of info that many others aren't aware of. I'm not buying your appeal to some abstract Java authority. Java was first developed for settop boxes. Nobody knew that Java would be the workhorse of serving up web pages.
    Java is, in my view, a good language for the real world.
    Yes, it's proven itself, as have many other languages that have operator overloading.
    You are doing that, by implying that what we actually want is general operator overloading.
    Actually, the posts on the thread are pointing to that. You want java.math, somebody else wants something else, and we have overloading on String right now.
    Not the Math class - the java.math classes (BigDecimal and BigInteger). Yes, the compiler should know about these classes explicitly and knows that they are special. It knows this for String, so it can know this for these classes.
    So what do you do - have a big vote on what classes should be special to the compiler?
    No, they aren't. Java is still subject to certification, and if others mess about with syntax and java.* classes, the result isn't 'Java
    What's in a name? IBM/Apache can call it Jolt. The difference is that if Java is open sourced they can get a big code dump and be able to redistribute it.
    Apart from the fact that I am not asking to make the 'Math' class special - (I am asking for java.math classes to be 'special'). I think I say exactly that, suddenly or not. There is no reason why this could not be implemented without allowing general operator overloading.
    I think it's all or nothing. I don't think java.math classes will be special - ever.
  20. Re: Operator Overloading[ Go to top ]

    That "real" experience is the experience of programmers that aren't suddenly privy to some bit of info that many others aren't aware of. I'm not buying your appeal to some abstract Java authority.
    It isn't abstract or Java. There has been an on-going debate about this for decades. The knowledge of how operator overloading can cause problems is widely known.
    Yes, it's proven itself, as have many other languages that have operator overloading.
    No, they haven't. The mess that you can get into with languages like C++ where this is allowed is well established. In this respect (and many others), C++ often proves itself less capable as a robust development language. Part of Java design was to excluse some of the mistakes of C++.
    Actually, the posts on the thread are pointing to that.
    No, that is simply your interpretation.
    You want java.math, somebody else wants something else, and we have overloading on String right now.
    That is overloading of an operator by extending the syntaxt, not allowing a developer to do it. This was done for String because it was also present in popular languages like Pascal.
    So what do you do - have a big vote on what classes should be special to the compiler?
    Yes, within the JCP.
    No, they aren't. Java is still subject to certification, and if others mess about with syntax and java.* classes, the result isn't 'Java


    What's in a name? In terms of Java, a LOT.
    IBM/Apache can call it Jolt. The difference is that if Java is open sourced they can get a big code dump and be able to redistribute it.
    Sun's Java being open source is irrelevant to this. Any group could make a similar language right now and call it what they like.
    I think it's all or nothing. I don't think java.math classes will be special - ever.
    I see no reason for this. They are java.math classes after all.
  21. Re: Operator Overloading[ Go to top ]

    It isn't abstract or Java. There has been an on-going debate about this for decades. The knowledge of how operator overloading can cause problems is widely known.
    The knowledge that some people that don't know what their doing and using operator overloading can cause problems. And these same people will cause problems whether there is operator overloading or not.
    No, they haven't. The mess that you can get into with languages like C++ where this is allowed is well established. In this respect (and many others), C++ often proves itself less capable as a robust development language. Part of Java design was to excluse some of the mistakes of C++.
    Saying that Java is more robust than C++ is pretty much a joke.
    No, that is simply your interpretation.
    And the interpretation is that others want operator overloading besides the Math classes.
    That is overloading of an operator by extending the syntaxt, not allowing a developer to do it. This was done for String because it was also present in popular languages like Pascal.
    I'm sure Pascal does lots of things that Java didn't copy. Sorry, no excuse. String should just have an add() to be consistent.
    What's in a name? In terms of Java, a LOT.
    Meaningless
    Sun's Java being open source is irrelevant to this. Any group could make a similar language right now and call it what they like.
    Not after Sun drops a big code dump that anybody can use it won't be.
    I see no reason for this. They are java.math classes after all.
    And other people in the thread want the syntax changed in other ways that make sense. But my question is why do you have such a poor opinion of Java programmers? To you, they're all a bunch of idiots that will turn code into a nightmare if operator overloading is introduced.
  22. Re: Operator Overloading[ Go to top ]

    The knowledge that some people that don't know what their doing and using operator overloading can cause problems. And these same people will cause problems whether there is operator overloading or not.
    That doesn't make sense at all. Give people less ways to cause problems and they will cause less problems.
    I'm sure Pascal does lots of things that Java didn't copy. Sorry, no excuse. String should just have an add() to be consistent.
    I agree. Take '+' away from String and give it to classes where it is more appropriate.
    What's in a name?

    In terms of Java, a LOT.


    Meaningless.
    My experience is that developers know what Java is and what it means. Java has become a byword for compatibility.
    Sun's Java being open source is irrelevant to this. Any group could make a similar language right now and call it what they like.


    Not after Sun drops a big code dump that anybody can use it won't be.
    My view is that if some version of that code doesn't pass the compatibility tests, it won't be widely adopted. So much development relies on Java compatibility that developers won't trust non-certified versions for major projects.
    I see no reason for this. They are java.math classes after all.


    And other people in the thread want the syntax changed in other ways that make sense.

    But my question is why do you have such a poor opinion of Java programmers? To you, they're all a bunch of idiots that will turn code into a nightmare if operator overloading is introduced.
    No, you misunderstand me. I have a poor opinion of programmers in general (including myself). I am sure there are some awesome developers who don't make mistakes and always write clear code that they can come back to in a decade and instantly recall what I meant, no matter what clever tricks I use. You may be such a high-quality developer. I admit that I am not. I feel safe with the protection of a language designed to protect me from my own mistakes. Why do I have this view? Because I have had decades of experience of looking at code from other developers. This has led me to think that having such safety for general development is a good thing.
  23. Re: Operator Overloading[ Go to top ]

    That doesn't make sense at all. Give people less ways to cause problems and they will cause less problems.
    Wow, that's just an amazing statement. There's tons of stuff you could strip off of Java as it is right now to "give people less ways to cause problems". Does enums cause problems? What was the problem before when it didn't have it. Are generics problematic? They're pretty tricky. I guess we could get rid of anonymous inner classes too. How much more can we strip away?
    I agree. Take '+' away from String and give it to classes where it is more appropriate.
    I was being facetious there, but do you think that many developers have or had a problem with overloading + for String?
    My experience is that developers know what Java is and what it means. Java has become a byword for compatibility.
    Where to start here....Java is not a byword for compatibility. It's a name for a VM, a language, and a set of libraries. Do you really think that when developers think of Java in their head, the first thought that pops up is "compatibility"? We've got lots of compatible languages. Most of .NET is compatible. You've got Ruby, Python, and whatever other interpreted languages out there. Java doesn't get that distinction.
    My view is that if some version of that code doesn't pass the compatibility tests, it won't be widely adopted. So much development relies on Java compatibility that developers won't trust non-certified versions for major projects.
    What developers? And since 95%+ of Java is server side anyway, you don't have the deployment problem.
    No, you misunderstand me. I have a poor opinion of programmers in general (including myself). I am sure there are some awesome developers who don't make mistakes and always write clear code that they can come back to in a decade and instantly recall what I meant, no matter what clever tricks I use. You may be such a high-quality developer. I admit that I am not. I feel safe with the protection of a language designed to protect me from my own mistakes. Why do I have this view? Because I have had decades of experience of looking at code from other developers. This has led me to think that having such safety for general development is a good thing.
    Actually, I consider myself an average developer. And that's why I like abstractions that cut down on line noise. I don't have the best memory in the world, so anything that can increase my conceptual awareness while reading code is a win for me. Just look at the line noise you get now without operator overloading in the math classes. My problem is that reading lots of boilerplate code cuts down on my understanding of what the code is suppose to do - in that verbosity actually harms comprehendability. And I'll just re-iterate what I've said many times before that banning operator overloading from the language altogether is not going to magically protect developers from themselves.
  24. Re: Operator Overloading[ Go to top ]

    That doesn't make sense at all. Give people less ways to cause problems and they will cause less problems.


    Wow, that's just an amazing statement. There's tons of stuff you could strip off of Java as it is right now to "give people less ways to cause problems". Does enums cause problems? What was the problem before when it didn't have it. Are generics problematic? They're pretty tricky. I guess we could get rid of anonymous inner classes too. How much more can we strip away?
    I disagree with all of this. For example, enums and generics can add a lot of clarity to code, unlike operator overloading.
    I agree. Take '+' away from String and give it to classes where it is more appropriate.


    I was being facetious there, but do you think that many developers have or had a problem with overloading + for String?
    No, but if you really wanted consistency....
    My experience is that developers know what Java is and what it means. Java has become a byword for compatibility.


    Where to start here....Java is not a byword for compatibility. It's a name for a VM, a language, and a set of libraries. Do you really think that when developers think of Java in their head, the first thought that pops up is "compatibility"?
    Yes. For a lot of them (including me).
    We've got lots of compatible languages. Most of .NET is compatible.
    .NET is compatible with what? There is only one serious implementation.
    You've got Ruby, Python, and whatever other interpreted languages out there. Java doesn't get that distinction.
    Yes, it absolutely does. Many of these languages have introduced major incompatibilities with version changes (this has certainly been the case with Perl and PHP). Many of these languages intend future versions which may break backwards compatibilty (Ruby, Python, for example).
    My view is that if some version of that code doesn't pass the compatibility tests, it won't be widely adopted. So much development relies on Java compatibility that developers won't trust non-certified versions for major projects.


    What developers? And since 95%+ of Java is server side anyway, you don't have the deployment problem.
    Of course you do. This is nothing to do with Java being server-side or not. There are Sun implementations of Java on different platforms, IBM and HP and other implementations of Java on others. They are compatible. This matters.
    No, you misunderstand me. I have a poor opinion of programmers in general (including myself). I am sure there are some awesome developers who don't make mistakes and always write clear code that they can come back to in a decade and instantly recall what I meant, no matter what clever tricks I use. You may be such a high-quality developer. I admit that I am not. I feel safe with the protection of a language designed to protect me from my own mistakes. Why do I have this view? Because I have had decades of experience of looking at code from other developers. This has led me to think that having such safety for general development is a good thing.


    Actually, I consider myself an average developer. And that's why I like abstractions that cut down on line noise. I don't have the best memory in the world, so anything that can increase my conceptual awareness while reading code is a win for me. Just look at the line noise you get now without operator overloading in the math classes.

    My problem is that reading lots of boilerplate code cuts down on my understanding of what the code is suppose to do - in that verbosity actually harms comprehendability.

    And I'll just re-iterate what I've said many times before that banning operator overloading from the language altogether is not going to magically protect developers from themselves.
    Yes, but there comes a point where cutting out boilerplate through the use of various abbreviations harms readability, especially when such abbreviations may only make sense to a few people (this is one of the main arguments against operator overloading). And yet again, the use of math operators for math classes is NOT a desire to have general operator overloading. Wanting to use these operators on BigInteger and BigDecimal does not mean I also want to be able to define that they can be used on abitrary classes.
  25. Operator overloading will come[ Go to top ]

    It's only a matter of time... Remember when templates (generics) and enumerations bore the scorn of the Java language puritans? Then Java 1.5: generics (templates) and enumerators - go figure. C++ world was happily using templates (because they make a whole lotta sense) for more than 10 years before Java generics came along. The Java developers who had switched from C++ had to wait 10 years before they could do the same cool things they were doing in C++ in the mid nineties! We were all fed the *rap that enums were sent from the devil - until C sharp was released and then all of a sudden there was talk of enums in Java. Personally I hated having to define a range of separate 'final static int's and assign a unique value to each of them. That stinks. The C language back in 1987 when I started developing code supported enums - why did it have to take competition from C sharp before they finally made it into Java nearly 2 decades later? If you've ever seen how elegant the code for a C++ financial app looks when you create a Currency class that stores dollars as a long, representing cents (to avoid rounding) you'll know how powerful overloading is. You can overload all the funky maths operations so that you can add, subtract, multiply, divide etc., your Currency object just like it was an int or a float - beautiful: Currency unitCost(23.58); Currency totalCost = unitCost * quantity; instead of BigDecimal unitCode = new BigDecimal("23.58).setScale(2); etc., ... yeah, you know the rest - it only gets more ugly from here. Trust me operator overloading will come... I just hope we don't have to wait too long.
  26. Re: Operator Overloading[ Go to top ]

    I think it's all or nothing. I don't think java.math classes will be special - ever.
    Strings are...
  27. Re: Java Futures at JavaONE[ Go to top ]

    Fetching the stars before cleaning the dishes :-( They should fix the garbage collection. These drop outs for seconds are a no go for several services. The price for memory drops but you can not use it without long drop outs. Since they use a different algorithm that is not O(n^2) they will not do it.
  28. I hope by now we should be grown up, and instead of talking operator overloading and scripting we have to talk more on robustness, JVM profiling and perfromance/scalability issues. I would like to see App domain kind of improvements in the next release of Java instead. Good luck Java team.
  29. Why would we want XML literals in Java as a language level feature? XML is just another data type. Popularity really shouldn't be a reason for including it. The trouble is that there isn't any defined mechanism in the JCP to stop things happening. The only people with power are big companies, and most votes are rubber stamps, particularly on an issue ilke this. So my message to Graham Hamilton would be, how can the community say NO to changes like this?
  30. Agree on the XML specific stuff. Besides, the example doesn't seem to make life much easier. I can still mis-type ending elements, etc. How about just java literals where I can set a string like:
    String myString = LITERAL { Here is my Formatted string with returns and escaped text {1}. This would work well for templates, xml, etc and avoid the annoying StringBuffer class. };
  31. Re: XML literals? No thanks[ Go to top ]

    it'd be good to have jstl-type evaluations so if you have person.getName(), you could have String message = "hi, my name is ${person.name}"; which would avoid a lot of the pain asociated with concatenating strings. Ruby has something similar which can evaluate simple expressions.
  32. Re: XML literals? No thanks[ Go to top ]

    it'd be good to have jstl-type evaluations so if you have person.getName(), you could have String message = "hi, my name is ${person.name}"; which would avoid a lot of the pain asociated with concatenating strings. Ruby has something similar which can evaluate simple expressions.
    I would really object to this, as it would introduce code which can't be compile-time checked or refactored. It is fine to have this sort of thing in other languages or systems associated with the JVM, such as JSP or BeanShell, but definitely not in the Java language itself.
  33. Re: XML literals? No thanks[ Go to top ]

    if it were accepted as a language feature, it could be added to compile-time checks though. if it could be checked at compile-time, would you not think it would be useful?
  34. Re: XML literals? No thanks[ Go to top ]

    if it were accepted as a language feature, it could be added to compile-time checks though.
    I don't see how it could. Expression language is intended to be dynamic, and can be constructed and interpreted at run-time.
    if it could be checked at compile-time, would you not think it would be useful?
    Not really, no.
  35. Re: XML literals? No thanks[ Go to top ]

    ok, it could (of course) be done, but we'll have to disagree on this one. personally, i think it would be a great feature to have. at the very least, it would be more useful than the xml syntax proposed ;)
  36. Re: XML literals? No thanks[ Go to top ]

    ok, it could (of course) be done, but we'll have to disagree on this one. personally, i think it would be a great feature to have.

    at the very least, it would be more useful than the xml syntax proposed ;)
    Actually, I even disagree with that :) It would be great to be able to generate XHTML using that syntax...
  37. it'd be good to have jstl-type evaluations so if you have person.getName(), you could have String message = "hi, my name is ${person.name}"; which would avoid a lot of the pain asociated with concatenating strings.
    If String concatenation is your problem, then take a look at java.text.MessageFormat, or the newer java.util.Formatter.
  38. Why would we want XML literals in Java as a language level feature?
    I'm not sure about this feature either. However if we have String and numeric literials in the language, why not literial representation for other types? This maybe a very useful feature for templating XML. Also one of the problems with XML is validation. With and XML literial we would have the compiler to validate some things for us before runtime.
    So my message to Graham Hamilton would be, how can the community say NO to changes like this?
    Join the JCP. There are two (at least) members of the exec that don't belong to a big company, Hani and Doug Lea. Doug has had a profound impact (for the better) on Java. Hani has also made contributions. The bigger question is, these things are being talked about yet there is no JCP JSR in which to frame the discusions. - Kirk Pepperdine
  39. Re: XML literals?[ Go to top ]

    Why would we want XML literals in Java as a language level feature? XML is just another data type. Popularity really shouldn't be a reason for including it.
    We have literals for numbers and strings because they are used frequently. The question is whether XML is used frequently enough to merit its inclusion in the language proper. I wonder whether it wouldn't be a better idea to introduce object literals instead. They would be a more generic superset of XML literals and other kinds of hierarchical data structures like UI component hierarchies and the like.
  40. bad ideas[ Go to top ]

    Beanshell vs Groovy? ppllllease. Media/video? Thin down like orb/corba packages? What about JRE "zero" deployment? (rt.jar parts are downloaded only later if app needs it). This is the whale release, that kills Java (EJB+JSF was punch 1 and 2 and "Whale" is the KO). Good thing I know C#. .V
  41. Re: Java Futures at JavaOne[ Go to top ]

    I'd prefer to see better management of libraries. Something like Maven, or even ruby's gems which made it easy to install software. Enforcing versioing would be great too, so every library *had* to have it's version included in the manifest - I can hardly think of a time when it wouldn't be useful. I'm not keen on the xml support either - just take the code or ideas from the popular libraries like digester or castor and make them javax.* packages. Java-gems could then download and install xml support if you wanted it. I'd also like to see the corba code moved to j2ee libs, I still haven't seen a standard application using them. Not saying there aren't any, but if you're using corba it's more likely that your application is actaully "enterprise" ;)
  42. Java 7 wishlist[ Go to top ]

    Wishlist: --------- *) Do not change the language *) Make the VM memory consumption lighter *) Make the VM startup **faster** and please consider *) Make option to force JIT compilation from the first invocation *) AOT compilation Thanks :)
  43. Re: Java 7 wishlist[ Go to top ]

    I think you can force immediate JIT compilation (i.e. everything is compiled before first invocation, eliminates interpreter mode) using HotSpot argument "-Xcomp" (if I remember correctly). Don't expect the app to be faster though... it'll only increase startup time and memory consumption a _lot_! (in most cases, probably unless your app is very small) kind regards, Messi
  44. Thanks![ Go to top ]

    Thanks I didn't know that!
  45. Operator overloading[ Go to top ]

    It would be great to be able to write something like: class Property { private T value; public T operator=() {ret t} public void operator=(T value) {this.value = value} } class MyBean { final public Property s = new Property(); } MyBean x = new MyBean(); x.s = "Hello Word"; System.out.println(x.s); and what about something along the lines of: class Print { public operator()(Object object) { System.out.println(object); } } Print print = new Print(); print("Hello World"); Just a thought, Richard.
  46. class Property { private T value; public T operator=() {ret t} public void operator=(T value) {this.value = value} } class MyBean { final public Property s = new Property(); } MyBean x = new MyBean(); x.s = "Hello Word"; System.out.println(x.s);
    Is that really so different to x.s.get() and x.s.set("Hello World")? Even if, it would probably be better to implement "get()" and set(...)" methods than "operator=()". I don't like this kind of properties (which C# uses) - a side effect is that suddenly assignments can raise an (runtime?) exception. regards, Messi regards, Messi
  47. I want properties[ Go to top ]

    When will java get the equivilent of C# properties? I think that is an obvious addition and should have no compatability or robustness problems. - dave