[quote=“Don_Kiddick,post:29,topic:39645”]
How to say this diplomatically? You suck at them.
It is possible to write overly complex types with wildcards, but when I started using C# I found the generics lacking, because I was couldn’t write the complex types I could in Java.
JNA is nice, but as with all automagic pproaches it has quiet a few drawbacks. I want them to unfuck JNI and leverage VM internals. JNA is just a fancy wrapper around JNI as far as i am concerned. Still cool.
The CNI (“C” native interface) that they had in GCJ was a step in the right direction - a simple 1:1 mapping to arbitrary library code as I recall.
Cas 
JNI. How did I forget JNI? (die! die! die!) Has anyone followed any of the proposed official replacements?
Another trivial thing is “abstract final”. Simplifies the language and nukes the now required uncallable constructors of static utility classes.
Abstract final seems to be not very logical. Why not use final and a private constructor? (or only a private constructor)
That’s what you do. The constructor serves no purpose. final & abstract are the only mutually exclusive root level class modifiers.
Oh… so it’s really possible to make a class abstract final?
Mutually exclusive = unable to both be true at the same time 
Roquen was suggesting that since it’s currently not possible to use both abstract and final together, the Java devs should add that possibility for a different behavior: true uninstantiable classes. I disagree because the naming itself is weird. Using a private constructor is good enough
I agree to your disagree
Nah, I’m suggesting it should have been that way from the start. As is created extra implementation work for compilers and VMs that add nothing to the language. Changing it now would make very little sense. abstract & final together seem weird because that choice wasn’t made. abstract = can’t instantiate. final = can’t extend. Perfectly describes static utility classes. It’s illogical to create a private constructor which is never called.
FTFY
Operator overloading for my own classes would be nice
Operator overloading is one of the few things that are actually valid to argue for and possible to implement in Java.
Ew… operator overloading might be too much of a stretch. It has to be one of the most abused and misused aspects of C/C++. Java doesn’t need to add that layer of confusion to its process. 
[/offtopic]
Though having pointer access for primitives is something I miss from C/C++.
Implementing operator overloading is certainly not a hard problem in general, no. But as it stands now, operators are not method calls, so there’s likely to be more compatibility issues doing it than are immediately obvious. Still, I think the main objection to operator overloading is, shall we say, theological rather than technical.
What about all the junk objects that would create? ‘+’ for concatenation for things like Lists would make perfect sense, but arithmetic operators would be scary. a = a + 1 + 1 + 2 + 3 + 1 + 2 + 3 + 0; could not be optimized without also expanding/replacing the type system. You could not reduce the number of new objects created, you could not simplify expressions, you could not rearrange the order of operations on objects, and you would have to make a lot of method calls. It would be relatively simple to provide that feature as syntax sugar, but readability would be scary.
c = a + b; would look nicer than SomeObject.add(a, b, c);, but only on the surface. It could mean anything depending on the type of a and b at compile time and their types at run time. Then you would have to jump around between source files to decipher meaning from human-unreadable code. Jumping around that much just to get some information from another person’s code that could have been written using a more consistent and fairly self documenting language is dizzying and takes time away from real programming. That’s why C++ is so hazardous to your health, as well as any other language with an include directive.
Operaters are my Gods and Overloading is my religion! How dare you insult His greatness and power! ;D
Well if you know the types of ‘a’, ‘b’, and ‘c’, it would be easy to decipher what a ‘+’ would mean regarding their types and the outcome. It’s just like calling the ‘add’ method, but less verbose.
public class Vector {
...
public Vector add+(Vector other) {
return new Vector(x + other.x, y + other.y);
}
}
...
Vector a = new Vector(5,6);
Vector b = new Vector(2,3);
Vector c = a + b;
Actually one operator is a method call in some contexts: +. Well, actually it can be a bit more than a method call. I think the use of + for string concatenation is the compatibility reason which prevents adding operator overloading to the language now. If it had been in the language from the start, they’d have done something different for string concatenation, or even eliminated it entirely in favour of using String.format.
And I would categorise the main objection as psychological rather than theological: its essence is “We know the horrors that people will perpetrate with it”.
I think you’re making some unwarranted assumptions about how it would be implemented. The most Java way of doing it would be a special interface which defines the methods into which the operators are translated, so c = a + b would be no harder to decipher than c = a.add(b) currently is. Having various interfaces would allow for things like varargs add operators. The technical side of things isn’t the problem.
Indeed the real problem is the ability C++ operator overloading gives to programmers to practically redefine the syntax. This makes for syntax that is almost impossible to glance at and understand without all manner of crossreferencing. It gets even more hilarious when two C++ programmers start overloading the same operator in the same project to do different things. And then they bring in some libraries that do it a third way. The theological argument is actually relatively practical for a change.
Cas
I have heard this exact argument numerous times, verbatim, in opposition to Object-Oriented Programming.