Comments on: A few requests for Java 7, part 1 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/ by Java coders, for Java coders Tue, 07 Sep 2010 06:16:07 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ionel http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-62667 Ionel Tue, 08 Dec 2009 12:08:09 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-62667 <p>What about an operator between - something really simple that could prove to be useful : so instead of a < 5 && a > 2, we have a in (2,5)</p> What about an operator between - something really simple that could prove to be useful : so instead of a < 5 && a > 2, we have a in (2,5)

]]> By: Ashish Ranjan http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-3239 Ashish Ranjan Wed, 28 Nov 2007 07:15:19 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-3239 <p>In my opinion, the most urgently required thing in core language is HEREDOC feature. C#/Ruby/PHP/Perl every language has this feature and this is a must tool and also this feature can not be replicated by any java library, it should be part of java syntax itself. For example: Creating sql string with lots of string appends is a big headache, whereas it is boon to do the same with by heredoc(multiline strings) with/without interpolation.</p> <p>bye :-) Ashish Ranjan ashishwave@yahoo.com</p> In my opinion, the most urgently required thing in core language is HEREDOC feature. C#/Ruby/PHP/Perl every language has this feature and this is a must tool and also this feature can not be replicated by any java library, it should be part of java syntax itself. For example: Creating sql string with lots of string appends is a big headache, whereas it is boon to do the same with by heredoc(multiline strings) with/without interpolation.

bye :-) Ashish Ranjan ashishwave@yahoo.com

]]> By: Sam http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-2169 Sam Thu, 01 Nov 2007 10:10:07 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-2169 <p>@Ian fast array compare would be nice... somewhat related, were you aware that the <code>CharSequence.compareTo</code> is optimised by the Hotspot runtime for super-fast character comparisons. This is inherited by <code>String</code>.</p> @Ian fast array compare would be nice… somewhat related, were you aware that the CharSequence.compareTo is optimised by the Hotspot runtime for super-fast character comparisons. This is inherited by String.

]]> By: Ian http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-2166 Ian Thu, 01 Nov 2007 06:44:45 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-2166 <p>I strongly agree with your zero-copy subarray feature, though I don't particularly care how the syntax works.</p> <p>I'd also like fast array compare methods, analagous to Arrays.equals(), based on C's memcmp. Java's Array.equals() or an equivalent array comparator are over an order of magnitude slower than C's memcmp. </p> <p>-Ian</p> I strongly agree with your zero-copy subarray feature, though I don’t particularly care how the syntax works.

I’d also like fast array compare methods, analagous to Arrays.equals(), based on C’s memcmp. Java’s Array.equals() or an equivalent array comparator are over an order of magnitude slower than C’s memcmp.

-Ian

]]> By: Sam http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1868 Sam Fri, 19 Oct 2007 23:47:40 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1868 <p>Stephen, I believe I've seen that before (in the form of a triple-equal <code>===</code> operator), and I'm totally in favour of in. Dealing with null really is what adds all that boilerplate! However, my concern with it would be that it would then leak out of <code>equals</code> methods and then we'll have <code>==</code>, <code>.=</code> and <code>equals</code> to worry about! Maybe that's not such a bad thing, but in that case I'd probably like to <code>@Deprecated Object.equals</code> :-) (which is an insane modification)</p> Stephen, I believe I’ve seen that before (in the form of a triple-equal === operator), and I’m totally in favour of in. Dealing with null really is what adds all that boilerplate! However, my concern with it would be that it would then leak out of equals methods and then we’ll have ==, .= and equals to worry about! Maybe that’s not such a bad thing, but in that case I’d probably like to @Deprecated Object.equals :-) (which is an insane modification)

]]> By: Stephen Colebourne http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1849 Stephen Colebourne Fri, 19 Oct 2007 08:10:31 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1849 <p>Your equals construct is too specific IMO. See <a href="thttp://www.jroller.com/scolebourne/entry/java_7_dot_equals" rel="nofollow">this blog pos</a>. This allows you to write:</p> <p>a .= b</p> <p>and have it translated by the compiler to </p> <p>(a == b || (a != null && a.equals(b)))</p> <p>This is a solution that has much wider applicability, and would make a huge difference to readability.</p> Your equals construct is too specific IMO. See this blog pos. This allows you to write:

a .= b

and have it translated by the compiler to

(a == b || (a != null && a.equals(b)))

This is a solution that has much wider applicability, and would make a huge difference to readability.

]]> By: Alex Miller - Java 7 Roundup (Oct 18th) http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1842 Alex Miller - Java 7 Roundup (Oct 18th) Fri, 19 Oct 2007 04:30:35 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1842 <p>[...] The javablog had a post about several Java 7 requests: [...]</p> […] The javablog had a post about several Java 7 requests: […]

]]> By: Sam http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1809 Sam Wed, 17 Oct 2007 21:22:56 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1809 <p>Kezzer, I see your point... I must admit my biggest gripe about languages like Perl are that there are so many ways to do something that I just don't know where to begin. However, that said... I really do feel that something must be done about the boilerplate in <code>equals</code> and limited operator overloading would be such a nice addition resulting in much more terse and readable code. It wouldn't even be "a different way of doing it", it'd just be a different way of writing it, which is very different as the logic and objects involved remain the same.</p> Kezzer, I see your point… I must admit my biggest gripe about languages like Perl are that there are so many ways to do something that I just don’t know where to begin. However, that said… I really do feel that something must be done about the boilerplate in equals and limited operator overloading would be such a nice addition resulting in much more terse and readable code. It wouldn’t even be “a different way of doing it”, it’d just be a different way of writing it, which is very different as the logic and objects involved remain the same.

]]> By: Sam http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1808 Sam Wed, 17 Oct 2007 21:14:21 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1808 <p>Marek... that would be great :-) I'm thinking specifically of <a href="http://openlapi.com" rel="nofollow">OpenLAPI</a> where some code is referencing up to 3 different classes of the same name (well, it did in <a href="http://javablog.co.uk/2007/08/29/j2me-development-on-os-x/" rel="nofollow">this almost-release</a>). Of course that is J2ME and would never get the benefits of Java 7 updates, but it just screams out at me how useful it would be.</p> Marek… that would be great :-) I’m thinking specifically of OpenLAPI where some code is referencing up to 3 different classes of the same name (well, it did in this almost-release). Of course that is J2ME and would never get the benefits of Java 7 updates, but it just screams out at me how useful it would be.

]]> By: Marek http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/comment-page-1/#comment-1806 Marek Wed, 17 Oct 2007 17:48:36 +0000 http://javablog.co.uk/2007/10/15/a-few-requests-for-java-7-part-1/#comment-1806 <p>Hi, getters and setters are really good features hope they will be included in the Java 7 (read about properties in Java 7). However from my point of view it is also very important to have import aliases, just like c++ or c#. This would be so great addition to Java - just imagine no more problems with naming classes - see awt and swing for a good example why import aliases are so needed (currently you have to avoid classes with same name, cause you will have problems to use them in the same time). <pre><code> import java.awt.Component as AwtComponent; import javax.swing.Component as SwingComponent; </code></pre></p> <p>So no more ClassName (like in swing) - total freedom of naming. That would be great. Hope, that someone will read this. Regards.</p> Hi, getters and setters are really good features hope they will be included in the Java 7 (read about properties in Java 7). However from my point of view it is also very important to have import aliases, just like c++ or c#. This would be so great addition to Java - just imagine no more problems with naming classes - see awt and swing for a good example why import aliases are so needed (currently you have to avoid classes with same name, cause you will have problems to use them in the same time). 

import java.awt.Component as AwtComponent;
import javax.swing.Component as SwingComponent;

So no more ClassName (like in swing) - total freedom of naming. That would be great. Hope, that someone will read this. Regards.

]]>