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.
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.
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.