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.'"
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.
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.
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.
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.
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*
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.