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."
This is about Java the language, not Java the browser plugin. You should know the difference by now...
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
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).
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.
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.
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.
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.
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.
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.