If you could change Java, the language, what would you change?

Miscellaneous Topics
#1

Discuss :slight_smile:

For myself, I’d think about the following:

  1. I’d add “NOT NULL” as a modifier to variables, and get the compiler to assert whether something could possibly be null and complain. Why? Because I’m sick of having to assert whether something’s null or not when a compiler should be much better at doing the job than me.

  2. I’d remove checked exceptions. Why? Because they don’t actually appear to make it any easier to code correctly. Exceptions always get caught by the VM and are handled correctly anyway.

  3. I’d remove the need to make casts where the type can be inferred. Why? Because when it’s obvious that you’re attempting to make a cast, why should you have to type it?

  4. I’d have a fast easy native interface to DLLs that would allow you to simply load DLLs/SOs and call functions in them without writing a wrapper library. Why? Because JNI is the single biggest barrier for Java integrating with legacy code and making it hard to load and call 'em is a PITA.

  5. I think I’d make mapped objects a first class language construct :wink:

  6. I’d add the “const” keyword back into the language, and maybe enforce that at VM level too. Why? Because it’s easier than all the of alternatives!

Cas :slight_smile:

#2

I’d quite like a C++ style const, creating immutable interfaces is clunky and slow.

I’d also like a good way of dealing with releasing native resources (eg. gl objects). C++ RAII is much less error prone than having to do it manually. As is, finalise() is practically useless.

Constantly new’ing Vector2f objects and the like is annoying, and creates lots of garbage[1]. It’d be nice to be able to define value objects which work like primatives.

From what I hear C# has added versions of all of the above, but it also adds a whole boatload of other crud I really don’t like the looks of.

[1] Admittedly, I’m getting more relaxed about this and new-ing them all over the place now. I havn’t seen GC hiccups since I abandoned J3D and J2D and switched to LWJGL.

#3

About (1), I love the @NotNull and @Nullable annotations that IDEA supports. You can use them on both method parameters and method return values, you can see the warnings while coding and it also has an option to generate the corresponding assertions at compile time. They can easily add this to the Java compiler (you’d see the warning at compile time, like the unchecked cast warnings).

I’m not sure about (2), I’ll leave that to more experienced programmers. :slight_smile:

Can you give an example about (3)? Wouldn’t it be a little dangerous?

Agreed about the rest. I’d also make method parameters implicitly final.

#4

a ‘parallel’ keyword, as apposed to ‘synchronized’


public final void process()
{
   parallel(myThreadPool)
   {
       ...code
   }

   parallel(myThreadPool)
   {
       ...code
   }

   for(int i=0; i<5; i++)
   {
      parallel(myThreadPool)
      {
          ...code
      }
   }

   // implicit barrier, at end of method
}

You could use ‘synchronized’ inside the parallel-blocks if desired.

Looking at how multi-threaded everything will get in the future, it would be great not to hassle with Runnables so much.

Being more realistic, I’d settle for mapped-object / struct-like / value-object.

#5

Example of #3:



SomeEntity blah;
...
Robot robot = blah; // implicit cast to Robot from SomeEntity

Cas :slight_smile:

#6

Hm, for some reason I prefer explicit casting over implicit. Maybe because it makes it clearer that there’s a potential class cast problem.
I don’t care about having to type more, as long as it’s making things clear what is going on.
I kind of get the same feeling out of this as auto boxing/unboxing; I’d rather be verbose and clear.

#7

The not null thing is nice. Could be handy indeed. I must admit that I haven’t looked at annotations at all yet.

I totally disagree with #3 (the cast thing) tho. Imo it’s a sensible tradeoff. A bit more to type and no (hard to track) surprises in return. Thats why I like Java.

#8

nothing. i dont want more stuff to learn. :stuck_out_tongue:

#9

Something in the compiler that looks at my code and suggests a complete solution and/or optimization based on an analysis of the context and general intent derived from my comment sentences, algorithm loops, and variable names :slight_smile:

Hmm or is that asking too much?

#10

offcourse pulling the memory nexus in the JVM. (yes I’m in that camp now.)

Not sure if it falls under the language but I would start some serious work on the api. modulealise it, avoid backwards compatibility constrains and refactor the hell out of certain stuff.

there are a couple things I want to research first like

public doDuckLikeThings(Type duck) {
duck.methodDeclaredInInterfaceDuck();
}

#11

What kind of asserts are you doing? Mostly, I find myself fighting the compilers broken implementation of checking “has this variable been guaranteed assigned to during this method?” and explicitly nulling every variable I create (what a waste of time), or punting null errors except where I occasionally have something useful to do/say about them.

I will fight to the death to protect checked exceptions. The world has got a much better place for me since other library users and fellow coders were forced to think about the exceptions they were otherwise ignoring, and, on average, got better at actually handling the ones they should handle. It wasn’t even worth trying to get C etc coders to bother doing this, since it was optional, and too much effort to educate the entire world :(.

Templates provide a limited form of this, ML-style (with it’s total 100% type inference). I’m not sure, but IIRC there are cases that are not covered by templates but where the compiler can, theoretically, determine that there is no possible runtime error - if there are any of those left, then they hsould be fixed.

OTOH, I agree with previous posters: explicit casts are a life-saver in terms of reading other people’s broken code and fixing it.

Abso-frickin-lutely. Major major problem with commercial games dev :frowning: :frowning: :(.

All good things :).

#12

Is this technically possible? I thought you have to at least link to the interface you call in the DLL/SO. So dynamically loading a DLL/SO seems impossible to me. Am I wrong? How does VB do this kind of thing?

#13

I don’t know about the language, but with the standard API I wish Swing didn’t enforce its own threading model - the ‘Event Dispatch Thread’ causes so many threading problems and making sure code is running on the EDT by doing SwingUtilities.invokeLater(new Thread(){public void run(){…})}); makes code look so ugly. SWT has a different way of threading events.

#14

If Delphi, BlitzBasic, C#, etc. can all just call DLLs then so can Java. The only reason that Java can’t just call functions is because of the stupid requirement to pass the JNI env. and sometimes object ref into the function call. Daft. Whoever designed this bit of thinking should be hung by the toenails until sorry.

Blah3 - unfortunately most coders simply surround checked exceptions with try {} catch() { e.printStackTrace(); } and so error handling is no better than it was before. You just simply can’t make developers behave how you want. So why bother insisting on try/catch when the thread simply catches any uncaught exceptions anyway? In fact why bother with it at all when half of the possible exceptions that are likely to be thrown in practice - NPEs, OOMEs, CCEs, etc, simply aren’t declared anyway? It was a strange and daft design decision which they wisely did away with in .net and the developers are happy as pigs in poo.

About inferred casting: I’m not sure why everyone sees this as being confusing. If I attempt to assign a variable to another variable then the compiler knows it’s either castable or it isn’t; if it is castable to the type I want, why bother even saying that I want it casted? Effectively I’m saying it twice and that’s plain stupid. Every character of source code you type is another character you’ve got to read, understand, and debug! The less there is, the better.

Oh I just remembered one of the most important things I left off the list: operator declarations, which enable you to declare static methods as operators, eg. the much fabled dot operator for Vector3fs:


public static operator float dot(Vector3f left, Vector right) {
return left.x * right.x + left.y * right.y + left.z * right.z;
}

leading to code that looks like this:


Vector3f a, b;
...
float dot = a dot b;

There are very limited uses for it but where it’s used it’s invaluable. String.equals() for example :wink:

Cas :slight_smile:

#15

FoxTrot is a little relief in that area…

#16

Yeah, but how. It might be worthwhile to analyse that. Maybe there is a chance to write a library for easy dll-loading?

#17

Something like this would be just peachy:


static {
System.loadExternal("opengl32.dll");
}
public static native external glVertex3f(float x, float y, float z);

where “external” is the new keyword that says, look for this function directly in the dll. Or something like that. So the majority of external methods simply won’t need any JNI wrapping.

Cas :slight_smile:

#18

Does this one work? Java Native Access

#19

Wha?! Generally, the compiler knows nothing of the sort. e.g. if your method takes an Object as arg, you have no idea at the compiler level whether that can be cast to anything. If the compiler trivially knows, then that is already supported - you can assign anything to a variable of type that is a superclass of the thing you’re assigning, no? Or am I smoking crack today?

As I said, IIRC there are cases where the compiler can, theoretically, infer but doesn’t (yet) - but I can’t remember which they are. Can you give a specific example?

A stupid recommendation. Java is not C++. C++ is not a straightforward programming language, it’s (become) specifically designed for doing this kind of metaprogramming. If you want to metaprogram, stick to C++, don’t try and convert Java from a normal language into a metalanguage.

IMHO.

(and … the “very limited uses for it” is the bit that gives the game away; as you say yourself, this isn’t a feature for java-the-language, it’s a feature for a small number of specific domains of problems that a small number of people want to solve)

:stuck_out_tongue:

#20

No - most coders in your experience. My experience is the opposite. I would happily bet large amounts of money on the average amount of exceptions being handled correctly being higher in java than in all the non-checked langs, because I’ve seen it so very much more often in java code than in any other lang.

EDIT: and coders who do that tend to get themselves not employed by me, re-educated, or removed from my team pretty quickly.

There are shit coders everywhere. Just because shit coders can write shit code doesn’t mean everyone is doing so.

Also … it’s very easy for me to download free open-source code-lint tools and run them against the codebase and then name-and-shame in the next team meeting anyone caught routinely doing a { e.printStackTrace() }. Very easy.