Java 8 launched

evilsofa

[H]F Junkie
Joined
Jan 1, 2007
Messages
10,078
Java 8 just launched.

As always, if you go to java.com, you'll get the installer that also installs crapware, but if you go to oracle's java page, you can get the clean installer without crapware:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

And also as always, not installing Java is great security advice! Except when you have to, as so many do, if they want to do job training, use banking sites, use government sites, and other such things that are so not essential to your life.
 
There are a lot of nice things in Java 8.

JavaFX is becoming the premier GUI toolkit and Swing is legacy.
Lambda expressions
Finally a standard API for Base64 encoding and decoding.
New date and time API
JDBC 4.2
Support for AES-NI cpu capabilities
Support for TLS SNI extension
AEAD CIpherSuites (i.e. AES/GCM)
Implemented the rest of the NSA Suite B algorithms

Honestly all the TLS updates are probably worth the upgrade by themselves.
 
hopefully they make it less prone to malware and virus attacks. I usually install Java for what I need it for then remove it afterwards.
 
Have they removed the nightmare which is trying to deploy and manage Java in an enterprise scenario? Version expiration of Java 7 was the worst feature, ever.
 
Have they removed the nightmare which is trying to deploy and manage Java in an enterprise scenario? Version expiration of Java 7 was the worst feature, ever.

Without any knowledge of what that is, it sounds like a reaction to a situation that was equally bad: enterprises that required you to run one specific version of Java, and only that specific version, in perpetuity.
 
Without any knowledge of what that is, it sounds like a reaction to a situation that was equally bad: enterprises that required you to run one specific version of Java, and only that specific version, in perpetuity.
It's not about what version, rather how often to deploy the upgrade. I have no problem regularly updating Java, I do have a problem with how Java is set to expire on a certain day and if you haven't got the new version out yet your users get locked out of their applications.

Even then, the options Java gives users to upgrade when it expires can screw up the installation and force manual intervention on each workstation (specifically users without admin rights hitting the expiration windows "upgrade now" button that cannot be disabled). Java deployment was never great, but at least it was serviceable with one time registry edits (either through a bat file or GPP's). With Java 7 and up it's become a nightmare of never ending testing and redeploying to stay ahead of the expiration date.
 
It's not about what version, rather how often to deploy the upgrade. I have no problem regularly updating Java, I do have a problem with how Java is set to expire on a certain day and if you haven't got the new version out yet your users get locked out of their applications.

Even then, the options Java gives users to upgrade when it expires can screw up the installation and force manual intervention on each workstation (specifically users without admin rights hitting the expiration windows "upgrade now" button that cannot be disabled). Java deployment was never great, but at least it was serviceable with one time registry edits (either through a bat file or GPP's). With Java 7 and up it's become a nightmare of never ending testing and redeploying to stay ahead of the expiration date.

Do you know about the DeploymentRuleset.jar file?
If you use this, then you can essentially have specific sites ignore the expiration. Just like you can have Java ignore the unsigned JARs for the domains you have configured in the ruleset.

We had to do this, because we couldn't decrease the security level to Medium. This was the middle-ground.

Previously with only the expirations and whatnot, we had hundreds of users that were at a work-stoppage due to out of date Java, and our patching platform not yet having the updated definition, plus time for us to test out the update.

No more will this be an issue.
 
Part of the security problem is the major revisions install parallel to older versions and as a result I've seen systems with version 5.0 on them alongside 7 update 45. There really needs to be an overhaul to the updater and awareness of these issues because Java has been the number one route of exploitation IME. The exception list is a great move but provides initial headaches. I hate Java guys, I really do.
 
You mean Java 1.8, right?
Why does Java ignore the preceding '1'?

Sorry - this has always bugged me. About as much as old Apple computers with a -single- mouse button. :D
 
You mean Java 1.8, right?
Why does Java ignore the preceding '1'?

Sorry - this has always bugged me. About as much as old Apple computers with a -single- mouse button. :D
Exactly! They need to get the version numbering right as it's another avenue of confusion. I'm at wits end with Java.
 
Part of the security problem is the major revisions install parallel to older versions and as a result I've seen systems with version 5.0 on them alongside 7 update 45. There really needs to be an overhaul to the updater and awareness of these issues because Java has been the number one route of exploitation IME. The exception list is a great move but provides initial headaches. I hate Java guys, I really do.

I think part of the reason for the updating installing along-side, is the fact that some Java apps require an older version, so you may still need the older version for Apps A and B, but app C can be run with the newer version.

As much as I always hear about "backwards compatibility" with Java, there's so many Java apps that we use that are not compatible.
Hell, we still have some users with 1.6 update 38.
Even our latest Citrix NetScaler web interface requires 1.6 update 31. And that version of the NetScaler VPX is less than 1 year old.
 
Lambda expressions

The Lambda expressions by themselves are a great feature to have, from a productivity and code readability perspective (I personally hated writing one method interfaces and instantiating anonymous classes in order to pass 'functor-like' behavior around), but the BIG feature is the collections' 'Stream API' for which Lambdas are often used.

Most importantly is the fact that it allows deeper abstraction when working with collections. For example, if I have an ArrayList of Employee objects, and I want to get all of the employees who have elections to contribute more than 6% to their 401(k) plan (Let's say the Employee class has a method getContributionAmount() which returns this value), I can do so as such:
Code:
List<Employee> employees = SOME_OTHER_STRUCTURE.getEmployees();

List<Employee> topRetirementSavers = employees.stream().filter(e -> e.getContributionAmount() > 0.06).collect(toList());

...instead of doing it the old way:

Code:
List<Employee> employees = SOME_OTHER_STRUCTURE.getEmployees();

List<Employee> topRetirementSavers = new ArrayList<Employee>();

for (Employee e : employees) {
    if (e.getContributionAmount() > 0.06) {
        topRetirementSavers.add(e);
    }
}

...or even worse:

Code:
List<Employee> employees = SOME_OTHER_STRUCTURE.getEmployees();

List<Employee> topRetirementSavers = new ArrayList<Employee>();

for (int i = 0; i <employees.size(); i++) {
    if (employees.get(i).getContributionAmount() > 0.06) {
        topRetirementSavers.add(employees.get(i));
    }
}

The new way of doing it is great because, for starters, it's a lot more expressive and is much easier to read. It's also a lot quicker to write.

But more importantly, it's a layer of abstraction. You don't care how it gets them, as long as it does so quickly and gives you the answer you want. Writing the loop isn't part of the problem you're trying to solve, and spending the time to write the loop is a waste of your time because it's a problem that's already been solved. There's no sense re-inventing the wheel if somebody has already done that for you. Also, if you do write the loop yourself, you've coupled yourself to that specific implementation of iterating. What if someone comes up with a better way of doing it? Maybe some distributed map-reduce software, like Hadoop could run your code very efficiently in parallel if you haven't already tied yourself to a specific way of iterating that wasn't even relevant to your problem.

The Stream API offers a lot of other nice features, too. Maybe with that same ArrayList of employees, you'd like to find out how much money in total is being contributed into 401(k) accounts by all of your employees annually.

Easy:

Code:
List<Employee> employees = SOME_OTHER_STRUCTURE.getEmployees();

double totalAnnualContribution = employees.stream().reduce(0, (s, e) -> s + e.getSalary()*e.getContributionAmount() );

The key here is that you don't care how iteration is done. That's not the problem you're interested in, so micro-managing the computer to get it to iterate the way you want is counter-productive. It's quicker to go to one of your analysts and say "Develop reporting for me on how much money we are spending on <blank>" instead of leaning over their shoulder and telling them how to do it and what to click on every step of the way. If your analyst is smart enough to do that on their own, you can be off doing other things. Likewise, there's no sense in having a developer do something the compiler or the language can do for them. The developer is an expensive resource, so you only want them to be spending time solving problems you actually need a developer in order to solve. If you let the software handle the things it can handle, you're saving money by saving a developers time. It's also more flexible, because your code is no longer dependent on how the iteration is done, and realistically you don't want it dependent on that anyways.

I am glad that Java is finally acquiring some modern programming features.

Have they removed the nightmare which is trying to deploy and manage Java in an enterprise scenario? Version expiration of Java 7 was the worst feature, ever.

I honestly have never had problems with this. How are you deploying/managing it? What workflow are you using to keep Java up to date on workstations? If you put the time in to make the deploying/updating automated, then doing it very frequently is painless.

You mean Java 1.8, right?
Why does Java ignore the preceding '1'?

Sorry - this has always bugged me. About as much as old Apple computers with a -single- mouse button. :D

No, he means Java 8, and he, like everyone else who follows this naming convention, is correct.

Java 8 is the name of the 8th version of the Java platform. The '1.8' versioning is for the developer side of the releases, which aren't relevant to consumers. Some files, such as JDK releases, etc. use 1.8 as the version name, but the official name for the platform is Java 8.
 
Last edited:
I honestly have never had problems with this. How are you deploying/managing it? What workflow are you using to keep Java up to date on workstations? If you put the time in to make the deploying/updating automated, then doing it very frequently is painless.

He's referring to the fact that, once a newer version is released, the previous version no longer allows you to run any Java apps with the default security setting of High.

We use LANDesk for security and compliance (aka patching) and it can take them up to 48 hours before they release the appropriate definition for the new version.
Then we have to test the patch, which can take another 48 hours before deploying it system-wide.
We have some users who rely on Java-based apps.
Not to mention the fact that unsigned Java apps cannot be run with the High security level.

So once the new version is released, we have hundreds of users who can no longer work, because Java's security "feature" denies the ability to run Java apps once the current version is no longer current.

Additionally, having HIPPA, we cannot just lower the security level to Medium as that then increases the risk of Java-based infection.

Luckily though, as I stated in a previous post, they assist in resolving some of these issues with the DeploymentRuleset.jar file which we are now using and it definitely has greatly helped with these issues.
 
He's referring to the fact that, once a newer version is released, the previous version no longer allows you to run any Java apps with the default security setting of High.

Yes, which is only a problem if you cannot get updates out painlessly. We could keep up with the security updates fairly quickly on the computers which we were responsible for, so it was never a problem for us.
 
I think part of the reason for the updating installing along-side, is the fact that some Java apps require an older version, so you may still need the older version for Apps A and B, but app C can be run with the newer version.

As much as I always hear about "backwards compatibility" with Java, there's so many Java apps that we use that are not compatible.
Hell, we still have some users with 1.6 update 38.
Even our latest Citrix NetScaler web interface requires 1.6 update 31. And that version of the NetScaler VPX is less than 1 year old.

Java IS backwards compatible, but I'm sure if you have code written shitty enough you can break it. To re-compile you just need to specify the version you want the source compiled to.

He's referring to the fact that, once a newer version is released, the previous version no longer allows you to run any Java apps with the default security setting of High.

We use LANDesk for security and compliance (aka patching) and it can take them up to 48 hours before they release the appropriate definition for the new version.
Then we have to test the patch, which can take another 48 hours before deploying it system-wide.
We have some users who rely on Java-based apps.
Not to mention the fact that unsigned Java apps cannot be run with the High security level.

So once the new version is released, we have hundreds of users who can no longer work, because Java's security "feature" denies the ability to run Java apps once the current version is no longer current.

Additionally, having HIPPA, we cannot just lower the security level to Medium as that then increases the risk of Java-based infection.

Luckily though, as I stated in a previous post, they assist in resolving some of these issues with the DeploymentRuleset.jar file which we are now using and it definitely has greatly helped with these issues.


So you are suggesting that the JVM is not backwards compatible because you have 3rd party software, or a set of rules you have to follow that prevents it from being backwards compatible?

JDK is backwards compatible. The JVM is only mostly backwards compatible (there are documented incompatibilities often the result of a security patch).
 
Last edited:
Java IS backwards compatible, but I'm sure if you have code written shitty enough you can break it. To re-compile you just need to specify the version you want the source compiled to.

uhhhh....
We rely on several 3rd party Java-based web apps.
One being cardinalhealth.com
It will not work on anything newer than 6 update 31 or 38. It just will not work and, from what I've heard from out desktop support, Cardinal even states that specific (old) version must be used.

Then, there's our Citrix NetScaler VPX web interface. This particular release of the NetScaler VPX was released by Citrix less than a year ago. The web interface is virtually unusable with anything Java 7 or greater.

We have other 3rd party Java apps and Java-absed web apps that just FAIL to work with newer versions of Java.
These 3rd party apps are also NOT custom-designed apps.

How can they claim backward compatibility when we have probably half-dozen apps that just will not work with newer versions? We're only 1 organization.

[/quote]So you are suggesting that the JVM is not backwards compatible because you have 3rd party software, or a set of rules you have to follow that prevents it from being backwards compatible?

JDK is backwards compatible. The JVM is only mostly backwards compatible (there are documented incompatibilities often the result of a security patch).[/QUOTE]

No. Even Oracle recommends leaving the Java security level at High. Yet, once Oracle releases a new version of Java, the previously-current and currently-installed version FAILS to load Java apps with an error that you need to update, unless you decrease the security.

I'm sorry, but even Oracle's own recommendation breaks shit when you can't patch 3,000+ machines the very same day they release a new version. And decreasing the security level increases the chances of explotation.

I'm not talking about JDK. We don't do any Java programming in-house. The only thing I use it for is to sign a DeploymentRuleset.jar file so that users won't end up at a work-stoppage when a new version is released.

But like I said, the DeploymentRuleset.jar fixes the Java apps failing to load due to out of date errors. We have excluded necessary sites.
It's the other Java-based web apps that still require an old version, despite "backwards-compatibility"
 
One being cardinalhealth.com
It will not work on anything newer than 6 update 31 or 38. It just will not work and, from what I've heard from out desktop support, Cardinal even states that specific (old) version must be used.

That's not a Java problem, though. That's a 'cardinalhealth.com is terrible' problem, if they're giving you such constraints. If cardinal health is a web application, they shouldn't be using Java for anything user facing (it sounds like the app's interface is a Java Applet, rather than a plain website). User facing interfaces should be served to the user as web (and I don't care how you accomplish this, be it that you serve your interface dynamically with Java EE or Java ServerFaces, or if you have a static website built in something like Angular.js which uses AJAX to interact with the backend over a REST API. There are many acceptable ways to serve a user interface for a web app, and serving a Java applet is not one of them). If the client side is stuck on a specific JRE version becauser of a web application, that web application is mixing service logic with presentation logic too heavily, and that's the cause of the problem. The web applications we develop at my workplace don't even require that the JRE be installed client side. They just need a standards-compliant web browser. The only place the JRE matters is server-side, and we're still flexible about that.

I'm sorry, but even Oracle's own recommendation breaks shit when you can't patch 3,000+ machines the very same day they release a new version. And decreasing the security level increases the chances of explotation.

Sure, but why can't you patch 3000+ machines in one day?
 
Last edited:
That's not a Java problem, though. That's a 'cardinalhealth.com is terrible' problem, if they're giving you such constraints. If cardinal health is a web application, they shouldn't be using Java for anything user facing (it sounds like the app's interface is a Java Applet, rather than a plain website). User facing interfaces should be served to the user as web (and I don't care how you accomplish this, be it that you serve your interface dynamically with Java EE or Java ServerFaces, or if you have a static website built in something like Angular.js which uses AJAX to interact with the backend over a REST API. There are many acceptable ways to serve a user interface for a web app, and serving a Java applet is not one of them). If the client side is stuck on a specific JRE version becauser of a web application, that web application is mixing service logic with presentation logic too heavily, and that's the cause of the problem. The web applications we develop at my workplace don't even require that the JRE be installed client side. They just need a standards-compliant web browser. The only place the JRE matters is server-side, and we're still flexible about that.

The backwards compatibility is broken, plain and simple. I don't care who's problem it is, there is no backwards compatibility if an app requires an old version of Java.
As I stated, Cardinal Health is not the only one. A less than 1-year old Citrix NetScaler VPX web interface also requires an old version.
At least a half-dozen total in our department alone (3,000 users out of.... >15,000)

Sure, but why can't you patch 3000+ machines in one day?

As I stated, we use LANDesk for patching. It can take upwards of 48 hours for LANDesk to release the updated definition. It can then take us another 48'ish hours to test.
We have sites covering the whole state.

First, some of these sites are on shared 56k connections; shared with dozens of users. We rely on LANDesk to retrieve the patch from peers rather than from a preferred server or the core, due to the insanely slow links.
Second, we don't want to deploy something to 3,000+ machines without proper testing, or we could be shooting ourselves in the foot.

How many organization push out patches the minute they're released, without actually testing? That's just plain stupid.
 
The backwards compatibility is broken, plain and simple. I don't care who's problem it is, there is no backwards compatibility if an app requires an old version of Java.
As I stated, Cardinal Health is not the only one. A less than 1-year old Citrix NetScaler VPX web interface also requires an old version.
At least a half-dozen total in our department alone (3,000 users out of.... >15,000)

Again, these are applications which were poorly designed and/or poorly written. If you follow best practices, your Java application won't require users to use old versions of Java.

Anybody can write terrible software, regardless of how good the platform is. Java isn't perfect, but it's good enough that you can write software that isn't subject to such asinine requirements. If you gave these same incompetent developers something else, like the .NET Framework or native C++, they'd still be writing code that wasn't 'backwards compatible'. It's them, not Java.


Believe me, I'm usually the first person to complain about Java. There's many things I think Java is lacking in and many things I don't like about Java. But this isn't one of them. There's nothing stopping someone from writing an application that doesn't suck.

As I stated, we use LANDesk for patching. It can take upwards of 48 hours for LANDesk to release the updated definition. It can then take us another 48'ish hours to test.
We have sites covering the whole state.

Well that's a LANDesk problem, not a Java problem. When I used to do this stuff (before I moved into software engineering), we organically developed our own solution to handle this stuff, which gave us the flexibility to automate and rapidly deploy software changes to all of our OUs. If we could do it, that means people selling a product should be able to do it just fine.

If LANDesk isn't cutting it, then LANDesk isn't cutting it. That has nothing to do with Java. If I can create and support code to handle this process well, they should be able to as well. Again, the right answer here is that LANDesk should figure out how to do a better job, or you should find something other than LANDesk. Leaving highly vulnerable vectors un-updated because LANDesk is holding you back isn't the answer.

Since other shops can deploy Java updates more quickly, easing the security of Java because your organization can't doesn't really make sense. Blame LANDesk, not Java.

Second, we don't want to deploy something to 3,000+ machines without proper testing, or we could be shooting ourselves in the foot.

Proper testing can be automated.

How many organization push out patches the minute they're released, without actually testing? That's just plain stupid.

I'm sure there's plenty who do it. That's not what I'm advocating though. The ideal thing to do is automate the deployment of updates, create an automated testing scheme, and streamline the process to the highest extent possible. Certainly you want some amount of manual intervention required (such as verification that tests pass before starting the deployment), but only what's really necessary. A good system administrator is too expensive to pay to update computers....I can use a system administrator's time better elsewhere, and the computers can handle updating much faster than a system administrator can update them.
 
Last edited:
I have previously noted that if an inattentive family member ever allowed the Java updater to install Ask, the Java updater would always prompt to install it again, even if I installed Java using the Ask-free installer from Oracle instead of java.com. There's an option somewhere that gets permanently flipped to allow this shenanigan to happen, but how do you turn it off? Not in the Java Control Panel.

The answer comes courtesy of this superuser thread. Here I partially quote the best answer (other methods of doing the same thing are listed there):

Copy and paste the following code into a text file called disable_java_sponsors.reg and double click on it to import these values in your Registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft]
"SPONSORS"="DISABLE"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft]
"SPONSORS"="DISABLE"
 
I honestly have never had problems with this. How are you deploying/managing it? What workflow are you using to keep Java up to date on workstations? If you put the time in to make the deploying/updating automated, then doing it very frequently is painless.
Deploying it is easy. The problem is you can't always update to the latest version because apps may not be fully compatible. What this leads you with is the Java expiration date warning prompting users to update. If a non-admin clicks update, they get a botched install.
 
If a non-admin clicks update, they get a botched install.

They shouldn't be able to break their install by doing this. If they can damage the install as a non-admin, your permissions need to be tightened down.
 
Do you know about the DeploymentRuleset.jar file?
I looked at that a little bit. The problem is when you are running 3rd party Java utilities that are often updated without your knowing. Then you're right back at square one. Why on Earth Oracle won't simply give you a Boolean that you can change in the Java MSI is beyond me. It would be so much simpler.
 
I looked at that a little bit. The problem is when you are running 3rd party Java utilities that are often updated without your knowing. Then you're right back at square one. Why on Earth Oracle won't simply give you a Boolean that you can change in the Java MSI is beyond me. It would be so much simpler.

Examples?
Since we started using this, we have not yet had any issues.
We simply whitelist the full domain that the apps live on.
Although, we have very few users with multiple versions installed for different apps; so I don't know how effective that part actually works (ie designating domain1.com to use 6u38, everythign else use 7u51)

Also depending on your security requirements, you could set the security level to Medium using the Deployment.Properties file instead; either at the user level or machine level. Of course this also increases the security risk.
 
We simply whitelist the full domain that the apps live on.
I didn't see that. I only saw finding the file specific hash and whitelisting that, not the domain the file is coming from.

I didn't see anything on the help site about disabling the expiration either. It said you can, but there's no list of the setting. I've had to do it through deployment.properties, which does work, but the settings only take effect after the 2nd time the app is launched. If you want it to take effect the first time the app is launched you need the .cfg file on the computer before you install Java. If you try to add it later the app must be launched twice to take effect. By that time the user could of clicked "update" and corrupted the install of Java.

If they let you disable the expiration and set security in the MSI (or with a mst) it would solve so many problems.
 
I didn't see that. I only saw finding the file specific hash and whitelisting that, not the domain the file is coming from.

I didn't see anything on the help site about disabling the expiration either. It said you can, but there's no list of the setting. I've had to do it through deployment.properties, which does work, but the settings only take effect after the 2nd time the app is launched. If you want it to take effect the first time the app is launched you need the .cfg file on the computer before you install Java. If you try to add it later the app must be launched twice to take effect. By that time the user could of clicked "update" and corrupted the install of Java.

If they let you disable the expiration and set security in the MSI (or with a mst) it would solve so many problems.

Code:
  <rule>
	<id location="sas.elluminate.com" />
	<action permission="run" />
  </rule>

If this rule is in your DeploymentRuleset.jar, then users will be able to continue to access those Java-based Blackboard apps even after Oracle has released the next version. It essentially decreases the security level to Medium on the sites you identify.

At the very bottom I then have
Code:
  <rule>
    <id />
    <action permission="default" />
  </rule>

Which means that any site not identified will run with the default settings (unsigned jars won't work, can't run signed jars after new version is released, etc)

Now, I cannot confirm the actual expiration date as we don't have any users stuck on an old release of 7. Although it looks like we will find out on April 15 or 16 (since expiration date is the 15th for 7u51 and 7u60 has not yet been released.)

We currently have 9 domains whitelisted and have not yet encountered any issues since doing this.

edit: after seeing that the expiration date has been a very short time after the next release, I would say our DeploymentRuleset does resolve the issue of the expiration date.
 
Back
Top