Whiteboard results - For each

Whiteboards

Whiteboard results - Generics

General ideas

This page documents the results from the whiteboards where all Javapolis 2006 participants were encouraged to participate with their ideas.

List creation

This idea was to provide a syntax way to create lists.

List<String> list = new ArrayList<String>({"one","two"});

The additional syntax in the brackets is a creation syntax for lists.

Comments included:

• "Use builders, you don't need a language change"
• "Why not just use static factories"
• "Yes!"

Map creation

This idea was to provide a syntax way to create maps.

Map m = {
  key1 => value1,
  key2 => value2,
  key3 => value3,
};

This was a sketch of an additional literal syntax for maps.

Comments included:

• "Ruby, Perl, ..."
• "Yes! Literal syntax for maps!"

Static this

This idea provides a syntax to access a Class object for the current class from a static method.

public static void main(String[] args) {
  Class thisClass = this.class;
}

The syntax wasn't indicated on the whiteboard, so this is derived from the intent.

Comments included:

• "+1"

Keyword parameters

This idea was to allow parameters to be passed into a method by name.

foo.bar(x => 6, y => 9);

This syntax passes the parameter x the value 6, and parameter y the value 9. The syntax required optional parameters with defaults.

Comments included:

• "Like common lisp"
• "Solves problem of lots of params"
  • "and constructors"

Tuples

This idea was to add tuples to Java.

int a,b,c;
(a,b,c) = (1,2,3);  // syntax proposal 1
{a,b,c} = {1,2,3};  // syntax proposal 2

Comments included:

• "Use braces {} rather than parentheses () - this avoids repurposing parentheses to have a tuples like meaning which braces already have (sort of)"
• "The tuples should be like an 'anonymous type', ie. (a,b,c) has type <int,int,int> so a method could return a tuple"

  // method declaration:
  public (int,String) mostPopularWord(String text) {
    ...
    return (numhits,word);
  }
  // calling code:
  (hits,word) = mostPopulateWord(textToQuery);

User defined operators

This idea was to add some form of operator overloading to Java.

Matrix a = new Matrix(...);
Matrix a = new Matrix(...);

Matrix c = plus(a, b);   // current syntax
Matrix c = a + b;        // new syntax

The reason behind the change was to make scientific computation easier.

Comments included:

• "C#, C++, Python, Ada, Fortran have this so why not Java"
  • "Ruby and Groovy have it too"
• "For the syntax, take a look at existing solutions - don't reinvent the wheel"
• "How would you avoid abuse?"
  • "The current syntax is the abuse: plus(d, mult(plus(a,b),c)) - should be: d + (a + b) * c"

Catch multiple exceptions

This idea was to allow multiple exception types to be caught easily.

try {
  ...
} catch (Exception1, Exception2 ex) {
  // handle both types of exception
}

There were no comments on this idea.

Combined Reflection and Mirror API

This idea is to provide a common API to access the standard reflection API and the annotation mirror API.

Detail on http://agilejava.com/blog/?p=65

There were no comments on this idea.

Immutable arrays

This idea was to add the ability to have immutable arrays in Java.

public static final String[final] MONTHS = new String[] {
  "Jan","Feb","Mar,...
};

The syntax change is allowing the 'final' within the array type definition. It would lock the contents of the array and prevent any change.

Comments included:

• "Requires VM support - Neal Gafter"
• "Why not use a type-safe enum"
  • "With JVM change, this could really improve startup performance"

Method access

This idea was to improve support for accessing methods.

// current
Method m = obj.class.getMethod("someMethod");
// proposed
Method m = obj.someMethod.getMethod();

The exact syntax was a little unclear, but the intent was to allow direct access to the Method object using language syntax.

"How can I get the Method object? The existing way breaks refactoring!"

Comments included:

• "And doesn't give compile time errors!"

Properties

This idea was to improve support for properties.

1. No useless setters and getters - only specify when needed
2. True refactorable data binding and compiler checked (not with strings)
3. Native property observers, like AOP before/after advice

The example for part 2 was:

binder.bind(user, User.firstName);
binder.onChange(user, User.firstName, closure);

In this example, the 'User.firstname' syntax returns an object representing the firstName property on the User class.

There were no comments on this idea, however an informal straw poll vote yielded 4 in favour and 2 against.

Assertions

This idea was to enhance assertions.

"Assertions should work the same way as in Eiffel, ie. inheritance, instead of useless C/C++ artifact."

Comments included:

• "Eiffels approach has a number of subtle problems. ie. it doesn't handle no-entrancy well/correctly - callbacks are important."

Equals by annotation

This idea was to simplify writing equals methods.

"Object equals() and hashCode() should compare all fields that have an @Equals annotation"

Comments included:

• "And slowdown every equals()? No!"