I don’t follow what you are saying at all. The verifier internal to the JDK? Are you talking about performance issues?
“barely anybody” == less than 1% / a tiny minority, I stick by that statement, as very, very few Java developer actually grasp advanced concurrency theory and behavior in the JVM.
I never said it wasn’t awesome, or not full featured. The code to use these gems, however, extremely verbose and hairy, which was what I identified as a problem…
Unfortunately those two statements aren’t mutually exclusive! :persecutioncomplex:
“Look at games like Wakfu that embed a Java runtime where most users don’t even realize the game was completely written in Java.”
This. This is the problem right here…
Since when did writing in a language become so bad that we have to make it seem like we don’t write in it. I’m proud to say when I write something in Perl, Python, C++, C#, Haskell, and JavaScript. However, when something is written in Java we are working a lot harder to cover it up than actually be proud to state it exists. The extra overhead (and space) our programs have to endure can be avoided if safety and ease of use for our users was better maintained.
Writing applications (and games) is a competitive market. The last thing anyone needs is the language itself pushing against users using the product. It is just inefficient, and it results in us having to waste a lot more time and money working around the faults.
I’ll be keeping my eye out for advanced concurrency applications. I mean, most applications will have a difficult time taking full advantage of it. We can already leverage threads well enough for gaming applications, but in this regard, there might be some breakthroughs. It is hard to tell as this release is still fairly new.
From a developer standpoint, Java 8 makes our code a lot more efficient to write and faster in the JVM. I can’t refute that. However, what use is there for a fast program if we still have to deal with the security and user access issues. It just seems counter-productive to me…
Console games often use C++ for the base game and something like Lua for higher level scripting and use various middleware library like Havok physics: At no point does the user need to be aware or understand what C++ or Lua or Havok is. The game just works. And programmer types can learn more and read developer Q&A. Java should work the same way.
Game devs don’t have to be ashamed of something like Lua, but users should be able to play the end game without thinking about the development end of things.
There are no security or user access issues with something like Wakfu, at least not compared to than any other downloadable game made in any other dev tool.
Clientside Java pissed off developers: unstable plugin, no backwards compatibility whatsoever.
Clientside Java pissed off average Joe: unstable plugin, guaranteed browser freezes, constant nagging for updates shipped with nasty toolbars.
Clientside Java pissed everybody off. So there. That’s the problem right there. You can’t blame aforementioned Joe for a healthy aversion regarding Java, trying to obliterate every single JRE he can find, for the sake of browser security, too.
Next time I embed a JRE, I’ll disguise it so well, only antivirus software can find it – after which it will make an attempt to lock its files, and crash the JRE… yeah, there is no hope.
We have a problem with programming languages. We are trying to rank them against ones that don’t belong.
As far as I’m concerned, there are 3 commonly used types of programming (not scripting) language:
1. Well used, well tested, well developed languages. (C, C++, C#, Java, etc.) Good for maintaining legacy applications/libraries, but are struggling to keep up with the times.
2. Web languages. (JavaScript, PHP, HTML if that can be counted as a language). I know I said not scripting, but these are really your only option for web development.
3. Next-gen languages. (D, Go, Rust, Scala, Python, etc.). The next set of languages that aim to fix something in any of the previous languages.
To be successful, they have to be compatible with existing toolchains, and quickly get the libraries and bindings that people will need. If they do this, they are extremely useful. If they don’t, they flop. They can also flop when they try to do too much, and just create a mess. (looking at you, Scala)
Extremely low-level (ASM, etc.) and esoteric languages left out because they’re not commonly used.
Languages start off in #3, and if successful enough, will eventually end up in #1 when technology moves on. The longer one can stay in category 3, the better, and also the longer it will stay in #1 when it eventually falls behind. Web languages (very limited) just go in #2.
Yes the bytecode verifier in the VM. Since it wasn’t changed to enforce the type-bounds all JVM languages must emit bytecodes that will pass as if they aren’t there. In most cases I expect there is no performance hit as the back-end is likely to be able to remove the runtime typechecking and/or artificially injected access methods. Java the language reflects this…that the annoying part. Needed to cast a known to known and/or suppressing warnings.
Generics with primitive types and no boxing would be great. Large chunks of unnecessary code and performance issues cut out in a trice.
Cas 
Let me refine that: we need a type macro system (code specialization of types). I’d be nice if it were runtime (VM aware), but that’s doable without JVM support.
No! The Java applet plugin pissed everyone off. Every copy of Matlab embeds a JDK, just like Wakfu, or the Windows version of IntelliJ (IIRC). That is all client side and there are no complaints about that at all.
The toolbar crap and totally broken auto-updater cost them a vast amount of goodwill.
Cas
That is all the Java web plugin. If you just embed a client-side JRE like Matlab, Wakfu, IntelliJ, users aren’t bothered by that stuff.
Wasn’t talking about embedded there… just system VMs. The JRE is otherwise awesome, if a little overlarge these days.
Cas
Oracle should kill or at least formally deprecate the system VMs.
Hopefully this will get a little better when we get Jigsaw and a module-based JRE glares at Oracle. Although I haven’t heard/read anything about it recently…
Although Stripped implementations were ruled out for java 8, they may show up in a point release prior to java 9. While it’s not a full module system, it would at least allow for the removal of unneeded classes in a way that is compliant with the license.