Name any piece of irreplaceable software for any user. Windows? nope, not for Mac users or Linux users. Firefox? not for Chrome users. The only irreplaceable software is based on C, but customers don't need to be aware of that. There are plenty of great Java programs out there that are without peer for users that need them (which doesn't happen to include you). So your argument is bunk - you just made it because you don't like Java - but you are lacking the insight to see that your argument extends to all software technologies (with the exception of C, which is pretty much core to all systems). So get real, eh? Java has plenty of uses - unless all you do all day is consume web content like Facebook and make mindless statements as an AC on Slashdot.
- no standard memory/CPU profiler (JVisualVM r0x0r!!!)
- no standard database access.
- no standard dependency injection framework.
- no standard XML handling framework.
- no standard logging framework.
- no standard way to integration with LDAP/Active Directory
- compiles to C++ so requires porting to every destination platform.
... etc
It is the libraries that matter, not the language. Add libraries and you get hugely increased functionality and productivity, but unfortunately some security holes also creep in as different parts interact (this is true for any development language). I'd rather take the productivity, thanks.
.... and get rid of C and C++ for all their buffer overrun holes. Oh, and let us also get rid of Javascript while we're at it for all its exploits. Then we'd better shut down Silverlight/C# as well (http://www.cvedetails.com/product/19887/Microsoft-Silverlight.html?vendor_id=26). By the same measure we'd better ditch our operating systems to (http://www.cvedetails.com/vendor/26/Microsoft.html).
So what do we have left after scorching the earth? nothing? they're all vulnerable and all need to maintained and patched. Java is not alone and not really any worse than any other technology.
Or instead we could get real and demand that browsers fix their plugin model and run plugins with almost no privileges, ya know, as Unix/Linux does for services. That way the inevitable security holes are not catastrophic as they are now, and we don't have to do "denial of service" on ourselves by removing useful tools and technologies.
You take the TIOBE numbers to mean anything whatsoever? Interesting.
The TIOBE numbers are considered approximate, yet you fail to provide any alternative numbers and scoff at the approximation. Java rules the Enterprise, many development tools, and some games (IL-2, Minecraft, Take on Helicopters, the upcoming Arma3). The Java browser plugin may as problematic as Flash or the.NET plugin (Silverlight), but the Java Runtime Environment (JRE) itself is solid and very, very fast (which is why many developers, myself included, prefer Java to alternative development platforms).
So please, enlighten us with your numbers showing Java usage is neglible. You can't. Perhaps it's just you think computing is your desktop only, yes? Well, there's a huge amount of computing (eg. the Enterprise) that the average Joe doesn't see or hear about (because enterprises don't always talk about their competitive advantages) - and a lot of that is Java.
Yes, I refer to the same Compatibility graph of the Mono project and am horrified at how many parts are not implemented or won't be implemented. Good for you that you are so determined to work with C# that you are prepared to work with partial compatibility, work around missing parts, and then advocate for others to do the same. You probably also choose to ignore the fact that while C# is still supported by Microsoft it is no longer the love child it once was, with Microsoft now concentrating on alternative technologies. Don't be surprised while the rest of world is skeptical of the nirvana you claim.
I am also open to the notion that the only way we will better understand human activity is to study it.
If you want to do social studies then get consent from randomly selected citizens. A curiosity to study human nature in no way entitles anyone to track people *who cannot refuse to be tracked due to a massive power imbalance* (eg. pupils). To want to track people aligns with totalitarian and fascist impulses. The student in question was completely right to refuse to be tracked, and anyone who opposes it is completely wrong and against the freedoms in the spirit of the US Constitution. The fact that anyone would seek to justify such tracking beggars belief.
You think that + is simple and obvious? well, it is clear you don't understand Linear Algebra then (the canonical case for operators is matrix and vector operations). For example: what does * do? elementwise multiplication? inner product? outer product? cross product? any of numerous decompositions (eg. LU, or SVD)? How do you make * work with a triple product? Just because *you* can't imagine the issues with operator overloading doesn't mean there aren't any.
Using your "logic," pretty much any feature or utility open to even slightest abuse supposedly should be banned.
Untrue. You are projecting a strawman argument onto me. Please desist. I was pointing out that when you have a better understand of what can go wrong with operator overloading (as language designers had) then you see that it can be useful but is also quite dangerous and the risks can be considered to outweigh the benefits. Especially when the canonical use for operator overloading (Linear Algebra) shows that operator overloading is inadequate to describe the breadth of operations that need to be performed. Since operator overloading is inadequate you are forced to go back to method calls, in which case you have to evaluate whether overloading is worth it (given the risk that someone will do something odd with it, except in the simple cases you work with).
Over the past decade, with couple of exceptions, I haven't seen a single operator overload case deviating from the rule.
Well, it appears you need to see more 3rd party code. Just because *you personally* haven't seen the fsck-ups doesn't mean they don't exist.
Only for memory. There's a lot of other resources out there where the GC complicates things a lot. Files and mutexes to name some common ones. At least.Net has "using" which is a poor mans RAII, but it's still easy to mess up and have a lingering resource handle.
You can still write code to the RAII pattern in Java. In fact there are some cases in the libraries with such scarce resources that you need to do it manually, eg. AWT/Swing's createGraphics() and Graphics.dispose(). Generally doing this manually is not required because the Garbage Collector handles the deallocation of resources for you. Hence RAII is seen as unnecessary work and a source of many bugs in a multithreaded environment (if multiple threads share a resource RAII is not so good at deciding when to deallocate, and it is deallocation that is the problem, not allocation). The GC not only releases memory but can also schedule calling of the finalize() methods for resource cleanup - but there is no guarantee that finalize() will be called during the lifetime of the program (often, if a program never runs short of resources then the GC never has to run and finalize() is never called). Note that there is an equivalent of the 'using' keyword in Java 7 as part of JSR 334. You can write programs without this functionality, it is just much more compact when this keyword is available. So you see, Java has many ways of handling resources, RAII being one of them, but in almost all cases the Garbage Collector does a vastly better job than a human does in managing deallocation of shared resources in a non-deterministic multi-threaded environment.
So what are you doing here, an inner product?, an outer product? and element-wise product? a triple product? a cross product? diagonalization? or something else? you assume that the multiplication operator can do only one thing but the more you know about Linear Algebra the more possibilities there are (perhaps you are not aware of the possibilities?). Not only are there multiple possibilities but because you only have one * operator you then have to start using method names to handle all the 'multiplication-like' operations you can do (you are back to Java); and then you also have the case that * can mean different things when you incorporate different libraries in your program (one may use it to do element-wise multiplication, one may compute the inner product) which means your source code is not clear about what exactly will go on (which is a fertile source of bugs, so was something the Java designers sought to eliminate). The C++ pattern of RAII is merely trying to do a 'budget' Garbage Collector yourself.
Yes, in simple cases operator overloading can be nice (as you point out). In complex libraries (eg. Linear Algebra) and large projects that re-use many libraries operator overloading has a great potential to cause bugs. Does that make sense now?
That's nice, but I think you might be missing the point. The problem is not operator overloading *in your own code* the issue is integrating a lot of third party code (re-use is the best way to do software development) where each library you integrate has different conventions for the meaning of the various operators. That was the problem that they tried to avoid.
Man, I can't read the B.S. anymore. I'm surprised you haven't plainly named Gosling et al your gods and declared yourself to be a priest of their church. Amen. (Or change your "community" - because it sucks.)
No need for the rant. I was merely explaining why those who chose to create a language that fixed the deficiencies of C++ did what they did. They noticed that operator overloading was problematic in the context of re-use (and they were aiming for productivity). So feel free to take a chill pill, k?
You are looking at it the wrong way, which is why you reach the wrong conclusion. Most C# apps are written in Visual Studio and then need to be ported elsewhere. The fact is they often won't when you then try and run them on Mono. Of course, the tiny number of folks starting from the Mono side can restrict themselves to the compatible subset and hope that it works on the MS runtime (which is continually evolving, yes?). Bugger that. I'd rather have Java where the *design intent* is for *everything* to be cross-platform and standardized. Then I can get on with real work rather than trying to figure out which bits are or are not going to work when deployed to each customer's site (they get to choose their tech, we don't, yes?). This is why Java is still preferred in the enterprise to C# (and Mono is still niche); despite some of the nice language features of C# this fundamental design limitation will always hold it back (if Mono was fully compatible so cross-platform was essentially a non-issue then C# would gain wider adoption for web-scale internet systems; but it ain't there yet and the trends in IT are away from such techs).
Java, for instance, has ended up exploited fairly often.
Not nearly as much as C, C++ and presumably Objective-C. In fact, given the amount of remote facing Java code it is surprising how few exploits there have been for Java relative to the amount of web-facing code out there (and most of the exploits rely on holes on the underlying operating system when Java gives it access).
I was under the impression that trying to load an applet signed with an untrusted certificate would produce a big warning intended to scare off home users
That is correct, users are warned *for their own safety*. Users simply click through as they have been trained to do by Windows ("Next" > "Next" > "Next"). I've never had any of my users unable to click that one button and get going. Much better than colossal (and thankfully now repaired) security holes 1x1 pixel PNGs that get loaded without warning, yes?
It is good that operator overloading works for you. It used to work for me when doing scientific work too. However, my experience is whenever I tried to integrate a third-party library I had to go and check their source and documentation to see what their operations actually did. Sometimes neither source nor documentation were available and it was a matter of trial and error to see what the overloaded operators did both functionally and non-functionally.
I'm not saying operator overloading can't work or can't be useful. It can be. All I was saying that the general case is that the experience of the community is that operator overloading is a fertile source of errors in large systems. This knowledge led Gosling et al. to the conclusion that the new language they would be building would be better off avoiding operator overloading to assist developers achieving correctness in their applications. They wanted to void the mistakes they considered that C++ had made. It turns out that in the enterprise their decision was correct, by trading off some of the power of C++ they got huge increases in simplicity, correctness and productivity in resulting Java applications (and that is why the enterprise adoption of Java is so high and displaced C++ in many areas). C++ has more power for sure, but the additional complexity/developer difficulties when integrating libraries was not a feature, it was an anti-feature as far as they (Gosling et al.) were concerned.
when I would see at least one enterprise system running OpenJDK.
In my experience "The Cloud" usually comprises Linux boxes. Guess which version of Java they run? OpenJDK. Just in case you weren't sure, OpenJDK and Oracle JDK *are the same thing* in terms of technology (apart from some tiny library differences, eg. some graphics handling). It is the licenses that differ. Oracle also has some proprietary performance monitoring tools they sell with an enhanced JDK, but I've never seen any customers purchase them (although I'm sure some do).
Oracle/Sun Java SDK and run-time are pretty much sole alternative for the businesses, since it is pretty much only Java implementation providing commercial support.
The large number of customers I've deployed Java solutions for never worry about "commercial support" for the JDK. It is just never an issue. You need commercial support for your Operating System and LDAP and mailserver, and mission-critical stuff etc etc but no one cares about commerical support for their Java (they want the resulting *applications* to have support, but don't care about the JDK/JRE) just as no one cares about commercial support for their C/C++ compiler, or build tools, or dev environment, or test tools etc etc Please also note that besides Oracle providing commercial support for their JDK, IBM also provides support for the IBM Java stack. So you actually have a choice (for those dumb/unskilled enough to be a Java developer that couldn't use the source of OpenJDK to diagnose/fix your issue:) ). Free Libre and Open Source Software actually works - since access to the source code helps a great deal if you are a developer.
So your statements are not actually correct - perhaps you're not a Java developer so don't quite understand that ecosystem to the same degree that a commercial Java dev does?
the developer needs to buy a code signing certificate and digitally sign the applet.
Incorrect. Applets may be self-signed, although with a self-signed certificate the user is prompted to accept it (unlike a CA-signed certificate which would be accepted without prompting provided the browser was configured to recognize the CA).
Good luck getting a Java applet or a Java Web Start application to run on iOS, Android, Windows RT, or any other tablet operating system.
Well, that is a delberate choice of the manufacturers of those platforms to silo themselves from the rest of the computing environment. The manufacturers do it while they do a power-play for marketshare, and don't give a shit about their users. Fortunately Android is the clear winner in adoption and IcedRobot is underway to bring standard Java to it (iOS gets shipped on a lot of units but market share is declining relative to Android; Windows RT is negligible at this stage and probably will always lag in adoption).
Incomplete == incompatible
That's why Mono's adoption is so much less than Java (even if C# does have nifty language features it simply can't make up the deficiency).
Wow, you missed a couple of years of court cases! The OpenJDK is under the GPL and Oracle's patent claims against Google for a non-OpenJDK implementation came to nothing. Furthermore the JDK has always allowed anyone to create compatible implementations (and explicit patent grant for compatible implementations is given). The only thing you could not do was call your implementation "Java" unless you passed the Java "TCK".
In summary, there is nothing proprietary (or worth a patent fight over) with OpenJDK. The courts have already ruled on this so there is *zero* risk in using a solution based on OpenJDK. So I suggest you get your story straight and no need to persist with a FUD bogeyman about Java's legal status anymore. The C# language is standardized but its libraries are proprietary to Microsoft (and the Mono libraries are incomplete). So Java and C# are not comparable in terms of risk of proprietary claims.
it is not common but for really complex applications Java (applets or Webstart) do run in your browser (and kick the shit outta Javascript for functionality, performance and cross-browser compatibility).
Once IcedRobot is implemented the economics will swing back to Java. For those writing C++ they have to port for each platform (including Android). With Java they write once, test everywhere, and each new target platform after the first is nearly all pure profit. The problem with Android at that moment is you can't use the standard Java libraries with it, fortunately there is a project in the works to rectify this. Write once, test everywhere, sell everywhere and run everywhere is both sane and profitable. Porting anew for each platform is madness.
Operator overloading and templates were so problematic for users of C++ the designers of Java expressly removed them to remove common causes of problems (for new developers). RAII was superceded by the Java Garbage Collector. There are other ways of solving the same problem. Note: operator overloading is very problematic, eg. does * mean 'inner product', "outer product", "element-wise multiplication", or some other weird operation that some developer decided to put in. another example, does = do a deep-copy or a shallow copy? Operator overloading seems like a good idea but it is often shitty to maintain someone else's C++ who has used it.
RAII is important in C++, not so important in Java (especially in a multi-threaded environment where the Garbage Collector frees you from worrying about the lifecycle of resources shared between threads - which is a hassle in C++ and why you end up having to obsess about RAII and/or stay single-threaded).
Can I guarantee repeatable runtime behavior?
In Standard Java you can't control when the GC will run or in what order resources will be freed, but that is not significant in most cases. With VisualVM (part of the standard JDK) you can profile both memory and CPU usage in real-time for any application (unlike C/C++ you don't have to build a special debugging/profiling version of the application since the instrumentation is in the JVM "operating system" hosting the app). If your application is single threaded the behaviour is deterministic (as in, repeatable). Multi-threaded systems are non-deterministic (not matter what language you use). You are using multiple threads aren't you. Almost all chips these days (except the extremely low end) have multiple cores, and if you are not using all cores you are wasting hardware resources. Java (and more importantly, its standard library) has much better support for multi-threaded programs than C++ (no surprise given their relative ages).
Same with Java. You can use GCJ to compile just as you would with a C/C++ program (including statically linking everything you need for reliability). Although the Oracle JVM is so fast these days it actually runs faster than the statically compiled programs (since the JVM JIT can profile quickly at runtime using data not available to static compilers).
Embedded systems are pretty niche. I've run plenty of soft real-time Java programs on embedded systems (where size was not a constraint, so the SBC was ok for Java). You can of course use Real Time Java if you have determinism and scheduling constraints. You know about Java RT, yes? Oh yeah, calling the virtual machines as "interpreters" shows a decade out-of-date view of things. The JIT compilers are awesome these days, and they can make fast profiling decisions based on information not available during static compilation, which usually results in better performance of a long running system (like embedded systems are).
Slashdot Mirror
Name any piece of irreplaceable software for any user. Windows? nope, not for Mac users or Linux users. Firefox? not for Chrome users. The only irreplaceable software is based on C, but customers don't need to be aware of that. There are plenty of great Java programs out there that are without peer for users that need them (which doesn't happen to include you). So your argument is bunk - you just made it because you don't like Java - but you are lacking the insight to see that your argument extends to all software technologies (with the exception of C, which is pretty much core to all systems). So get real, eh? Java has plenty of uses - unless all you do all day is consume web content like Facebook and make mindless statements as an AC on Slashdot.
... etc
It is the libraries that matter, not the language. Add libraries and you get hugely increased functionality and productivity, but unfortunately some security holes also creep in as different parts interact (this is true for any development language). I'd rather take the productivity, thanks.
So what do we have left after scorching the earth? nothing? they're all vulnerable and all need to maintained and patched. Java is not alone and not really any worse than any other technology.
Or instead we could get real and demand that browsers fix their plugin model and run plugins with almost no privileges, ya know, as Unix/Linux does for services. That way the inevitable security holes are not catastrophic as they are now, and we don't have to do "denial of service" on ourselves by removing useful tools and technologies.
You take the TIOBE numbers to mean anything whatsoever? Interesting.
The TIOBE numbers are considered approximate, yet you fail to provide any alternative numbers and scoff at the approximation. Java rules the Enterprise, many development tools, and some games (IL-2, Minecraft, Take on Helicopters, the upcoming Arma3). The Java browser plugin may as problematic as Flash or the .NET plugin (Silverlight), but the Java Runtime Environment (JRE) itself is solid and very, very fast (which is why many developers, myself included, prefer Java to alternative development platforms).
So please, enlighten us with your numbers showing Java usage is neglible. You can't. Perhaps it's just you think computing is your desktop only, yes? Well, there's a huge amount of computing (eg. the Enterprise) that the average Joe doesn't see or hear about (because enterprises don't always talk about their competitive advantages) - and a lot of that is Java.
Yes, I refer to the same Compatibility graph of the Mono project and am horrified at how many parts are not implemented or won't be implemented. Good for you that you are so determined to work with C# that you are prepared to work with partial compatibility, work around missing parts, and then advocate for others to do the same. You probably also choose to ignore the fact that while C# is still supported by Microsoft it is no longer the love child it once was, with Microsoft now concentrating on alternative technologies. Don't be surprised while the rest of world is skeptical of the nirvana you claim.
Fantastic link. Thanks for that.
I am also open to the notion that the only way we will better understand human activity is to study it.
If you want to do social studies then get consent from randomly selected citizens. A curiosity to study human nature in no way entitles anyone to track people *who cannot refuse to be tracked due to a massive power imbalance* (eg. pupils). To want to track people aligns with totalitarian and fascist impulses. The student in question was completely right to refuse to be tracked, and anyone who opposes it is completely wrong and against the freedoms in the spirit of the US Constitution. The fact that anyone would seek to justify such tracking beggars belief.
Still doesn't justify tracking students inside (and outside, if you read the claims) school grounds and times.
You think that + is simple and obvious? well, it is clear you don't understand Linear Algebra then (the canonical case for operators is matrix and vector operations). For example: what does * do? elementwise multiplication? inner product? outer product? cross product? any of numerous decompositions (eg. LU, or SVD)? How do you make * work with a triple product? Just because *you* can't imagine the issues with operator overloading doesn't mean there aren't any.
Using your "logic," pretty much any feature or utility open to even slightest abuse supposedly should be banned.
Untrue. You are projecting a strawman argument onto me. Please desist. I was pointing out that when you have a better understand of what can go wrong with operator overloading (as language designers had) then you see that it can be useful but is also quite dangerous and the risks can be considered to outweigh the benefits. Especially when the canonical use for operator overloading (Linear Algebra) shows that operator overloading is inadequate to describe the breadth of operations that need to be performed. Since operator overloading is inadequate you are forced to go back to method calls, in which case you have to evaluate whether overloading is worth it (given the risk that someone will do something odd with it, except in the simple cases you work with).
Over the past decade, with couple of exceptions, I haven't seen a single operator overload case deviating from the rule.
Well, it appears you need to see more 3rd party code. Just because *you personally* haven't seen the fsck-ups doesn't mean they don't exist.
Only for memory. There's a lot of other resources out there where the GC complicates things a lot. Files and mutexes to name some common ones. At least .Net has "using" which is a poor mans RAII, but it's still easy to mess up and have a lingering resource handle.
You can still write code to the RAII pattern in Java. In fact there are some cases in the libraries with such scarce resources that you need to do it manually, eg. AWT/Swing's createGraphics() and Graphics.dispose(). Generally doing this manually is not required because the Garbage Collector handles the deallocation of resources for you. Hence RAII is seen as unnecessary work and a source of many bugs in a multithreaded environment (if multiple threads share a resource RAII is not so good at deciding when to deallocate, and it is deallocation that is the problem, not allocation). The GC not only releases memory but can also schedule calling of the finalize() methods for resource cleanup - but there is no guarantee that finalize() will be called during the lifetime of the program (often, if a program never runs short of resources then the GC never has to run and finalize() is never called). Note that there is an equivalent of the 'using' keyword in Java 7 as part of JSR 334. You can write programs without this functionality, it is just much more compact when this keyword is available. So you see, Java has many ways of handling resources, RAII being one of them, but in almost all cases the Garbage Collector does a vastly better job than a human does in managing deallocation of shared resources in a non-deterministic multi-threaded environment.
offsetTangentPos = LocalToTangentMatrix * GlobalToLocalMatrix * (globalPos + offset);
So what are you doing here, an inner product?, an outer product? and element-wise product? a triple product? a cross product? diagonalization? or something else? you assume that the multiplication operator can do only one thing but the more you know about Linear Algebra the more possibilities there are (perhaps you are not aware of the possibilities?). Not only are there multiple possibilities but because you only have one * operator you then have to start using method names to handle all the 'multiplication-like' operations you can do (you are back to Java); and then you also have the case that * can mean different things when you incorporate different libraries in your program (one may use it to do element-wise multiplication, one may compute the inner product) which means your source code is not clear about what exactly will go on (which is a fertile source of bugs, so was something the Java designers sought to eliminate). The C++ pattern of RAII is merely trying to do a 'budget' Garbage Collector yourself.
Yes, in simple cases operator overloading can be nice (as you point out). In complex libraries (eg. Linear Algebra) and large projects that re-use many libraries operator overloading has a great potential to cause bugs. Does that make sense now?
That's nice, but I think you might be missing the point. The problem is not operator overloading *in your own code* the issue is integrating a lot of third party code (re-use is the best way to do software development) where each library you integrate has different conventions for the meaning of the various operators. That was the problem that they tried to avoid.
Man, I can't read the B.S. anymore. I'm surprised you haven't plainly named Gosling et al your gods and declared yourself to be a priest of their church. Amen. (Or change your "community" - because it sucks.)
No need for the rant. I was merely explaining why those who chose to create a language that fixed the deficiencies of C++ did what they did. They noticed that operator overloading was problematic in the context of re-use (and they were aiming for productivity). So feel free to take a chill pill, k?
OpenJDK == GNU Community Project != Oracle. Now Oracle may set the direction of Java but that does not mean OpenJDK == Oracle.
You are looking at it the wrong way, which is why you reach the wrong conclusion. Most C# apps are written in Visual Studio and then need to be ported elsewhere. The fact is they often won't when you then try and run them on Mono. Of course, the tiny number of folks starting from the Mono side can restrict themselves to the compatible subset and hope that it works on the MS runtime (which is continually evolving, yes?). Bugger that. I'd rather have Java where the *design intent* is for *everything* to be cross-platform and standardized. Then I can get on with real work rather than trying to figure out which bits are or are not going to work when deployed to each customer's site (they get to choose their tech, we don't, yes?). This is why Java is still preferred in the enterprise to C# (and Mono is still niche); despite some of the nice language features of C# this fundamental design limitation will always hold it back (if Mono was fully compatible so cross-platform was essentially a non-issue then C# would gain wider adoption for web-scale internet systems; but it ain't there yet and the trends in IT are away from such techs).
Java, for instance, has ended up exploited fairly often.
Not nearly as much as C, C++ and presumably Objective-C. In fact, given the amount of remote facing Java code it is surprising how few exploits there have been for Java relative to the amount of web-facing code out there (and most of the exploits rely on holes on the underlying operating system when Java gives it access).
I was under the impression that trying to load an applet signed with an untrusted certificate would produce a big warning intended to scare off home users
That is correct, users are warned *for their own safety*. Users simply click through as they have been trained to do by Windows ("Next" > "Next" > "Next"). I've never had any of my users unable to click that one button and get going. Much better than colossal (and thankfully now repaired) security holes 1x1 pixel PNGs that get loaded without warning, yes?
It is good that operator overloading works for you. It used to work for me when doing scientific work too. However, my experience is whenever I tried to integrate a third-party library I had to go and check their source and documentation to see what their operations actually did. Sometimes neither source nor documentation were available and it was a matter of trial and error to see what the overloaded operators did both functionally and non-functionally.
I'm not saying operator overloading can't work or can't be useful. It can be. All I was saying that the general case is that the experience of the community is that operator overloading is a fertile source of errors in large systems. This knowledge led Gosling et al. to the conclusion that the new language they would be building would be better off avoiding operator overloading to assist developers achieving correctness in their applications. They wanted to void the mistakes they considered that C++ had made. It turns out that in the enterprise their decision was correct, by trading off some of the power of C++ they got huge increases in simplicity, correctness and productivity in resulting Java applications (and that is why the enterprise adoption of Java is so high and displaced C++ in many areas). C++ has more power for sure, but the additional complexity/developer difficulties when integrating libraries was not a feature, it was an anti-feature as far as they (Gosling et al.) were concerned.
when I would see at least one enterprise system running OpenJDK.
In my experience "The Cloud" usually comprises Linux boxes. Guess which version of Java they run? OpenJDK. Just in case you weren't sure, OpenJDK and Oracle JDK *are the same thing* in terms of technology (apart from some tiny library differences, eg. some graphics handling). It is the licenses that differ. Oracle also has some proprietary performance monitoring tools they sell with an enhanced JDK, but I've never seen any customers purchase them (although I'm sure some do).
Oracle/Sun Java SDK and run-time are pretty much sole alternative for the businesses, since it is pretty much only Java implementation providing commercial support.
The large number of customers I've deployed Java solutions for never worry about "commercial support" for the JDK. It is just never an issue. You need commercial support for your Operating System and LDAP and mailserver, and mission-critical stuff etc etc but no one cares about commerical support for their Java (they want the resulting *applications* to have support, but don't care about the JDK/JRE) just as no one cares about commercial support for their C/C++ compiler, or build tools, or dev environment, or test tools etc etc Please also note that besides Oracle providing commercial support for their JDK, IBM also provides support for the IBM Java stack. So you actually have a choice (for those dumb/unskilled enough to be a Java developer that couldn't use the source of OpenJDK to diagnose/fix your issue :) ). Free Libre and Open Source Software actually works - since access to the source code helps a great deal if you are a developer.
So your statements are not actually correct - perhaps you're not a Java developer so don't quite understand that ecosystem to the same degree that a commercial Java dev does?
the developer needs to buy a code signing certificate and digitally sign the applet.
Incorrect. Applets may be self-signed, although with a self-signed certificate the user is prompted to accept it (unlike a CA-signed certificate which would be accepted without prompting provided the browser was configured to recognize the CA).
Good luck getting a Java applet or a Java Web Start application to run on iOS, Android, Windows RT, or any other tablet operating system.
Well, that is a delberate choice of the manufacturers of those platforms to silo themselves from the rest of the computing environment. The manufacturers do it while they do a power-play for marketshare, and don't give a shit about their users. Fortunately Android is the clear winner in adoption and IcedRobot is underway to bring standard Java to it (iOS gets shipped on a lot of units but market share is declining relative to Android; Windows RT is negligible at this stage and probably will always lag in adoption).
Yes, they won't implement some libraries
Incomplete == incompatible
That's why Mono's adoption is so much less than Java (even if C# does have nifty language features it simply can't make up the deficiency).
Wow, you missed a couple of years of court cases! The OpenJDK is under the GPL and Oracle's patent claims against Google for a non-OpenJDK implementation came to nothing. Furthermore the JDK has always allowed anyone to create compatible implementations (and explicit patent grant for compatible implementations is given). The only thing you could not do was call your implementation "Java" unless you passed the Java "TCK".
In summary, there is nothing proprietary (or worth a patent fight over) with OpenJDK. The courts have already ruled on this so there is *zero* risk in using a solution based on OpenJDK. So I suggest you get your story straight and no need to persist with a FUD bogeyman about Java's legal status anymore. The C# language is standardized but its libraries are proprietary to Microsoft (and the Mono libraries are incomplete). So Java and C# are not comparable in terms of risk of proprietary claims.
the Web only supports JavaScript
it is not common but for really complex applications Java (applets or Webstart) do run in your browser (and kick the shit outta Javascript for functionality, performance and cross-browser compatibility).
Once IcedRobot is implemented the economics will swing back to Java. For those writing C++ they have to port for each platform (including Android). With Java they write once, test everywhere, and each new target platform after the first is nearly all pure profit. The problem with Android at that moment is you can't use the standard Java libraries with it, fortunately there is a project in the works to rectify this. Write once, test everywhere, sell everywhere and run everywhere is both sane and profitable. Porting anew for each platform is madness.
Operator overloading and templates were so problematic for users of C++ the designers of Java expressly removed them to remove common causes of problems (for new developers). RAII was superceded by the Java Garbage Collector. There are other ways of solving the same problem. Note: operator overloading is very problematic, eg. does * mean 'inner product', "outer product", "element-wise multiplication", or some other weird operation that some developer decided to put in. another example, does = do a deep-copy or a shallow copy? Operator overloading seems like a good idea but it is often shitty to maintain someone else's C++ who has used it.
RAII is important in C++, not so important in Java (especially in a multi-threaded environment where the Garbage Collector frees you from worrying about the lifecycle of resources shared between threads - which is a hassle in C++ and why you end up having to obsess about RAII and/or stay single-threaded).
Can I guarantee repeatable runtime behavior?
In Standard Java you can't control when the GC will run or in what order resources will be freed, but that is not significant in most cases. With VisualVM (part of the standard JDK) you can profile both memory and CPU usage in real-time for any application (unlike C/C++ you don't have to build a special debugging/profiling version of the application since the instrumentation is in the JVM "operating system" hosting the app). If your application is single threaded the behaviour is deterministic (as in, repeatable). Multi-threaded systems are non-deterministic (not matter what language you use). You are using multiple threads aren't you. Almost all chips these days (except the extremely low end) have multiple cores, and if you are not using all cores you are wasting hardware resources. Java (and more importantly, its standard library) has much better support for multi-threaded programs than C++ (no surprise given their relative ages).
Same with Java. You can use GCJ to compile just as you would with a C/C++ program (including statically linking everything you need for reliability). Although the Oracle JVM is so fast these days it actually runs faster than the statically compiled programs (since the JVM JIT can profile quickly at runtime using data not available to static compilers).
Embedded systems are pretty niche. I've run plenty of soft real-time Java programs on embedded systems (where size was not a constraint, so the SBC was ok for Java). You can of course use Real Time Java if you have determinism and scheduling constraints. You know about Java RT, yes? Oh yeah, calling the virtual machines as "interpreters" shows a decade out-of-date view of things. The JIT compilers are awesome these days, and they can make fast profiling decisions based on information not available during static compilation, which usually results in better performance of a long running system (like embedded systems are).