private static final long serialVersionUID = 1L;

public SSMap i(String key, String value) {
this.put(key, value);
return this;
}

}

and then:

SSMap params = new SSMap()
.i(“idSite”, “1″)
.i(“period”, “day”)
.i(“date”, “today”);

http://gleichmann.wordpress.com/2008/01/15/building-your-own-literals-in-java-tuples-and-maps/

Peace
-stephan

>Many methods these days take a Map as a parameter

Well, I’d call an API with such methods a bad API. Why not defined some constants while you’re at it:

public static final String FIRST_NAME = “firstName”;

Bah.

>Person person = em.create(Person.class, “firstName”:”daniel”, “lastName”:”Spiewak”);

What if the create method takes two maps as arguments create(Class clazz, Map mapA, Map mapB)?
I don’t know how Ruby does it but how should Java be able to sort out which values belong to which parameter?

A InstanceInitializer isn’t a Constructor. http://java.sun.com/docs/books/jls/third_edition/html/classes.html#246032

And I wouldn’t call it a shorthand notation it does what you declare it to do in the order that you declare it should be done and there is no long form that is truely equal. (sure there are ways that the result will be the same but the execution is/operations are different.) (step 4 in paragraph 12.5 for execution order) (For the ppl that had there cup of coffee: pls note how if there wouldn’t be subclass beeing created here you would get a runtime error

to dive into the actual discussion; I wouldn’t call the ruby bit cleaner, shorter? yes, less effort? yes, easier to read? if you say so. Sure the java syntax is a bit painful I agree. Also the problem isn’t limited to maps alone. Think other containers like (J)Component’s but also simple Lists. Now one option for that was to make add() methods return the object your adding to allowing for:

Container container = new Container();
container.add(foo)
.add(bar)
.add(ducky)
.add(firetruck);

(someone even suggested that void could be implicitly return the object which the method belongs to)
But any add()-alike method might return at this time something else like the status of the operation or other stuff. But it falls more into api-design then language-design I guess.

you asking for a (shorthand) syntax to create Map.Entry and implicitly wrap those in a Map which is where the problems start. The later(implicitly wrapping) creates unreadable bit’s of code. What if em.create() takes 3 arguments Type Map and something else(heaven forbit: a Map). Sure you can get around that by using the same restrictions as Object… object has. but that has it’s drawbacks too.

now you can hope for something alike (please ignore that Map is an interface, I suppose you could use Unmodifiable map)
Person person = em.create(Person.class, new Map(“firstName”:”daniel”, “lastName”:”Spiewak”));
Person person = em.create(Person.class, Collections.unmodifiableMap(“firstName”:”daniel”, “lastName”:”Spiewak”));
I gues you see the drawbacks of that too.

JDBC is low level, also in general java developers don’t like collections with unenforced rules to masquerade as types. Which is where script-like languages and java-like languages clash. Sure creating shorthand constructions for data objects is tedious. Illustration:

Person person = new Person();
person.setFirstName(“Michael”);
person.setLastName(“B”);

person = em.persist(person);

vs

Person person = new Person(“Michael”,”b”);
person = em.persist(person);

(+ creating dull constructors)
causes problems if ’shorthand’ constructors end up having the same type arguments.

Here ‘named parameters’-constructors for beans that can be and should be auto-generated could be a blessing:

(Person is a bean)
Person person = new Person(FirstName:”Michael”,LastName:”B”);
person = em.persist(person);

Person person = new Person(LastName:”B”,Foo:”bar”);
person = em.persist(person);

Some other notes:
I wouldn’t know about inconsistency but if you referencing to verbose as bulky then I like bulky and it would be intentionally bulky.

Also generics was introduced to improve type safety not as syntax sugar.

Ruby’s hash syntax is excellent, and greatly influences APIs built with Ruby, including many of the Rails APIs. The simple hash syntax basically gives you a simple form of named arguments, which can be used to make a very powerful, but easy-to-use, API, because you don’t have to pass arguments in a specific order, and you can better grok a method call without looking up its definition.

Of course, closures have an even bigger impact on APIs.

Even the following example, which is a bit less of a leap from Java in its current form, would be a big improvement:

Person person = em.create(Person.class, new HashMap(“firstName”:”daniel”, “lastName”:”Spiewak”));

…Although I think I prefer Ruby’s => notation to the colon notation you’ve borrowed from Groovy.