Forgot your password?
Java Programming

Everything About Java 8 233

Posted by Soulskill
from the building-a-new-generation-of-security-holes dept.
New submitter reygahnci writes "I found a comprehensive summary of the developer-facing changes coming in Java 8 including: improvements to interfaces, functional interfaces, lambdas, functions, streams, parallels, date/time improvements, and more. The article includes example code with realistic examples of use as well as explaining the reasoning behind some of the choices made by the developers who are working on Java 8."
This discussion has been archived. No new comments can be posted.

Everything About Java 8

Comments Filter:
  • Changes (Score:4, Interesting)

    by phantomfive (622387) on Wednesday March 27, 2013 @06:21PM (#43297445) Journal
    There is a real, major benefit of using Java over other languages, such as C or Haskell or Smalltalk, which is this: it lets you work with other mediocre programmers, and has limitations that prevents them from doing anything too crazy. That is, even if they write horrible code, it won't be so bad that you can't work with it (I'm sorry fellow Java programmers if that offends you, but think of where Java is used most).

    That said, I'm somewhat concerned about some of these changes. Lambda functions are great, but one of the benefits of functional programming is the lack of side effects. Under the Java 8 design, lambda functions allow you to modify member variables, which means that benefit is completely gone. This means lousy programmers will be able to write incredibly complex code, with strange side effects, that is hard to use.

    The new streams functionality is fine, but did they really have to call it streams? When there are already Streams in Java?

    String.join() is great. Finally.

    The new Date library looks fine. It better be good enough, because do you really want yet another Date system added into Java?
  • Re:LOL Java (Score:5, Interesting)

    by SplashMyBandit (1543257) on Wednesday March 27, 2013 @07:00PM (#43297795)

    That's because Java is still magnitudes slower.

    I'm afraid I have to disagree. I'm writing a modern jet combat simulator in Java and the runtime speed is fine. The bottleneck is never the CPU, it is always the GPU. I also have to say that Java's performance in terms of latency is very good. The reason for this is because I'm able to create a lot of threads very easily and Java manages resource sharing very well, plus use of the language features for synchronization threads and I get to use around 20% of each of the eight cores on my machine. When I use an excellent product in a similar niche called DCS:World I do notice that it's speed is somewhat hampered by the C++ running on a single core. Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.

    So I think your comment is not correct. Java is comparable to C++ (sometimes faster, sometimes slower) on a single thread. When it comes to overall performance I find Java is faster overall because it is much easier to utilize all the cores in a machine with Java. In terms of gaming the performance of programming language used is nearly irrelevant - it is all down to how well you use the GPU (especially GPU memory; if you can keep stuff in VRAM then your performance is awesome).

    Finally, let's move from the speed that is not that relevant (runtime) to the speed that actually matters (development time). Java is much much faster to develop in. You do have to spend some time profiling and tuning a Java program, but since you spend far far less time debugging than C++ you are still winning. I also love the JVisualVM that comes with the Sun/Oracle JDK and OpenJDK. While C++ has profilers they are a hassle to use, you have to compile your program each time you want to profile and recompile to measure different metrics. With JVisualVM you can profile any Java program without source and without recompilation since the monitors are built into the JVM (in exactly the same way as performance counters are built into operating systems these days, accessible by dtrace, strace, truss etc).

    So, I think C++ is best used in niche programs where the host environment measures its memory in kilobytes. For other applications Java is more than fast enough on a single thread, has better throughput on multi-core machines, and is *much* faster to develop in (saves money, and also means something gets delivered sooner, as in, "faster time to market"). That's why Java kicks ass on the Tiobe Index - even if users only know about it from Minecraft and browser plugin issues.

  • Re:LOL Java (Score:2, Interesting)

    by HarrySquatter (1698416) on Wednesday March 27, 2013 @09:52PM (#43298971)

    I'm afraid I have to disagree.

    And yet your anecdote doesn't really answer my question. If Java was so fast why do all the high performance libraries for things like multimedia not use it? Even the multimedia classes in Java's own stabdard library use native code libraries under the covers because pure Java would be too slow.

    Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.

    I write multithreaded C++ code with Qt all the time. It is absolutely trivial. What is supposed to be tricky?

10 to the 6th power Bicycles = 2 megacycles