Slashdot Mirror
Love and Hate For Java 8
snydeq writes "Java 8 brings exciting developments, but as with any new technology, you can count on the good, the bad, and the headaches, writes Andrew C. Oliver. 'Java 8 is trying to "innovate," according to the Microsoft meaning of the word. This means stealing a lot of things that have typically been handled by other frameworks and languages, then incorporating them into the language or runtime (aka standardization). Ahead of the next release, the Java community is talking about Project Lambda, streams, functional interfaces, and all sorts of other goodies. So let's dive into what's great — and what we can hate.'"
I'm disappointed. I expected Lambda functions to be closer to Erlang's implementation, where you can access the variables of the enclosing function/method safely. But perhaps the examples in the article are just too simplistic to show such behaviour.
I do not fail; I succeed at finding out what does not work.
Proper date and time handling is one of the reasons I really prefer .Net to Java. The support for dates is just deplorable in Java. One shouldn't have to use an external dependancy, like JodaTime to handle basic date operations. If they could also add a "Decimal" data type, that is, a base-10 decimal primitive datatype, I think Java would be a much more useful language for day to day programming. Almost all the programming I do I would rather use a Decimal data type rather than a float data type, but very few languages support it as a native data type. .Net is one of the few environments where they got this right.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Oracle is good at one thing: making Larry Elison money. Microsoft isn't sure what they're good at.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Java is a real language, and a lot of real programs have been written with it. It's not a good language, but that doesn't make it trivial.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
So you're saying that *all* programming languages are exactly as good each other then? Perhaps you are spending too much time in the "real" world?
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway. What really sets languages apart is the tooling that's built up around them. The debuggers, the IDE, the profilers, etc. Also, the consistency and extent of the standard API plays a huge role in how useful a language is. I would rather use Brainfuck with an amazing tools and a rich API than use Java, Python, or Ruby with bad tools and an inconstent and incomplete API.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Well its a mixed bag really. It is a lot more verbose than other recent languages. The type system is inane. The main advantage is you have binary portability across platforms and a really huge standard API to use.
Newsflash: People write major systems in Java that work pretty well. People do mission critical, bet-the-company stuff in Java, and it works. *Your* mileage may vary, but it always does.
This doesn't mean it' the best choice for everything, because *nothing's* the best choice for everything
And it doesn't mean Java doesn't have serious flaws. There's something deeply ingrained in Java that encourages over-engineering. But every language has its pitfalls.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Oh boy!! If that's what you understand of java...
FYI, You are still using java every single day (as in websites using Java in server side, on phones, on smart cards, on home appliances, ...).
The old adage is always applicable: Those that do not use LISP are condemned to reinvent it. Badly.
I think one of the big problems is that programmers are very much biased towards thinking that what should be considered matters of preference are absolute right/wrongs, and most of the differences between major languages themselves are simply matters of taste or convenience. It's why you can get almost any software engineer to tear apart someone else's code, even if the code is written as well or better than anything they've written: there's pretty much always small differences that the engineer will find offensive even though there's no practical impact.
That was my general thought. Most languages are pretty much interchangeable. What tends to set them apart is the ecosystem they exist in... not just in terms of the 'hard' things like libraries and tools, but the 'soft' things like how much of a developer community (and candidate pool) exists for any particular domain.
Which kinda makes me wonder why language designers bother with these updated versions out side some fetishistic desire to make their language of choice more complicated. Though I guess it does help separate out the 'elite and in the know' from the 'newbies and outsiders'.... though I think C++ really takes the cake in that regard.
Java is a brogrammer language. It's for people that find writing real programs, in real languages, too hard.
Well consider this your lucky day! With Java 8 you can now write JavaScript to run inside of Java! Sayeth TFA:
Netscape created a piece of software called LiveScript to allow for scripting on its Web servers. It decided to port it to its browser and needed a fancier name, so it licensed the Java trademark from Sun and called it JavaScript -- which would long promote the confusion that JavaScript had very much to do with Java. However, after the apAOLcalypse, some members of the 12 colonies of Netscape were not done and sought to continue Netscape's plan of rewriting their browser in Java. In order to do so, it needed to create an implementation of JavaScript in Java. Netscape called the project Rhino; as with turducken, ours is not to question but to enjoy.
So just in case the seemingly unquashable confusion between Java and JavaScript wasn't bad enough, it's about to get worse. But I guess you can't blame Oracle -- they heard you like to use JavaScript and Java, so now you can JavaScript with your Java while you Java with your JavaScript. Or something. Plus throw in some Node.js bullshit for good buzzword coverage.
While there are many places that it can be useful to run JavaScript from within Java....
This is just plain bad.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
Sadly, people like to think that their tool of choice is the best, and it is the best everywhere and applicable to all situations, thus language designers over time try to make their preferred language more and more like every other language till it becomes and over complicates mess that you basically have to learn half a dozen dialects in order to understand any random chunk of code. Just look at C++, you can almost tell which year the person who wrote the code learned it in.
I used to work on a Java transaction processing application at a major financial institution that handled more than 1,000,000 transactions a day that consolidated data from Unix, mainframe and Windows systems. The transactions came from batch and online, client-facing applications that had five nines uptime requirements.
I don't know, sounds major to me. And we had no more "major system problems" than any other app and less than most.
It's not to say that Java is the answer to everything because nothing is. But it is definitely capable of doing the heavy lifting.
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
May you spend 100 years in purgatory, writing AI programs in COBOL.
Lisp may be an interesting language, but Lispers scare me. The glow in their eyes when they evangelize about the Mother of All Languages reminds me of Village of the Damned.
Since when is standardization stealing? Do you think the Redhat/JBoss devs that wrote Seam complained when they were asked to create the CDI spec? Or when Gavin King (creator of Hibernate) worked on JPA? Maybe in some bizarro world standardization actually happens as technologies mature. You can look at the expert list of any of the JSR and see who these *thieves* are.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Java 8 is still limited to 32-bit array indexes, meaning, e.g. that arrays of doubles are limited to 32GB. Java won't get true 64-bit support until Java 9 in 2016.
I remember when C# and .Net first came out, it was noted that it was just borrowing (some said stealing) from Java. When C# first came out, I didn't see it as becoming a leader in new language features, but it is clearly is, as Java 8 addresses a lot of things that been part of C# for a while.
Streams: Similar to IEnumerable and parts of LINQ (LINQ to Objects). Of course, IEnumerables are less strict on multiple enumeration (it may work). Being a bit more strict on this as Streams isn't a bad idea. Functional Interfaces; The article was light on details, but it seems to address the use cases that extension methods in C# addresses. Interesting that the body of the method appear in the interface. The ability for a class to override this default is a new idea, it will be interesting to see how this plays out. Not a bad way to go about this at all. Lambdas:Well, it's -> versus =>. I can't imagine the discussions that occurred over which one to choose.
I'm not sure about the JavaScript in Java feature. But, I've always said being able to execute Scheme in .Net would be useful to me, so this something that MS may have to address down the road.
For me, Java still needs some catching up in terms of parallel programming versus the Task Parallel Library (and the Dataflow Extensions). This is especially true with C# 5.0. Async and await are powerful language features. Personally, I'm still prefer C#. I like having first class generics, the full LINQ library (Expressions) and libraries like Reactive Extensions and Code Contracts (plus the static verifier) are nice features. But, all this in Java 8lis a step in the right direction. I just hope it isn't a case of too little, too late.
That's sort of the point of the language. The ability to write once and not have to rewrite the entire thing because you're now on a different platform.
Your complaint is sort of like complaining about how hard assembly is and how they should figure out how to make it more easily read and do things for you.
And it doesn't mean Java doesn't have serious flaws. There's something deeply ingrained in Java that encourages over-engineering. But every language has its pitfalls.
I don't think there's much in Java the language that encourages over-engineering; it's more in the community that surrounds Java. It's in the tutorials, and books, and code examples and discussion groups . It's in the frameworks and libraries.
The reality is that a "language" is as much shaped by the community that grows up around it as by the actual language itself. Perl doesn't have to be particularly unreadable, but the culture that grew up around perl in the late 90's that was obsessed with cute hacks, fewest keystrokes, and self created obscurity created a state where anyone learning perl was immersed in that culture and came out writing a lot of unreadable stuff. It is my understanding that since many of those programmers left perl for other languages perl has been remade as "Modern Perl" which is largely the same core language, just with a different and libraries, and is quite readable.
Conversely python can be made quite diabolical (just through together chains of nested list comprehensions and single character variables for example), but because it grew up with a culture of "one obvious way to do it" and readability most code you'll see tends to eschew such things, and strive to read like pseudo-code. Again, there's not that much inherent in the language, it's the cultural conventions surrounding the language that enforce much of that.
Java fell in with the Enterprise crowd, and consequently found itself immersed in a culture obsessed with design patterns and over-engineering. Had things gone a little differently with, say, in browser applets somehow becoming the primary driving force for java (let's assume they ran better say) then I doubt java would be known for over-engineering.
Craft Beer Programming T-shirts
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway.
This is a false statement, they are not as good as the other. Each language is designed to be strong in certain areas while weak/ignoring other areas. As an example, C promotes code close to machine language while Java shields the programmer from manual memory management (GC). There are many such design issues that make a language a natural fit for certain applications while making other languages ill-fitted.
What really sets languages apart is the tooling that's built up around them.
While tools may be important, they are of a secondary importance.
The email you cite also contains (quoting a previous email?) what I've long considered the real secret of Java's success:
Java did not achieve acceptance based mainly on the
features it has (or does not have). It was accepted because
Sun expended a huge amount of effort (not to mention money)
promoting Java and the things built from it, and wisely
positioned it against the nightmare that is C++.
The Guy Steele wrote:
We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.
Halfway to Lisp? Other than GC, there isn't much about Java that's Lisp like. Guy was rationalizing.
IMHO, without Java being pushed as an alternative to C/C++, I don't think we would have gotten the renaissance of dynamic languages we have today
I think Moore's law had a lot more to do with it than Java. Computers are now fast enough and have enough memory that you can afford to write many things in languages that are slow and memory intensive.
So if another framework or language has a certain feature Java isn't allowed to have them?
Really?
I'm not sure how that connects to the GPs request. Anyway Gosling didn't include it because the behavior aren't defined in CPU independent ways.
32-unsigned 0 minus 32-unsigned 1 = ?
where ? is CPU dependent. Some you'll 0xFFFF other 0x8001 others 0xFFFE. That's precisely the sort of thing JAVA was designed to abstract away. And if you don't want unsigned to be doing raw CPU arithmetic on primitives then you can just use a library.
Lisp is the perfect example of CastrTroy's point -- for a long time the interesting development tools were proprietary, expensive, and obscure.
That's not the real problem with Lisp, Smalltalk etc though.
The real problem is that you don't get to benefit from their strengths unless you live completely in their environment. Working with Lisp in a C* based world is like driving a car in the ocean.
In case you weren't aware of it: http://ironscheme.codeplex.com/
No sig, sorry.
I would almost agree, that any language is as good as any other. With a few exceptions, like "whitespace" which isn't meant to be a practical language anyway. What really sets languages apart is the tooling that's built up around them. The debuggers, the IDE, the profilers, etc. Also, the consistency and extent of the standard API plays a huge role in how useful a language is. I would rather use Brainfuck with an amazing tools and a rich API than use Java, Python, or Ruby with bad tools and an inconstent and incomplete API.
I think it would be very difficult to convince Terumo Cardiovascular Systems to build their next blood gas monitor system, or any of their medical devices, on a Java substrate. I think it would be difficult to convince Radiometer Inc. to base their next portable point of care immunoassay system on a Java substrate. I will go further: I doubt you could get any company working on life support systems of any type to trust Java enough to use it as a substrate.
Java is not suitable for a great number of applications, and, indeed, any language that uses a runtime system, and is either interpreted or JIT'ed, or not, is unsuitable for those applications.
For those applications, you need a language that compiles to ROMable machine code.
For applications like industrial control systems, both in manufacturing, and, again in life support, such as the control systems in nuclear facilities - or even coal-fired facilities, if they happen to have their output powering a pediatric ICU, any garbage collected language is unsuitable, since there is very little control, without infinite memory available, on when a GC will run. You can not implement hard real time in a GC'ed language.
For those applications, Java is unsuitable.
There are some languages suitable for those applications: assembly, C, Ada, FORTRAN, C++ (if you disable RTTI and certain aspects of polymorphism, and use an older version, rather than the current draft standard version). There are others, but they are infrequently enough practiced that they would be suspect, both in their mathematical provability, and in their ability to be audited for coding errors.
So No, any language is NOT as good as any other. Not even close.
Java was a GOOD language, because before we had C++.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
The basics still are wrong: generics still are slow and poorly implemented and Java still is bad for numerical apps.
A lot of medical devices are built using Java.
First Google result: http://www.oracle.com/us/technologies/embedded/embedded-java-for-healthcare-433550.pdf
It's been used in medical devices since the late 90's, shortly after it was invented.
For those applications, Java is purpose built.
After years of saying java didn't need C# features they go and steal tons of them from C#! Whether it's properties, lambdas, function pointers or async/await, the Java community has always insisted that those features weren't necessary and that Java was no worse for omitting them. Now they go and steal them and put them into their products and everyone will declare them innovative new Java features. Last month it was Apple stealing the "Metro" UI from Windows Phone. Now this. Is Microsoft the ONLY company doing anything innovative anymore?
Right, lets pretend Microsoft invented all of those things.
I'm a good cook. I'm a fantastic eater. - Steven Brust
What's the realistic alternative to Java? Java is good enough and the main gripe is that Oracle is loosing the trust that Sub Microsystems built up.
C# just isn't for political reasons. Financial institutions are very influential in programming languages becoming significant as they are the ones with deep pockets that hire huge amounts of -admittedly mediocre- programmers. So far all large to huge financial institutions I know bar Microsoft from entering their data centres.
So, what's the realistic alternative to Java that financial institutions will embrace?
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
A lot of medical devices are built using Java.
First Google result: http://www.oracle.com/us/technologies/embedded/embedded-java-for-healthcare-433550.pdf
It's been used in medical devices since the late 90's, shortly after it was invented.
For those applications, Java is purpose built.
This PDF is Oracle's "Markitecture" -- it's how they want things to work. They have not certified and indemnified their embedded JVM for use in life support systems. Don't expect them to. Don't expect a device manufacturer to bear the costs of certifying both the JVM and their application specific code, as a combination, for that use. IT's not going to happen.
Yes, my Java ring is in a box in my workroom... I do not wear it every day and do Green Lantern-ish stuff with it, like Sun was predicting would happen when they gave them away at Java One.
The fact is it's a bit of a self-propagating system. Kind of like it's current owner Oracle in general. Programmers who work in those environments persist their poorly performing "enterprise patterns" to the exclusion of other options. It happens in .Net too. I don't even blame the language so much as the developer ecosystem. I can't tell you the number of times I've seen in Java and .Net entire structures of Interfaces, and Classes, and Factories that which could be solved in a couple dozen lines of code in a single class. Sometimes the simpler, less enterprisey way is the better way. I even had friction from an enterprise architect trying to introduce automagic WCF client creation/registration in a solution that was already using Unity instead of explicit clients to the explicit service binding(s) implemented as a passthrough of the original interface. Fortunately, when I showed that it could be done wiring up a service binding with a single line, and the client with a single line in the config file, it was a much easier sell for the rest of the developers. Abstraction is awesome when it means less code, and less configuration. If that means writing an abstraction once to get that with all services, cool.. if it means having layers of crappy interfaces with only a single concrete implementation for no other reason, I'm less for it.
.Net and NodeJS... and I have to say, even without all the type safety and intellisense of VS and .Net, that I find NodeJS solutions, even relatively large ones (properly split up into testable, reusable modules) to be far nicer to work with than either Java or .Net have been. I'll take an application with a simpler codebase, with good unit test coverage any day. That's the difference of a platform more than the language itself.
I've spent most of the past year and a half with my time split between
Michael J. Ryan - tracker1.info
Try "debugging with print statements" when the codebase takes over 10 minutes to compile, and that's when the resources don't need to be re-processed. After you admit to that, the rest of the post can't possibly be taken seriously.
Right, lets pretend Microsoft invented all of those things.
If you had been following the language discussions for (for instance) lambda-J you would realize that there is a LOT more to it than simply deciding that a language must have this or that feature.
Specifically, both Java and C# are statically typed languages (although in C# a variable can be statically typed to be dynamic, but I digress) with advanced multi-generation garbage collection, structured exception handling, generics etc. Any new concepts introduced into the language must respect the concepts already there. Designing new features for Java or C# requires significant amount of innovation to solve the interference problems and maintaining the "feel" of the language.
LINQ is a real accomplishment, one that I have not seen put together like that in any other language. Yes, list comprehensions existed before. Yes, expression trees (ASTs) have been used in LIST and several other languages before. Don't know about extension methods, but I'm sure that there must be some research language. Yes, type inference had been used before. Yes, inferred classes must have been used in some language before. Certainly lifted types are well-known in certain other languages. But putting the whole package together and make it fit seamlessly with (and complement) the existing features and at the same time keep it so simple and generic that the useful parts are actually library features, that is a real accomplishment.
Reactive Extensions is real research (primarily by Erik Meijer who has regrettably now left Microsoft to return to academia). Not least because it ties to beautiful in with LINQ. It is entirely new? No, as Erik himself would say, IEnumerable is just a monad. IMHO that does not take away from the accomplishment.
Async and await are *really* cool and have inspired Scala to create something similar.
No, Microsoft didn't invent "all of those things". But fitting them in with a curly-brace, statically typed language is real innovation.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Still, the platform itself is enormously powerful and well supported in software and hardware which is why it is so popular in the enterprise. It's stable, it's scalable and it's portable.
no, all you "know" is that there is a method called "add" on the object named 3 that is being called with the parameter 5.
So the 'add' method could easily carve 3 and 5 on a tree. You have no way of knowing what it does just from the method name. The classic example is string::add(). Does "hello".add("world") produce "hello world" or does it only apply to "3".add("5") to produce "8"? You may criticise operator+ for this reason, but note that the add() method is just as bad.
So there is no difference between the operator+() method, and the add() method (except the name chosen, and the way its written by the developer).
Now we've established that there is no difference between the two, we can say that as normal humans are the ones that read and write code, the former, operator, mechanism is easier to read, write and understand, then it is the one that should be preferred.
I don't think there's much in Java the language that encourages over-engineering; it's more in the community that surrounds Java. It's in the tutorials, and books, and code examples and discussion groups . It's in the frameworks and libraries.
Indeed. The C++ world used to be like that. The sort of people who read the treat the design patterns pook not as a useful guide and taxonomy but as a way of life. They used to do the same stuff in C++ with massive class heirachies. I think they tend not to be very good programmers and they migrated en-masse to Java since it has fewer pitfalls. The C++ community has changed considerably since then and the modern style is very different.
I don't think that really says anything about the C++ language or the Java language. As a dyed-in-the-wool C++ programmer, going over to Java, I was firstly not at all surprised by the legendary overengineering, but was surprised that there seemed to be nothing in the language making people write overengineered code.
Don't get me wrong. It's not my favourite language: I find it a little dull and a little verbose, but it does not seem to be bad.
It is my understanding that since many of those programmers left perl for other languages perl has been remade as "Modern Perl" which is largely the same core language, just with a different and libraries, and is quite readable.
Much the same thing is happening in C++. The community (myself included) went mad with excessive template metaprogramming shortly after the mad with design patterns crowd left. It all seems to be calming down and the modern "Stroustrup style" (as it's known and given the name given to it is probably not all that new) of basically doing the sensible thing seems to be slowly taking over.
SJW n. One who posts facts.
Java was a GOOD language, because before we had C++.
One of my favorite definitions: "Java is like C++. But without the mace and knives."
So, 6,000,000 orders per second on a single Java thread on commodity hardware isn't good enough for you?
http://martinfowler.com/articles/lmax.html
Java does major heavy lifting, and is extremely fast, if you know what you're doing.
You can try to make minor parts of the program faster by calling C++ via JNI, but you risk harming performance in the long run, because then the JIT compiler can't inline or otherwise optimise that part of the code.
Of course, you can make any language slow if you mess up enough.
Benchmarks have been done and Java can often out-perform C (and C purists will point out that C++ has its own inefficiencies). The reason being that in addition to garbage collection, modern-day JVMs often "waste" time analysing code execution and re-optimizing dynamically, which is something that C cannot do.
A lot of things that are more efficient done small-scale become relatively less efficient when done large-scale. So much that the large-scale applications can actually benefit even further from processes that would be prohibitive on the small scale (such as on-the-fly re-optimization).
Even memory management can sometimes be more efficient when garbage-collected if the dynamic memory base is large enough and organized in the right way, replacing thousands of small memory transactions with one big one that reclaims whole blocks of memory at a swoop.
There's simply no one absolute answer. Only fools look for silver bullets or the One True Religion. But Java found its niche in high-performance, high-reliability backends and so it has received a lot of attention over the years towards making it handle that sort of stuff well.
That's not over-engineering so much as a lack of decent functionality in the JDK. Having things just work right out the box is one of the things I miss the most after I switched to java.
Java is over-engineered in large part because it's used on large-scale projects where the quick-and-dirty approach doesn't hold up. From time to time, I've had to chastise people for attempting to use J2EE for stuff that doesn't deserve to be written in anything more complex than PHP.
Then again, Sun made some really wretched design decisions. They're (as Oracle) now about to institute the third attempt to get dates, times, and calendars made easily usable. Although part of what made the first attempt so bad was that they DIDN'T over-engineer it. When you're programming for the World-Wide Web, you need support for multiple timezones and things like countries which use lunar calendars.
But how it's compiled isn't part of the language, it's part of the tool-chain. PHP is an interpreted language, unless you work at Facebook, where they have this compiler that turns PHP into C, after which, you can easily compile it to a native executable. Which was kind of my point. When you say you want to use C, Assembly, Fortran or Ada for those applications, what you're really saying is you want a language where the existing tool chain supports compiling down to machine code. You're actually choosing based on the tool-chain, and not on the actual properties of the language itself.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
As someone who mainly does C++, I have to whole-heartly agree with you. There is no silver bullet when it comes to the world of high performance transaction processing systems. 9/10 times, it is not the actual speed of the system that really dictates which language should be used, it is peripheral requirements that can make one language over another a better choice (i.e. does your development/support staff have more experience in one language over another so minimal training required). 15 years ago, I would have said that Java was more than likely not the best choice (note: not the best but more than likely capable) but not any more. The JRE has improved sooooo much that it can run neck-n-neck with unmanaged code in most environments.
Benchmarks have been done and Java can often out-perform C
Cite? I've often seen that claim but don't recall many benchmarks. Maybe somebody found a ten line loop that a JIT optimizes the hell out of, but I'm very skeptical that Java can regularly outperform C.
Lies, Damn Lies, and Benchmarks, as they say. Actual mileage may vary. For short runs, the sheer overhead of setting up a JVM puts it out of the running. For server systems running more or less continuously, the startup time becomes negligible. Loop optimization is probably not one of the things that Java can optimize better than C. On the other hand, on a lot of systems, there's a significant difference in the amount of time that it takes a conditional branch instruction to take the branch versus going straight. A C compilation produces static code and if the worst-case optimization (branch taken) is selected, that's the end of the story. A JVM monitoring performance can detect this sort of thing and rewrite the code to minimize the number of times the branch is taken. Needles to say, a 10-iteration loop run once a day isn't going to benefit, but a routine that runs millions of times an hour will.
For some actual numbers, I asked my friend Google and managed to find some cases where people did a head-to-head with a greater or lesser degree of honesty (Lies, Damn Lies, ...).
Here's one:
http://keithlea.com/javabench/
A Wikipedia discussion, for contemplation by those who don't knee-jerk reject Wikipedia:
http://en.wikipedia.org/wiki/Java_performance
And something a bit more scholarly:
http://scribblethink.org/Computer/javaCbenchmark.html
And something from IBM on Java's memory-management performance:
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
Something I read a while back and cannot recall now asserted that Java won most of their benchmarks except for those involving floating-point numbers. The reason being that C could use the processor's native FPU, but Java's "Write Once/Run Anyware" requirements forced it (unless overridden) to use IEEE Floating-point, which often had to be done in software.
IBM is a big Java proponent. The modern zSeries machines include 2 FPUs. One for the original, rather strange S/360 FP format and the other for IEEE. Not a co-incidence, I suspect. Reminds me of how a group of Honeywell engineers got together with an OS that had been written under government contract for NASA (thus available for public use), and designed a computer whose instruction set was optimized to run FORTRAN. They called they company Prime Computer.
True. CPUs do roll over.
And thinking of it (and correcting myself): Ada does for unsigned typed as well. Not for signed. There a RANGE_ERROR is raised. Strange but sometimes useful asymmetry.
But that does not invalidate my statement. All CPU I know of (there might be others, more exotic CPUs of course) set a carry and/or overflow flag on signed and unsigned roll-overs as well. One does not exclude the other here.
In 8 bit times those flags where extremely important to do 16 bit operation with only an 8 bit arithmetic logic unit. That is why it is called carry flag. And of course you can branch on the carry flag set or unset.