Project Lambda: Java Language Specification draft

[Osvaldo Pinali Doederlein]

Em 24/01/2010 18:59, Mark Thornton escreveu:
> Osvaldo Pinali Doederlein wrote:
>>
>> The collection literals proposal is already underwhelming IMHO, 
>> because it boils down to sugar over the Collections.unmodifiableXxx() 
>> APIs. We 
> I partly agree. For lists and sets something like this
>
> public CollectionLiterals {
> <T> public static List<T> list(T... e) {...}
> }
>
> used with static import is almost as brief. Maps though are more 
> annoying to initialise. The best I can manage with existing Java

These idioms (like Builder / fluent interfaces) are stuff I won't touch 
with a 10-foot pole. You are forced to allocate at least one extra 
object (a Builder), so there's extra overhead unless you rely on 
optimizations like escape analysis + scalar replacement. I don't like 
the language/library design of "let's ignore performance, make a mess, 
and pray our advanced JIT compiler will clean it up". This often fails, 
remarkably for client-side code that must run on the less featured VMs 
like HotSpot Client; startup/warmup time is another issue even for the 
top JITs. On top of that, even a good fluent interface is pathetic wrt 
readability if compared to proper language-level syntax. I prefer to 
completely ignore this technique/trend and just write a full page of 
add() or put() calls. </rant - don't take it personally>

Tuples could be even worse, because now we're allocating one temp object 
per entry; now your runtime performance will certainly suffer miserably 
if these tuples are not optimized out (granted, that's more likely if 
tuples are added as "lightweight" headerless objects, which is something 
MLVM people are researching).

It can be argued that the performance of literal collections is not very 
important because such collections are typically very small - people 
don't populate a million-element Map with literal code, right? This is a 
good general assumption, but there are important exceptions like 
machine-generated code (e.g. parsers) which often contains enormous 
datasets encoded as initialized variables. This remembers me of another  
RFE that I never lose an opportunity to remember: the classfile format's 
poor constant pool - you cannot encode a populated array, or an object 
that allows compile-time construction (e.g. "new Point(0,0)" - 
constructor only assigns to fields and is called with compile-time 
literals). Such initializations are supported by VERY bulky bytecode, 
that's initialized at class-init time or construction time, when ideally 
they could just be memcpy'd from the constant pool (or even mmapped, 
with something like the CDS).

A+
Osvaldo

>
> public CollectionLiterals {
> public static <K,V> MapBuilder<K,V> mapOf(K key, V value) {...}
> }
>
> public static interface MapBuilder<K, V> {
>        MapBuilder<K,V> and(K key, V value);
>        Map<K,V> create();
> }
>
> Giving
>
> mapOf(a,b).and(c,d) ... .create();
>
> However I have managed a StackOverflow in javac with code like this :-(.
>
> Now if there was a short way of creating tuples so that
>
> public static <K,V> Map<K,V> mapOf(Map.Entry<K,V> ... entries) {}
>
> could be used like
>
> mapOf((a,b), (c,d), ...)
>
> preferably without so many parentheses.
>
>
>> concrete implementations for these collections. While higher-level 
>> langs may contain multiple implementations of some collection and 
>> automatically pick or change the optimal impl for each situation (even 
> Easier to do with functional style where changing the implementation, 
> when a value or mapping is added or removed, presents no problem.
>
>
> Mark
>