Things I'd like to see in the language

General Discussions
#1

And on an unrelated note to my last topic, ahem ahem, being an engineer myself I sometimes speculate about making my life easier. Here’s a few things that would make my life easier coding in Java, above and beyond the cleverness in Project Coin and lambdas and all that fancypants stuff:

  1. import Something as SomethingElse - so I don’t have to use the ridiculously longwinded or occasionally clashing names other developers give their classes. Same for static imports.

  2. scoped public / private blocks - so I can stop typing “private” over and over and over again. I’d like to be able to say private { … }.

  3. using object {} blocks. The most inner using block becomes the default resolution for method calls, as if you typed “object.” before any call. Easily escaped by using “this.” to refer to the outermost scope or just any other object of course. There can be no name conflicts simply because the using object always takes priority when attempting to resolve references - so your call to toString() is always going to end up as object.toString() when using a using block.

  4. #define/undef, #ifdef/ifndef and #include. I know it’s heresy but on many occasions macro programming gets me better results. Especially when doing debug or release builds of classes - being able to #define DEBUG true before running javac just makes a lot of sense for me. Right now I have to manually edit a public static final boolean before I do an ant build to ensure all my extensive debugging code isn’t included in the final output.

Anybody got any other pet wishes?

I forgot structs / mappedobjects. But then that’s a given, right?

Cas :slight_smile:

#2

Yeah structs and arrays of struct are one of the biggest killers. In my fantasy world where this was added there would be a supporting class for cache access related hints.

More sugar:

  • get/set
  • operator overloading

Considering the kind of sugar that’s planned for JDK 8, I cannot see what an argument against either would be.

More involved language support:

  • multiple dispatch - coming up with a good syntax would be tricky.
  • “public defender methods” for interfaces Spec found here.

Humm…that seems awful short. I must be missing lots of stuff.

(edit: I left out pattern-matching & transformation rules…'cause that would never happen. Also mix-in, since you can kind fake them with classloaders)

(edit #2)
Having a “which” statement would be handy sugar.

#3

I’d like to see a lot of things in Java. Ultimately I got tired of waiting for them and switched to Scala. Need a new control structure? Write a function taking a by-name parameter. Just did that one last night to abstract looping over a 2D array. Renamed imports? Got it. You can exclude stuff from imports too. Private blocks? Done, with nested packages. Heck it’s even got a stronger version of private, namely private[this].

I’d just like to see Scala get some tooling support that doesn’t make me throw heavy objects around in rage.

#4

I’ve been using Scala as well with the IntelliJ plugin plus JetBrains’ fsc. Works okay and I’m pretty happy with the IDE support (although it could be better).

The language is great… lots of power, functional programming constructs, way less verbosity, and ties in seamlessly to existing Java libraries.

sbt is a pretty sweet build tool although I mostly use IntelliJ’s fsc and maven.

#5

As I mentioned somewhere else: I want to like scala and I’ve tried to like scala, but I’ve never had to time to convince myself. It’d be kinda cool to have a scala Q&A thread.

#6

For Java I would like to have a native method to compile an executable, wich contains all needed JVM resources.

This would help Java get a higher stake in distributing small programs and games.

The end-user often does not understand or want to install a Java JRE.

#7

As an aside to this (AOT to native): The LLVM sub-project VMKIT seems to be moving from GNU classpath to OpenJDK…this means Unsafe support…yeah!

#8

Would you mind making that with object {}? It will confuse people moving to/from C# less.

What is a “which” statement?

#9

3 and 4 are evil. :o
i would like to see some manual allocation/deallocation helpers and structs, maybe just some kind of layer on top of bytebuffer. i think there are some libs for this, but something builtin would be nice.

#10

IntelliJ’s tooling is pretty decent, but the type-aware hilighting is pants, and there doesn’t seem to be a lot of checking without it. ensime seems to catch more stuff when I save the buffer. I wanted to like eclipse’s scala plugin, but it can’t even do indentation right unless you litter the source with semicolons.

#11

Stack allocated objects for use only in current scope (not the JVM maybe doing escape analysis). I did a contortion act with static, pooled, reusable objects in frequently-called methods in a library I wrote. Heap friendly, but unsafe for multiple threads, unless synchronized, which ruins performance gains.

Multiple inheritance. I’ve heard the arguments before, but, sometimes, mixing in multiple interfaces just has me writing duplicate code.
Maybe allow multiple inheritance if no two parent classes have concrete public/protected methods with the same signature?

#12

If your object never escapes the current scope, the JVM is likely to stack-allocate it for you anyway. It’s a feature added in 1.7. Thing is, the eden generation isn’t much slower than the stack, so it doesn’t make a very big difference in the end.

Multiple inheritance isn’t as horrible as it’s made out to be as long as there’s a well-defined linearization order (like C3), and as long as references cast to different base classes compare equally. C++ fails on both these fronts, but we’ve come a ways since then. Forbidding methods with the same signature wold prevent overriding from working. Still, there are other ambiguities in MI that aren’t easily solved. I think traits come close enough, and java 1.8 will be getting default implementations in interfaces that will get them most of the way toward traits.

#13

I dont like that Java throws an error when there is “unreachable code”.
Such as returning early.
A warning is enough.

There are many situations where I want to test a function by returning early and pass something back.

Java always assumes that the code is alsready in the final version.

It should be the developers decision if there is dead-code or not.

#14

I’ll go even more radical than that: I think uncaught checked exceptions should only have generated a warning. They were a great idea in theory, but they fell flat in practice.

Oh, and can haz unsigned types?

#15

I thought the mapped object in lwjgl covered structs :persecutioncomplex:

#16

Terrible idea, would lead to having to remember two names for one item.

I agree this is a problem; my solution would be for no accessor to default to private, and add a ‘package’ keyword for defining packaged private (‘private’ keyword would be kept so you could also state it explicitly). Down side of this is that it would break tonnes of existing code.

So you want the ‘with’ keyword?

First, some versions of GCC preprocessor work fine with Javascript. Other C-preprocessors may work fine with other C-like languages. So you could probably just use an existing one for working on your Java code.

I’d also like to see something like this, but not done how the C-preprocessor did it. The problem is there is no real context about the language, it’s trivial to write macros to generate totally wrong code. I’d also much rather be using Java-like syntax, then #statement. D approaches this differently, and there is even an example of a compile time ray tracer built using it’s preprocessing mechanisms.

#17

Yeah the with keyword, whatever does the job that’s in general use elsewhere.

I wouldn’t say “Import as” requires you to remember two names for something. It’s local to a file; there’s nothing to remember beyond that file. An IDE would simply highlight the original classname for you. It’s a great tool which combined with a preprocessor would make retargeting libraries that bit easier (eg. retargeting LWJGL to Android OpenGLES, which is where I first realised it would have been useful, especially looking at the contortions libgdx has to go through to get something simple like that working).

A “package” keyword would have been great but yeah, too much existing code breaks for that to be worth it.

MappedObjects in LWJGL are neat-o but something with more support at the language level is what I’m after.

Oh yeah and unsigned types and byte and short literals would be just great for those of us used to dealing with ByteBuffers all day long.

Cas :slight_smile:

#18

It’s conceptually similar to a switch statement. At its most generic it is parameter-less and each ‘case’ block is followed by a conditional where the first matching conditional block (assuming multiple would pass) is the one which would be executed. Trivial example using a float:


  which {
     case f < 0:
       ...
       break;

     case f > 0.5f:
        ...
       break;
  }

Another option is a specialized version of the previous which has a parameter and only deals with types.


  which (obj) {
     case Foo:   // (obj instanceof Foo) is true
       ...

     case Bar:  // (obj instanceof Bar) is true
        // here's the tricky bit since the Foo case falls through.  Two possible implementation options:  All Foo's must also be Bar's, otherwise 
        // it's a compile time error.  Otherwise a runtime exception would have to be thrown if a mismatch occurred. 
        ...
       break;

     case Baz:
       obj.callSomeMethodDefinedInBazWithoutAStupidCastSinceWeKnowInThisBlockThatObjIsAnInstanceofBazDamnYou();
       ...
       break;
  }

In a similar manner to the above, inside a basic block of an ‘if’ statement:


  Object obj = ...;

   ...

  if (obj instanceof Bar) {
     // renaming and casting the variable is pointless.
     obj.someBarMethod();
  }

Plus unsigned types are nice for dropping an “if” statement.

#19

I’ve often wanted the ability to specify java package scope to allow specific other packages access to it without making the whole package completely public. This would allow much cleaner library structures.

You can achieve the above using various hackary like reflections but something clean and built in would be much nicer.

#20

I think there’s some feature like that coming in Java 7 or 8 isn’t there?

wrt. “which” - I’d just co-opt the switch keyword.

Cast inferencing = yes!

Object a = …
String b = a; // Why should I need to explicitly cast to String to get this to compile when the requirement is implicit?

Cas :slight_smile: