Slashdot Mirror
Everything About Java 8
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."
After all the security vulnerabilities patched this year, I would think they're feeling the pressure to make sure there isn't a repeat.
The Blade Itself
This is about Java the language, not Java the browser plugin. You should know the difference by now...
This is about Java the language, not Java the browser plugin. You should know the difference by now...
I've been misinformed then, I thought the security vulnerabilities in the java plugin were inherited from vulnerabilties in the way the language itself handled data. Someone mod up the guy above.
The Blade Itself
Highlights of Java 8 include
Green solutions. Advanced power management features, and automatic tracking of each thread's carbon footprint. An console allows users to see the carbon footprint of each thread in real time.
Social networking. Users can share jar files on social networks, and like their friends jar files.
Cloud computing. Java 8 will be the first VM built for the cloud.
I say we start a pool on how many zero days will be availible by the time it launches or even if we want to be generous, within the first week.
I will start it off with 7
For non trivial programs Java does not use more memory than an equivalent C++ program.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Get your head our of your ass. Java is one of the most widely used programming languages. Just because you don't notice it on your desktop doesn't mean it isn't used.
For non trivial programs Java does not use more memory than an equivalent C++ program.
Only if the large majority of your data is in non-object arrays, or in very large objects so that the headers and overhead are small enough.
Ezekiel 23:20
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Not exactly. Java is unable to vectorize floating point operations now (might change with java8 though), which is very common in any multimedia application. So it remains a lot slower than what you get by default in C/C++ with a decent compiler.
Video of some good progressive thrash music
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?
"First they came for the slanderers and i said nothing."
Probably. Server side Java (where it is used mainly) is pretty much reasonable security wise.
Why would anyone enable Java in a browser is beyond me.
Actually, once you get used to Swing it is pretty hard to go back to any other toolkit. Swing is amazingly powerful, and ever since Java 1.6.0u10 also very performant (since it is based on Java2D which is DirectX accelerated on Windows and OpenGL accelerated everywhere else). One thing you do have to be aware of with Swing is not to block the "Event Dispatch Thread". Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'.
With the Nimbus Look & Feel the look of Swing is pretty awesome. Of course, many Swing developers have or are transitioning to Swing;'s successor, JavaFX 2. JavaFX 2 looks amazing (lots of special effects, gradients, transparency, reflections, animations etc that can be switched on very easily). JavaFX 2 does have a slightly different model for properties than Swing, so there is a bit of an impedance mismatch when you embed Swing into a JavaFX 2 UI or vice versa.
I understand many don't like the learning curve of Swing, and some of the overheads (eg. TableModels) - but it turns out these abstractions are necessary for users to be able to make custom controls (which is easier, IMHO, than other toolkits as you get a lot of control on how your custom will work exactly how you want it to).
The best thing about Swing, IMHO is not even the enormous capability for extensions. For me the best features is not only to have pixel-precise layout, but also you can make the UI resize *exactly* the way you want. While I like GWT and CSV for web stuff when I use them I always miss Swing as the later us able to work out the correct size of controls itself, and resizes exactly the way I want it (that's due to a problem in browsers computing layout [which the GWT guys called "intractable" in the browser; but Swing shows this is not the case on the desktop]).
There is a lot of life left in Java desktop technologies. I'm having a great time using OpenGL (via JoGL) in Swing to produce a modern jet combat flight sim. The ability to mix Java controls and 3D saves a lot of work (most 3D apps have to implement UI controls themselves - so end up behaving non-conventionally and looking a little odd).
How exactly does it screw with compatibility? Old code will still compile. Old compiled classes will still load.
They're adding new stuff. Nothing old is being changed or removed.
You don't *have* to re-write anything. If someone tells you so, its because they want to.
It only screws with IT departments because they fear change. They also seem to not want to install security updates either.
The only JVM upgrade problems I've experienced in the last 10 years was with legacy code written for IBM's 1.3 JVM because the developers at the time thought it was a good idea to refer to com.ibm classes.
No Java itself is used in so many places. Your phone probably uses it for a start. From the cheapest old fashion Nokia candybars to the latest Android smartphones to a whole host of embedded systems around the place and various webservers. They all use Java extensively and they never have an issue with the language.
Unfortunately there's a particular Java plugin from Oracles version of the Java VM that insists on running every Java program your browser comes across. You wouldn't run a plugin that runs every compiled executable you come across would you? Well Oracles Java plugin tries to run every Java applet it comes across. That's where these security flaws you hear about come from.
So Java as a whole is having its name tainted by one particular plugin.
C++ is unable to perform comprehensive escape analysis (good for optimising multi-threaded code). C++ also lacks the ability to optimise virtual method calls.
Java can inline non-final methods and undo it if required.
There is a *lot* of stuff you can do when you have runtime optimisations as well as compile time.
You're technically correct in the Java is not compiled to machine code. The JVM does the bytecode to machine code compilation.
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.
You don't need to wait till an object is garbage collected for non-memory resources to be closed. You call the close method (in a finally block, or use the try-with-resources introduced in Java 7)
The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.
If keeping bytecode in memory was really a deal breaker, there is nothing stopping the use of memory mapped files.
First, the compiler algorithms are virtually identical in both cases, save for the expansion of method calls (vtables vs. multiple types of inline caches). Second, GC hardly affects overall speed if it's good enough (Azul Zing). The problem with Java's memory model is more about the lack of developer-controlled locality - if everything is an object accessed by reference, you end up with a lot of tiny pieces scattered around your memory. There's both size and speed overhead to that, no matter whether the whole thing got malloc()ed or allocated by a bump-a-pointer allocator with GC.
Ezekiel 23:20
After all the security vulnerabilities patched this year, I would think they're feeling the pressure to make sure there isn't a repeat.
Normally one would think that, but this is Oracle we're talking about.
> Has it stopped being an overly-verbose, memory-hogging, slow, insecure pain the ass?
FTFY
Sounds like you got screwed.
I'm a good cook. I'm a fantastic eater. - Steven Brust
You wouldn't run a plugin that runs every compiled executable you come across would you?
Sadly, I have Flash installed. I think its track record is almost as awesome.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Project Lambda from what I have gleaned has as its goal not necessarily feature parity with other programming languages, but instead speeding up certain multicore computations. It is therefore an experiment, and as its coding is not done yet, no one can be sure whether the experiment will be a success. What if the speed-ups simply don't happen once the implementation is finished? Given that Project Lambda may already be delaying some of Java 8, even though it was supposed to be the focus of Java 8, why couldn't Project Lambda be dropped if the experiment fails? There already seem to be so many compromises with the syntax compared to other languages that usage of Project Lambda may not be intended for general programming. Face it, the time to put in the equivalent of Project Lambda was near the dawn of Java, not trying to retrofit it at such a late stage. Perhaps it would be better to shelve it indefinitely as the community never had its heart in the concept.
Java has one feature that C# doesn't. This one feature makes up for all the nice-to-have little C# features. That one feature is "portability", not only of the language, but even more importantly, *all* the standard libraries. Mono goes some way to alleviating this but there are some significant libraries that Mono haven't developed and also state (according to their own pages) that they will never develop. I don't know if you have noticed it yet, but the Microsoft is just one platform in the World - and the number of platforms is burgeoning. Apart from a few platforms Java is locked out of deliberately (iOS, Xbox) Java runs pretty much whereever you need to be - with very very little porting necessary (eg. through judicious use of libraries, like JoGL,JOAL, JInput a jet combat simulator I'm developing runs not only with unmodified source on Windows+Mac+Linux+[and some tweaks for Android]; but actually runs without needing a recompile ! [I know it is not true for everyone, but for me, "Write Once, Run Anywhere" really works - even for a very complex multithreaded OpenGL/GLSL real-time application]).
I hope that sheds some light on why some of the Java devs still use it. The nice features of C# don't necessarily make up for Java's awesome portability of *all* its libraries.
Ever since autoboxing was added, it's already implicitly overloading operators for all of the object wrappers around atomic types anyways, and it's always implicitly overloaded the + operator for the String object, so the objection that it adds complexity should not be an issue. The only real remaining objection about unreadability that always seems to arise when the subject of operator overloading on user-defined classes is raised is actually entirely isomorphic to complaints about function or variable naming practices where the identifer's name doesn't effectively convey any sense of what the identifier's real purpose is... Java doesn't stop a programmer from using global class name like qxj, for instance, so it makes no sense to prohibit operator overloading merely on the suggestion that the resulting program is harder to read or maintain (and even then, such an identifier may even have a legitimate purpose in certain contexts.... but then, so can operator overloading, which is my point)
File under 'M' for 'Manic ranting'
Java 1.6 is the engine for java ee servers such as IBM websphere and tc server. there are still patches for 1.6 coming out, we just installed some at work recently for both the IBM and "Sun" (oracle) jdk
in fact, java 7 is optional add-on for websphree 8.5
No, the vulnerabilities are in Java, not the plug-in. (In Oracles JVM, the Android JVM will have its own, disjoint set of vulnerabilities).
It's just most places Java runs don't have an exposed surface to attack. Server-side Java has had tons of vulnerabilities patched so far - but it was rarely urgent to apply the patches, since there's no access to that JVM from off the box.
The browser plug-in was the way the JVM flaws were eposed, but it was the JVM that had the flaws (OK, the plug-in also has its own set of flaws, as well, but not so many).
Socialism: a lie told by totalitarians and believed by fools.
does it break backwards compatibliity with 7, like 7 did with 6?
that's been one of my major gripes about Java, write once, run anywhere until the jvm version changes, then you can be screwed.
Apparently, these lambdas don't even form real closures, their free variables can only be final ones.
If Java was so fast why do all the high performance libraries for things like multimedia not use it?
There are pure Java codecs. They work fine. It is not the C++ that is necessarily fast, but the inline assembler you can put in. In fact, the perfect analogy of using native libraries in Java is when C++ is too slow and you use inline assembler. In both cases you use a higher level abstraction for the huge productivity boost and switch to the lower level abstraction only when you really have to (which is become more and more rare these days) - when you are prepared to sacrifice portability for performance (on a single target). After doing C++ for nearly two decades I hate going back. Java is always my first choice unless I have some other reason (which is getting more and more rare these days).
I write multithreaded C++ code with Qt all the time. It is absolutely trivial. What is supposed to be tricky?
Resource management in a non-deterministic program. Releasing resources neither too early nor too late is problematic. For large data sets this is a problem (I don't know whether you are near the memory limits of your machine, or have smaller programmes) and is why very many modern environments use garbage collection to take the burden of the developer (especially as programs go from large, where any technique can work, to huge).
Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'
heh ... laughing from insanity? I think this sums up my experience with Gridbag. I ended up switching to Mig Layout which was a paradise compare to Gridbag. It actually made Swing work fun.
When people talk about benchmarks in terms of faster they mean performance not development. In terms of development time, Java gets crushed by much higher level languages. As for projects that aren't CPU constrained but constrained by something else, you are just saying you don't care about performance. That's wholly different than Java having C like performance.
As for multithreaded, C++ is obviously faster. If you want non tricky multithreaded languages like Haskell or Eiffel crush both of them.
And no on a single thread Java is not comparable. It generally is in the range of 1.5-5x slower. Which ain't bad at all, but I have yet to see any situation in which it is faster.
Let me try to explain it:
Java (The language and vm) does in general allow code to do anything. Mess up the system, call native methods and so on. In this it is no different from other languages such as c++ and php, which is why no one are running c++ og php directly in a browser*.
But sun wanted to be able to run Java code in the browser, so they made an security manager, which in principle allow you to specify exactly what parts of the java standard library a program should have access to. So you can restrict file access, to specific sub directories. Control thread and process control, class loading and so on.
So each call to a potential dangerous method first goes to the system manager to ask for permission, and if permission is granted the rest of the method is executed. And here is part of the problem: Default for all methods is access granted if there is no call to the security manager.
So for every method in the Java library, they had to determine if it could me misused, and it it could be misused, they had to insert call to the security manager to verify that the user have access to use this method in this way based on the arguments to the method.
And just one method which don't verify its argument as good as it should is enough to grant access.
The problem is made far worse by the combination of the java class loader which loads classes dynamicly, and the java reflection api which allows dynamic class loading and method calling. Verifying that code can't use the reflection and class loader to bypass the security system is really difficult, as proved by the many security problems.
So when people say the problem is in the java browser plugin, they are not exactly right. The problems are in the java security manager, but I think the browser plugin is the only component which uses the security manager. Our server code for example don't need a security manager to control exactly what our code have access to, because the code is written by guys we trust, and the rest of the security is handled by the system.
*Or at least should not. Active X is Microsofts version of the "Try to run untrusted general purpose code in the browser project". And its security record is as bad as javas.
Well you can't say Java has flaws and then detail one particular set of flaws in one product. Even then your claims that the flaw is in the JVM is doubtful. I can right now load up a Java program in Oracles JVM and delete my files off my hard drive. I can also straight up spin up 100000 busy threads and bring my machine to a crawl. Are these flaws? Of course not. I can do the same thing in C++.
The flaw is allowing the browser plug-in to do things it shouldn't. The JVM itself is supposed to allow you full functionality including the ability to shoot yourself in the foot. The flaw is the fact you've exposed the JVM to the outside world. The Applet Plug-in tries to limit this functionality but fails. That is not the fault of the JVM.
Bro, your 1.5-5x is just not true unless the Java was written by idiots (and as we old timers remember the chestnut, "You can write bad FORTRAN in any language"). Even in 2008 Java was beating C++ and approaching FORTRAN for speed, citation follows. Now you can cherry pick whatever benchmark you want and it will show C++ as faster, and I'll choose another benchmark and that will show Java as faster. That means they are about on par with regard to performance (that wasn't true in the past, but is true today).
Here's the citation about the "Current State of Java for High Performance Computing", written in 2008 (the JVM has got *much* faster since then):
http://blogs.oracle.com/jag/entry/current_state_of_java_for
Please note that the report was written by INRIA, the French Scientific Supercomputing outfit - it is not a fluff whitepaper from a vendor (who will lie to make sales). If you can flaw the INRIA paper I'd be very interested to hear why you are right and they are wrong.
When people talk about benchmarks in terms of faster they mean performance not development
If your development time is so long the project stakeholders may cancel it. That is the major cause of software development failure. If you time to develop is long your time to market is also long. That can mean missed opportunity and even business death. So the long development time might be appropriate for the toy QT programs you develop, but it completely blows for large commercial projects where you have a big team and the set of people who start a project may not be the set of people who finish (people get pregnant, get sick, get promoted, all sorts of stuff). Once you start looking past just the purely technical stuff you have quite a different view of technology. That's why few people choose C++ to start a project these days.
In terms of development time, Java gets crushed by much higher level languages.
I find that most of those higher level languages tend to be fairly good at one domain. They are faster to develop in, if you are doing the problem they were designed to solve, and then they suck. The runtime performance of higher-level language blows. eg, Groovy, Ruby, Python are not in the same league as C++/C/Java/C# etc. For most modern applications it simply doesn't matter anymore, because you are waiting for a database, or the network, or user input (**slow**), or the GPU, or the memory bus, etc etc. It is only if you are stuck doing batch operations that it really matters. Now I'm waiting for you to say, "but, but, multimedia!". The reality is that multimedia should be done in hardware. I use Java+JoGL+OpenGL for this. This destroys C++ (or any other software implementation) for performance. Horses for courses my friend. That's why few people use C++ anymore - we understand it well (used it for decades) - but realise that implementing a new commercial application with it is just duh stooopidd.
Not over yet, actually. If Oracle had really learned their lesson they wouldn't have appealed. I doubt they will win, but as I said it's still not an encouraging move.
But yeah, OpenJDK is not going anywhere, and the support behind it dwarfs even Google's resources...
The thing is that applets should die. I am a java dev. But i don't understand this big deployment on the web push. C/C++ don't have it and do just fine. I have applets/ws disabled long before this list of security issues.
If information wants to be free, why does my internet connection cost so much?
Well, you got a +5 :) but your assumptions about a security manager works and how amd where it is used: are completely wrong.
It is trivial to write a Java Application thatbuses a security manager and thus, e.g. restricting it from accessing the internet or certain parts of the file system.
Your idea that dangerous methods call the security manager is completely wrong. The VM calls the security manager before said method is executed.
Your assumption that the VM inserts the security manager code is wrong. See, for instance, the source code for java.io.FileInputStream(File). You can clearly see starting at line 128 and continuing to line 131 that this check is performed by the library, not the VM. Similar code is present throughout the Java standard library.