I've never looked at JNA...if it's just a wrapper for JNI, then it doesn't address the real problem. Don't get me wrong, cleaner is good...but the cost of going across the boundary is the problem.

It may not work for you, but the GNU java compiler had fast c/c++ interface 'cause it treated Java like any other compiler source. Trouble is that they didn't implement much of the Java common libraries.

@princec - this kind of syntax is pretty much what JNA gives you, along with the ability not to have to cross-compile stubs for different platforms. It's a better JNI on the user side by far, but it's still a wrapper to JNI so doesn't get over the issues of how heavyweight that may or may not be.

@Roquen - meant to ask this back on page 2 when you or someone else mentioned it - any links to discussions on JNI replacements for Java core? Faster JNI then everyone wins, including all those nice syntax wrappers like JNA.

@Oskuro - got an example of what you were trying to do? There shouldn't be much if anything that JNI gives you that JNA can't.

I timed it once, years ago on a Celeron 300 I think - the overhead of a basic Java->JNI call jump is in the order of hundreds of nanoseconds. This means you have to do an awful lot of them before you actually notice the overhead.

JNA is not a wrapper around JNI. It's a wrapper around libffi, or at least its moral equivalent. It might use JNI to interface to that, but after that, JNI is not involved. Since it's always using dynamic libraries with dlopen/LoadLibrary, it's always going to be a bit slower than JNI.

The overhead of JNI isn't so much the call overhead as the defensive copying or locking it has to do.

These times include everything in the call (Java, JNI, driver). IIRC on Linux I had seen times below 10ns (on slower CPU, etc). I think JNI overhead is simply noise in a desktop environment. Things are much worse on ARM CPUs, though that depends on the JVM implementation (hint: you want to use Oracle's).

JNA is not a wrapper around JNI. It's a wrapper around libffi, or at least its moral equivalent. It might use JNI to interface to that, but after that, JNI is not involved. Since it's always using dynamic libraries with dlopen/LoadLibrary, it's always going to be a bit slower than JNI.

Pedant! Yes, JNA is a JNI based wrapper to libffi (a forked version from memory). Not exactly sure what you mean by JNI is not involved after that - JNI is involved in every call.

If you're sensible about not doing too much of the auto-magic stuff, speed of a call is 2x-3x that of direct JNI. That's still noise!

On topic, I highly recommend keeping an eye on Kotlin. It fixes A LOT of issues I have with Java (many mentioned in this thread), without becoming a monstrosity of a language like Scala. It also has a strong focus on performance which is ideal when developing games and you need a modern language to work with. If anyone has decompiled Scala code will know what I mean.

I've also done several tests with JDK8 and lambdas and I can honestly say that, unlike generics in 5.0, they got everything right. It's a huge improvement over how we write code now. But Java (the language) is too slow moving, any way you look at it. Many will argue that it's a good thing, but with invokedynamic I think it's only a matter of time before another language becomes the first choice for JVM development.

I'll keep an eye on Kotlin, but I'll come back when it actually implements pattern matching. Right now it's nothing but instanceof checks with no actual patterns to be found.

The documentation also seems to imply Option is nothing but typesafe null, and that makes me wonder if they'll recognize the utility of monads the way C# has. With a for-comprehension or a LINQ select, I can use the same code to deal with failure synchronously or asynchronously, with or without error messages, with or without alternatives. I just change the type that goes in, and my flow control logic itself is all polymorphic.

I'm all for "let a thousand languages bloom", but I have little use for ones that throw away perfectly good theory with a proven track record.

I've the impression that a fair amount of resources are being devoted to "other languages" on the JVM. This is a good call as java is moving slowly and this strategy should aid draw more users. More users = more contributors = JVM moves faster = win.

On topic, I highly recommend keeping an eye on Kotlin. It fixes A LOT of issues I have with Java (many mentioned in this thread), without becoming a monstrosity of a language like Scala. It also has a strong focus on performance which is ideal when developing games and you need a modern language to work with. If anyone has decompiled Scala code will know what I mean.

I've also done several tests with JDK8 and lambdas and I can honestly say that, unlike generics in 5.0, they got everything right. It's a huge improvement over how we write code now. But Java (the language) is too slow moving, any way you look at it. Many will argue that it's a good thing, but with invokedynamic I think it's only a matter of time before another language becomes the first choice for JVM development.

I like what I see in Kotlin - like Scala, it has nice features that Java doesn't. Unlike Scala, it doesn't add a whole new area of complexity (Scala's type system)

I'm largely happy enough with Java. By and large I don't find language features are stopping me produce code - it's usually time and motivation that are the real issues :o)

By way of comparison, I dropped C++ when I realised I was spending too much time chasing memory leaks, circular dependencies, dangling pointers and other problems of the past which have been well and truly solved. This is my basic issue with Java++ languages - Kotlin has some nice ideas but I doubt it's going to greatly increase my coding efficiency, whereas the C++ to Java switch really paid off in terms of time not wasted.

@OP I really see no problem with var args, they are convenient in some select situations.

I never said that there is a problem with the idea, just the implementation. Using the efficiency of arrays for a 1-100 arguments magnitude is just loony.That a array introduces problems with generics, is not lazy (and this and the previous express the erasure problem and requires copies) and can be altered inside the method (uselessly by the way, since the type is constructed a runtime in both cases, and probably harmful for code clarity if you use it as a tmp) is just the cherry of crazy on top.Not to mention that collections are infinitely more flexible when ordering matters.

The only 'advantage' i can see is that a array is very amenable to get into cpu cache, but a varargs iterable built over a array probably would too, not to mention that the varargs arguments by necessity tend to be a small amount (or a actual array).

Also i wish java had made the Collections library have full immutable type interfaces (not super of mutable ones), so that libraries don't need no steenking copies.

Rust has some ideas here (the freeze concept applied to the type system is probably a better idea than a simple type because you can thaw, add stuff and freeze as a 'protocol type' without any copies on both sides of the client-api border. Not sure how it deals with concurrency).

@OP I really see no problem with var args, they are convenient in some select situations.

I never said that there is a problem with the idea, just the implementation. Using the efficiency of arrays for a 1-100 arguments magnitude is just loony.That a array introduces problems with generics, is not lazy (and this and the previous express the erasure problem and requires copies) and can be altered inside the method (uselessly by the way, since the type is constructed a runtime in both cases, and probably harmful for code clarity if you use it as a tmp) is just the cherry of crazy on top.

The only 'advantage' i can see is that a array is very amenable to get into cpu cache, but a varargs iterable built over a array probably would too, not to mention that the varargs arguments by necessity tend to be a small amount (or a actual array).

Also i wish java had made the Collections library have a full immutable type interfaces (not super of mutable ones), so that libraries don't need no steenking copies.

Rust has some ideas here (the freeze concept applied to the type system is probably a better idea than a simple type because you can thaw, add stuff and freeze. Not sure how it deals with concurrency but Rust is a very complex language in pointer types).

See, I don't understand someone programming in Java complaining about the lack of lazy sequences. If you want lazy sequences, use Haskell. Java programmers would expect a common Java idiom to be used for varargs, and an array is pretty common for Java. Don't you think that a Lazy sequence would have been a surprising choice for most Java devs?

I'm saying that arrays not being the good choice for the type of varargs was utterly predictable in the face of generics and the well known limitations that the type erasure workaround brought to the table - especially if you needed to transform the array. This is where lazyness (not infinite sequences) is a advantage by not requiring allocation of a new array to iterate over a 'new' sequence. By specifying the runtime type of ... as a array they mandated that any transformation that is used as input to ... needs to return [].

That you're telling that i should be 'using Haskell' doesn't make it any less the wrong choice. Common idiom? Surely less than collections, which are all iterable. Make arrays iterable too by VM wizardry for all i care.

Meanwhile, every 'framework' api in java 7 and 8 is deprecating all the array methods they can get away with in favor of generic collections (swing for instance). Terrible planning, left hand doesn't know the right stuff.

I like varargs being arrays inside the method - my pet hate is that it shouldn't be possible to pass in an array to the call. For a library writer it means you still have to check for null or defensively copy the array, even when 99% of the time that isn't required because the array has just been created for you!

BTW: I dug up one of the hand-waving presentations. "To Java SE 8, and Beyond!"

My hyperbole meter just blew its mountings!

I read the "removing JNI boilerplate" (which is also a pet hate) as bringing something like JNA into core - ie. a direct binding through something like libffi / dyncall. I may be completely wrong with that!

All these spinoffs of Java like Kotlin and Scala all share one particularly irksome trait, which is that they keep changing things for the sake of changing things. Eg. removal of semicolons to terminate statements, the use of the word "fun" to introduce a function declaration when we already have a way. Why can't someone make Java++, where all the lexical bits of Java are preserved and all the annoying unneccesary syntax that bothers us is fixed.

The things I'd off the top of my head which would make it so I had to type less crap are:1. scoped access modifiers for fields eg. public { .... }2. automatic casting eg. Object x = .... ; String y = x; // no need to write narrowing cast as it HAS to be a String to run3. all the little things in Coin I've been waiting for like ?.4. iterable arrays5. that nifty default implementation thing for interfaces6. structs. Haha.7. interface methods to actually have access modifiers that workbonus 8. pre and post conditions ("DBC beyond a simple assertion feature")

It depends what the other side of that Object x = ... statement, and whether you can be certain it's always a String (and if so, why not assign it to String or just reverse the assignments?). I like the fact that you have to be explicit about narrow casting so it's explicitly treated as different to normal assignment. And if you're not 100% it should probably be wrapped in an instanceof check or possibly a try / catch.

It depends what the other side of that Object x = ... statement, and whether you can be certain it's always a String (and if so, why not assign it to String or just reverse the assignments?). I like the fact that you have to be explicit about narrow casting so it's explicitly treated as different to normal assignment. And if you're not 100% it should probably be wrapped in an instanceof check or possibly a try / catch.

It made sense in C++ where you can basically turn anything into anything else but in Java it's enforced at runtime. At compile time I'm being therefore forced to make a redundant assertion. I can't see a class of mistakes that it prevents. The compiler will still complain if you attempt a cast that is illegal eg.

Note sure I agree. Casts in java are operations, while in C/C++ they are more "pretend these bytes represent this, rather than what i said it was previously". They really change things. I like compilers to catch things rather than just rely on run time errors.

I have no special talents. I am only passionately curious.--Albert Einstein

That's what I'm saying... compiler already catches anything actually illegal, and then you're just forced to type a cast unnecessarily beyond that. In the same manner that <> means "just use the right signature to make this generic work", I'm saying, just use the right cast to make this compile.

In the same vein as null deference analysis a decent compiler implementation could even be told to warn or error when it can infer the cast cannot possibly be made, or even if the cast is not guaranteed succesful at runtime through inference. Either way, I'm fed up of polluting the simplicity of the meaning of my code with bloody casts. At least generics have removed some of them.

That's what I'm saying... compiler already catches anything actually illegal, and then you're just forced to type a cast unnecessarily beyond that. In the same manner that <> means "just use the right signature to make this generic work", I'm saying, just use the right cast to make this compile.

As delt0r said, we're talking about an operation. A standard or widening assignment doesn't cast the object so can't throw a ClassCastException; a narrowing one can. The semantics are different, so the syntax being different is a good thing in my opinion. Simplifying syntax good - increasing the scope for breaking things in the process less so.

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