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

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!

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.

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.

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.

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

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.

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.

Quote

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.

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 .

Quote

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?

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.

Quote

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.

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

Quote

5. I think I'd make mapped objects a first class language construct

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!

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.

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?

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.

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:

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.

A minimal set of Java language annotations and a small framework for dynamically accessing native libraries (for example, .dll's on Windows or .so's on Solaris) on any supported platform without writing anything but Java code—no JNI or native code is required, and access is dynamic at runtime without code generation.

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.

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?

Quote

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:

There are very limited uses for it but where it's used it's invaluable. String.equals() for 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)

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.

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.

Hm, Blah^3 would appear to be on a religious rant sort of trip there. Discussion is kind of about how to make a lot of other people happy other than oneself too. I have very little use for operators because I don't do 3D at the moment (and make no mistake I'm not talking about operator overloading, just the ability to use methods like operators, no confusion, no weird symbols, nothing difficult to work out).

And the exception argument is already an enigma within the JVM - why are half of the exceptions that can be thrown unchecked? Because they clutter up the code? Perhaps we find now, after, hm, 8 years or something intensive use that checked exceptions just clutter up code too? How come .net has done away with them? Is it hurting them? I rather doubt it. I think after all this time I've pretty much come to the conclusion that checked exceptions do not help application development to be any more correct than it was before as it is trivially bypassed. And no, you can't sack me for doing it, or anyone else who works for you, because you almost certainly do it yourself. If you start thinking in terms of humans being the most important part of the programming equation rather than God then it pays to understand human motives and reason and emotions and not make people do things that they don't want to do because they will just find a way not to do it and that includes defecting to .net, ignoring checked exceptions, changing the language, using scripting languages, etc.

Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise. But bugger if they don't have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive.. If OOP was meant to make software engineering easier, it's failed.

Here's another controversial suggestion: ditch public/private/protected modifiers. All they do is make it harder to modify OO code to do what you want it to do. Most of the time, I want to modify someone else's library in some way using extension, and quite often that involves hackery because I want to use that code in a way they just plain didn't realise. But bugger if they don't have a habit of making methods private that are full of useful code. I have to dig up the fecking source (if I can get it - or decompile it at worst), make the method public, recompile the code and build a jar, and then carry on with my hackery. Very annoying and totally counterproductive.. If OOP was meant to make software engineering easier, it's failed.

They prevent me from coding to those implementation details, which is always a bad idea.

Quote

Then ask why anyone should prevent you - the user - from doing something.

Cas

Because it increases the dependencies between components (is cohesion the term I'm grasping at here? edit: nope, it's coupling). Which is bad.

True, a bad design can hide functionality that you want to get at, but that's down to the bad design rather than access modifiers.

This is the first time you've said something I've substantially disagreed with. Is it a sign of the coming of the end times? Everyone be on the lookout for rivers of fire, plagues of locusts, cats and dogs becoming friends etc.

If anything, I would want to increase the use of access modifiers, but I don't necessarily want to have to type them every time.

How about having something like the following:

1 2 3 4 5 6 7 8 9 10 11 12 13

public:

voidmethodA() {...}voidmethodB() {...}

//more public stuff

private:

voidhelperA() {...}voidhelperB() {...}

intmyPrivateVariable;

This has little to do with what princec was saying, but I really don't want to have my crappy little helper methods exposed for use by anyone. I would like to type less though.

The problem with this is that it could make it marginally harder to tell which methods are public/private/whatever while you're programming, but an IDE could use different-colored text or have some kind of marker or something.

There is another thing that annoys me even more, but it's more a matter of style. The "normal" way to write a class is to indent every line inside of the class, but that uses up alot of my valuable screen space (which sometimes causes my expressions with long variable names to take up multiple lines). The only information the first layer of indentation provides you with is that you're not writing package or import statements and so that you can see the not-indented start and end points of . Presumably, you can tell the difference between those statements and the actual code.

If you want some kind of marker to make the class definitions stand out more without the indentation, just use a comment like the following:

In the off chance that you define more non-inner classes in the same file, you can just have another line with a # sign. The end bracket is completely superfluous because all code is in a class except for the package and the imports at the top.

So I propose using the # (or something else) for class definitions instead of bracketing them. I don't think that's going to happen, but it would be convenient for me. The point is primarily to change the way people write code so that less space is wasted by useless indenting.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org