Forgot your password?
typodupeerror
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:
  • Re:The important bit (Score:5, Informative)

    by Anonymous Coward on Wednesday March 27, 2013 @05:24PM (#43296733)

    This is about Java the language, not Java the browser plugin. You should know the difference by now...

  • Re:The important bit (Score:3, Informative)

    by p00kiethebear (569781) on Wednesday March 27, 2013 @05:30PM (#43296827)

    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.

  • Re:LOL Java (Score:4, Informative)

    by angel'o'sphere (80593) on Wednesday March 27, 2013 @05:46PM (#43297023) Homepage Journal

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

  • by Anonymous Coward on Wednesday March 27, 2013 @05:47PM (#43297029)

    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.

  • Re:LOL Java (Score:1, Informative)

    by Anonymous Coward on Wednesday March 27, 2013 @06:01PM (#43297235)

    After all: it gets compiled down to the same machine code ...

    No, it doesn't. C++ gets compiled into machine code. Java gets compiled into bytecode that is run on the Java Virtual Machine. Also Java uses garbage collection, which can slow things down.

  • by viperidaenz (2515578) on Wednesday March 27, 2013 @06:34PM (#43297581)

    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.

  • Re:The important bit (Score:5, Informative)

    by SpazmodeusG (1334705) on Wednesday March 27, 2013 @06:42PM (#43297635)

    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.

  • Re:The important bit (Score:3, Informative)

    by lgw (121541) on Wednesday March 27, 2013 @08:28PM (#43298475) Journal

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

  • by LordLimecat (1103839) on Wednesday March 27, 2013 @09:16PM (#43298795)

    They're adding new stuff. Nothing old is being changed or removed.

    Oh, ok, we'll tell that to all the apps that broke with JRE > 1.4.2u9 (ie, Cisco ASA crap). Or the apps that broke with JRE >1.5. Or >1.6u9.

    If you havent seen incompatibilities due to java upgrades, be thankful: it means that you havent seen much of java.

  • Re:The important bit (Score:5, Informative)

    by TheSunborn (68004) <tiller&daimi,au,dk> on Wednesday March 27, 2013 @11:54PM (#43299577)

    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.

How many hardware guys does it take to change a light bulb? "Well the diagnostics say it's fine buddy, so it's a software problem."

Working...