There is currently a known bug with the way
String.hashCode() is implemented in Java. If a specially crafted set of
HashMap are introduced, a denial-of-service attack could result in the code. Basically, if enough of the parameters added hash to the same value, it will cause excessive CPU time.
HashMap bucket uses a linked list to store the map entries. Using this algorithm, if there are a high number of collisions, then the complexity of the hash changes from
O(N). To resolve this, once the number of items in a bucket reaches a certain threshold, the bucket will switch to using a balanced tree algorithm in order to reduce the complexity to
O(log n). Hopefully it will address denial-of-service bugs like this one that Oracle says is not its problem.
SNI isn't the name of a Dr. Seuss character. It is Server Name Identification. So everyone loves SSL or TLS or whatever its calling itself these days. However, while we are running out of IPv4 addresses, no one except for neckbeards and cat ladies actually wants IPv6.
Since most public sites don't have thousands, let alone millions, of users (whoo-hoo, hi, to the 10 to 12 people who read my personal blog), a lot of sites use the same IP address and a name-based virtual host. What that means is the second line of the HTTP request is the hostname. I can ask for podcasts.infoworld.com and www.infoworld.com, ending up at the same IP address, but based upon the hostname, I might get two different Web pages. However, many times I can't share IP addresses because of SSL. Due to the HTTP Host header on which name-based virtual hosts rely on comes after SSL encryption/decryption, I have to have a different IP for every SSL certificate.
This was addressed in the last few years with something called SNI; now Java has it too. Most recent browsers support it, Apache supports it, and Java now supports it. This means that before long we can expect Tomcat and other Java-based servers that use Oracle's slow-motion SSL implementation known as JSSE to support SNI.
All in all, some good features are coming to Java 8, but there are catches. Some of it will be in the way that developers choose to use the new technologies. The streams are by far the best new feature in my opinion. Hopefully the parallelism of collections will increase their processing performance. I can see uses similar to cache spaces. Bring your dataset into memory, and when you need specific things out of it, run it through a parallel stream to get at the data you need. The feature that is going to be dangerous is functional interfaces. If they are not used properly, they could cause a lot of headaches.
This article, "Love and hate for Java 8," was originally published at InfoWorld.com. Keep up on the latest developments in application development and Java, and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.