Saturday 7 May 2011

Java Wish List

When I was young (oh man I sound old just for saying that), when I was younger (eeee not any better; oh dear). Back when I used to write compilers, and hack the Linux kernel I never thought twice about adding a new language feature to make my job easier. Over the years the amount of effort that requires, usually in tooling of various IDEs and the lack of will for companies that I work for to develop such tools I have fallen out of the habit of asking what language feature would make this job easier (it has instead been replaced with ‘what framework feature or library will make this job easier’).
So as I become increasingly itchy with Java I have found myself once again asking these questions, “what language features do I want?”. I was surprised at how long this list became. I include short one descriptions of the main features that came to mind, I will look to expand on some of them in future posts as short descriptions do not do them justice.
  • Improved GC behaviour where performance does not drop off for big heaps.
  • Software/Hardware Tranactional Memory (STM/HTM) support built into the language, ala Clojure. 
  • Simplify the try-with-resource syntax.  Something like the following should suffice, using the usual curly braces and the stack for scope. 
    • autoclose InputStream in = new FileInputStream("a.txt");
  • Type inference Scala style. This one feature in Scala, in my opinion makes Scala the language to look at these days.
  • A JVM enhancement, support constant pools across an entire jar file and not just a single class. It would reduce the file size greatly.
  • To give extra design intent information to the compiler which would give extra compile time checking, allow the developer to declare that a object is to not leave the stack.  References that escape the stack can cause thread safety problems and so receiving compile time checks when it matters would be a big help.
    • local Context ctx = new Context();
  • Compiler to error when references to this escape a constructor during instantiation. This is a common cause of concurrency bugs and so should just not be allowed.
  • Closures closures closures, functions as objects, everything as objects, objects objects objects. Closures. – steps down off of his soap box –
  • Remove statics. Naturally not achievable for Java, but like Global variables they break many of todays best practice design patterns and they should be put out of their missary. Another good point of Scala ;) .
  • Build immutable and lockable objects into the language syntax
  • Support lazy evaluation of expressions passed as arguments to methods.
  • Build object field and method reflection into the syntax of the language.
  • Clean and elegant closure support. Okay easier said than done, I’ll expand my ten pence worth on how this should look later but as a teaser I don’t like the Groovy or Scala syntax and prefer the style of using anonymous method syntax. It just feels more uniform to me.
  • Reflection can retrieve method parameter names, and even java doc
  • Refreash the internationalisation frameworks and build it more cleanly into the language. I like how Apple have done it in ObjectiveC over the Java resource approach.
  • language eval support
  • simple dynamic sql syntax, Nick Reeves taught me a wonderful syntax for this a decade ago and I would love to see it become main stream.
  • Another theft from Scala, implicit type conversions and operator overloading (okay so thats C++ style, we all borrow from each other :) . So I can write a Radian class and pass it around and get compile time type checking and use of language operators and conversions etc
  • for ( T a : list ) should not throw NPE when list is null
  • Groovy had it right when they added the .? operator for avoiding NPE exceptions when calling a.b().c()
  • Default values for method parameters (geesh is Java the only language without this)
  • Multiple line strings
  • Language support for templates
  • Language support for SQL and XML
  • Add Interner support
  • Add cache framework api built up using the delegate design pattern
  • one keyword property declaration
  • cleaner support for hashcode, equals and tostring..

No comments:

Post a Comment