Hey guys, I’ve added this entry as a link on my Java 7 page.

wow, that’s a really great aggregation of ideas Alex!

As much as I think these ideas are good, but introducing new short-hand techniques typically increases complexity in that there’s then multiple ways of doing the same thing. Are you doing it to save you time or to reduce complexity? At what point does it cease to be programming and start to become somewhat scripting?

Operator overloading I think is a great idea, but again, one of Java’s aims was to simplify aspects whilst providing a high degree of control over code. Again, at what point does it defeat one of its purposes?

Great suggestions Sam! You’d get my vote if this were a democracy.

I’d love to see limited operator overloading. There are two common cases where it would improve the readability of code no end: accessing lists and maps.

The absurd thing is that Java already has the syntax array[i]. List.get(i) and List.set(i,value) are functionally equivalent to array access. So why can’t we use code like list[i]? What could go wrong? An added benefit is that it would abstract out the choice of arrays versus lists from a lot of code.

In maps, the [index] syntax would also be a big win for clarity. Consider and compare:

mymap.put(key, mymap.get(key)++);
mymap.put(a, mymap.get(b) + mymap.get(c));

versus

mymap[key]++;
mymap[a] = mymap[b] + mymap[c];

Which do you prefer?

These changes could be implemented for the List and Map interface without needing to invent a syntax for operator overloading. Better yet, create an interface IGetSetByIndex which List and Map can both extend. They would be purely cosmetic. The compiler would first transform [] syntax into get/set syntax. No change would be required in the JVM. The changes would be backwards compatible.

There is no downside! Please someone take note! This is a feature which pretty much every other language has.

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.

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.

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.

[…] The javablog had a post about several Java 7 requests: […]

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.

Re. Sam’s suggestion for equals(), here is a static method which achieves some of what he wants.

/**
 * Compare two objects for equality.
 * @param a
 * @param b
 * @param testMe Strings specifying which properties to compare. These must
 * either be public fields or no-argument methods whose return values will
 * be compared (e.g. getters). Properties are tested using equals().
 * <p>
 * Note: We could extend to testing private fields and methods using setAccessible(true)...
 * @return true if equal according
 */
public static boolean equals(Object a, Object b, String … testMe) {
    // Null tests
    if (a==null) return b==null;
    if (b==null) return a==null;
    // Should this be mandatory? It certainly risks subtle errors otherwise.
    // See Josh Bloch's Java puzzles for examples
    Class<?> clazz = a.getClass();
    if (clazz != b.getClass()) return false;
    // Test properties
    try {
        for (String prop : testMe) {
            Object af, bf;
            if (prop.endsWith("()")) {
                prop = prop.substring(0, prop.length()-2);
                Method f = clazz.getMethod(prop);
                af = f.invoke(a);
                bf = f.invoke(b);
            } else {
                Field field = clazz.getField(prop);
                af = field.get(a);
                bf = field.get(b);              
            }
            // Compare
            if (af==null) {
                if (bf != null) return false;
            } else if ( ! af.equals(bf)) return false;
        }
    // Convert class access exceptions into runtime exceptions
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
    // All tests passed
    return true;
}

Stick that code in a utility class (e.g. MyUtitilities), and you can then access it like this:

public boolean equals(Object obj) {
    return MyUtitilities.equals(this, obj, "leftBank", "torch");
}

I think that’s pretty handy, but it isn’t as nice as a language feature. For a start it’s slower, and getting round the access restrictions would make it slower still. Also you still need to override hashcode.

And here’s an alternative based on adding an annotation

Example usage:

class MyObject {</p>
 
<p>@Equals
public String name;</p>
 
<p>private int id;</p>
 
<p>@Equals
public int getId() {
    return id;
}   </p>
 
<p>public boolean equals(Object obj) {
   return UtilityClass.equalsByAnnotation(this, obj);
}
public int hashCode() {
   return UtilityClass.hashcodeByAnnotation(this);
}</p>
 
<p>}
</pre></code></p>
 
<p>Here's the magic utility code which makes it work:</p>
 
<pre><code># lang java
/**
 * Indicates that this field or method should be used for equals() and hashcode().
 *
 * Warning: Only use with public fields and methods
 */
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.METHOD})
public @interface Equals {
}
 
     /** Test for equality based on properties annotated with equals()
     * @param a
     * @param b
     * @return true if equal by class and when all @Equals properties have been
     * tested using equals()
     */
    public static boolean equalsByAnnotation(Object a, Object b) {
        // Simple?
        if (a == b) return true;
        // Null tests
        if (a==null || b==null) return false;       
        // Should this be mandatory? It certainly risks subtle errors otherwise.
        // See Josh Bloch's Effective Java for examples
        Class<?> clazz = a.getClass();
        if (clazz != b.getClass()) return false;
        // Test properties
        try {
            Object af, bf;
            for (Field field : clazz.getFields()) {
                if ( ! field.isAnnotationPresent(Equals.class)) continue;
                af = field.get(a);
                bf = field.get(b);              
                // Compare
                if (af==null) {
                    if (bf != null) return false;
                } else if ( ! af.equals(bf)) return false;
            }
            for (Method f : clazz.getMethods()) {
                if ( ! f.isAnnotationPresent(Equals.class)) continue;               
                af = f.invoke(a);
                bf = f.invoke(b);               
                // Compare
                if (af==null) {
                    if (bf != null) return false;
                } else if ( ! af.equals(bf)) return false;
            }
        // Convert class access exceptions into runtime exceptions
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        // All tests passed
        return true;
    }
 
    /**
     * Create a hashcode based on properties annotated with @Equals     
     * @param a
     * @return hashcode
     */
    public static int hashCodeByAnnotation(Object a) {
        final int prime = 31;
        int result = 1;
        Class clazz = a.getClass();
        // Test properties
        try {
            Object af, bf;
            for (Field field : clazz.getFields()) {
                if ( ! field.isAnnotationPresent(Equals.class)) continue;
                af = field.get(a);                              
                result = prime * result + (af==null? 0 : af.hashCode());
            }
            for (Method f : clazz.getMethods()) {
                if ( ! f.isAnnotationPresent(Equals.class)) continue;               
                af = f.invoke(a);               
                result = prime * result + (af==null? 0 : af.hashCode());                
            }
        // Convert class access exceptions into runtime exceptions
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
        return result;
    }

It only works for public fields and methods. Also you have to beware of circular references creating infinite loops.

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)

Dan, actually… if helper classes are allowed, I’d probably prefer one that has the same semantics as the .= operator talked about above. That way, my code would look like

@Override
public boolean equals(Object obj) {
if (this == obj)
    return true;
if (obj == null || (getClass() != obj.getClass()))
    return false;
ToyStoryState other = (ToyStoryState) obj;
return (UtilityClass.equals(leftBank, other.leftBank)
       && UtilityClass.equals(torch, other.torch));
}

pretty much halving the boilerplate. I wonder if we could set up Eclipse to do it this way instead of doing everything explicitly?

The Annotation way looks very sweet! Would require some jiggery pokery to allow the JVM access to private fields, though.

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

@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.

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