Oh, not heard about that, but pretty cool if it is.
No primitives - converting to primitives should be a compiler problem
Classes default to public, instance variables private and methods public.
switch on enums should handle nulls
checked exceptions should be removed
stop stuffing more stuff in the class libraries
That would be a new language instead of Java.
I agree…I wasn’t really attempt to suggest a reasonable syntax…just demo the base concept.
Some things “I’d” like to see (that I’m sure everyone would hate) involves using meta-data (via annotations). Specifically a fair amount of AOT compiler & runtime hints and contracts. As an example an escape analysis hint:
// no references are made to any of the inputs or returned value
@NoReference
public Bar foo(Bar a, Bar b)
{
...
}
// 'a' is potentially stored somewhere, 'b' is insured not to be.
public void baz(Object a, @NoReference Object b)
{
...
}
This would involve some minor compiler changes and a couple of additions to the verifier.
Strikes me escape analysis can sort all that out for you. Likewise any requests for any more detailed memory management beyond requesting contiguous allocation are profoundly unneccessary and provenly so time and time again. Garbage collection is simply not a problem since Java 6 and is even remarkably better since Java 7!
Cas 
Sure. In the same manner than the deoptim framework can pretend something is final until proven otherwise. However lowering the burden on the runtime by removing the need to deduce something that is known in advance frees up those wasted cycles for more productive tasks.
The runtime does seem pretty adept at figuring out this stuff very fast though. EA for example is apparently a linear-time algorithm. I wouldn’t really want to complicate writing code - I do want to make it simpler though. I’m really fed up of redundant typing (as in typing on the keyboard), mostly.
Cas
Hehe. And that was the “least objectionable” example I could think of.
The crucial thing is it’s still got to look and feel like Java Just with some irritations removed and shortcuts added.
Cas
That “which” thing looks like pattern matching to me:
foo match {
case s : String => println("It's a string!")
case f : Foo => println("It's a foo!")
case _ => println("dunno, man...")
}
Take a wild guess at the language. And that totally just scratches the surface.
I’d like a stronger containment syntax, which also provides a kind of aspect-oriented/mix-in capability (rather than multiple inheritance). Here’s a start:
public class Container
{
private final String str = new String("example"); // traditional containment
exposes Bar bar = new Bar(); // containment, and exposes API of Bar
contains Foo foo = new Foo(); // special containment, allowing selective expose
expose Foo.someMethod(int,float,String); // only expose this method
}
The public API of class Bar is exposed by Container, without having to do all of this:
public String getSomething(int arg)
{
return bar.getSomething(arg);
}
public void doSomething(String arg, float ugh)
{
bar.doSomething(arg, ugh);
}
The devil is in the details, of course. For one, each exposes/contains class must be unique (otherwise the compiler doesn’t know which member variable object to dispatch to).
This could be an avenue to including aspect-oriented style pre/post conditions/logic:
before Foo.someMethod(int a, float b, String c)
{
// do some pre-condition logic
}
after Foo.someMethod(int, float, String, Monkey returnval)
{
// do some post-condition logic
}
The pre-condition logic has access to the arguments (and could manipulate them if mutable objects). The post-condition gets tricky, because the argument values are no longer meaningful (but method signature necessary), and the return value of the method can be provided for reference (and manipulation).
These constructs can be found in other languages, but I think the above syntax could augment Java without too much impact.
Some operator overloading, and thingi cas mentioned… importing something as. It would be so cool 
I’d also like to see unsigned bytes, but I don’t think I’d like to see unsigned ints and longs. It keeps things simple that all of the larger primitives are signed.
Yeah, this is a similar construct to the ‘specialized types only’ version. Note however that there is a difference in possible flow control due to fallthrough, break and continue. IHMO the generalized version is much more interesting, but more likely to be hated.
@dishmoth: Rather than creating new keywords, it seems like all of these could be covered in a more flexible way by using annotations instead. Examples: If a given class is designed to be contained and the container will want to automatic expose a set of methods, each of these could be marked. And on the containing class side an annotation on reference def of the contained could have pattern matching to expose some set of methods rather than a potentially long list. And likewise to not expose a set of methods that the contained has pre-marked for exposure. WRT: weaving of aspects. Man people would really hate aspect weaving, but it would be interesting if one could devise a more generic (again by annotations) description of a how a given method is to be weaved to cover more design possibilities.
That pattern match was a degenerate case and not something you would put in real-world code. The example given for ‘which’ is doable with guards:
f match {
case x if x < 0 => ...
case x if x > 0.5 => ...
}
But again, without any actual pattern on the left side, you’re more likely to just use if/else if instead.
Eh? Wha?
Help! The tag has gone rogue!
It’s a really brain-dead check though, and the error is easily bypassed using if(true).
C# has a really cut-down preprocessor - #ifdef is about all that it supports (although it’s called #if and also allows you to use const values). Possibly a better model for what Cas wants than C.
@sproingie: okay…gotcha.
@dishmoth: the bug was in my brain. I would edit my post, but the it won’t let me ATM! It should have been @Nyhm.