You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with.<p>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging around making usage of different pieces non-standard and lots of over-objectizing everything so you end up having to assemble lots of things out of little pieces, boilerplate-like, that should just be a single import and instantiation.<p>The modern JVM is surprisingly quick and robust technology and I've been pretty happy with it in my limited tests. I ported some old Perl algorithms to it and got some really good speed out of it once I benchmarked some of the collections a little.<p>Some things should just be outright fixed, like a proper regex literal so I don\\'t have to \\e\\s\\ca\\\p\\\\e everything so much\\\\\//\/\\.<p>It's "got good bones" and a refurb of the entire thing to bring it focus could breath a lot of long-term life into it.<p><i>edit</i><p>I guess what I'm trying to say is it would be great if the language was informed a bit more with what's going on in the dynamic languages space like Go has been. I like how Python is about as clear as Java code is, but it's always seemed a little more quick and breezy to work with. This is something I think Go got right and it'd be great if Java sort of caught onto this.
For me, the best part of this release is the fact that the TLS stack has been significantly improved, and is now quite good. The lack of some critical features in Java 7 (e.g., inability to enforce cipher suite order) made TLS effectively unusable.<p>The list of improvements is quite long, actually:<p>- Server Cipher Suite Preference<p>- Strong Server Ephemeral Diffie-Hellman Parameters<p>- Authenticated (GCM) Suites<p>- Hardware Acceleration on Intel and AMD processors<p>- Server-Side SNI Support<p>- Ability to disable client-initiated renegotiation<p>- TLS 1.2 enabled by default in client mode<p>- Clients support Ephemeral DH over 1024 bits<p>More details here: <a href="http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html" rel="nofollow">http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-j...</a><p>And there are more security improvements documented here: <a href="http://openjdk.java.net/projects/jdk8/features#core/sec" rel="nofollow">http://openjdk.java.net/projects/jdk8/features#core/sec</a>
I'm very happy with the JVM in general, but I really, really, really wish they fixed the start up time. People compile Clojure down to Javascript for command line tools precisely because of this. lein <anything> takes annoyingly long, so I don't do it.<p>I realize this is not a real concern for them for e.g. servers, but I wish they had some developer- or desktop-specific configuration that would start about as fast as a Python VM. I don't even care if it runs code (a reasonable fraction) slower.
If you're curious about the developer-facing changes in Java 8, I of course recommend the blog entry we wrote up last year [1]. It's a bit hard to believe it's been a year.<p>[1] <a href="http://www.techempower.com/blog/2013/03/26/everything-about-java-8/" rel="nofollow">http://www.techempower.com/blog/2013/03/26/everything-about-...</a>
A very interesting new feature that is not talked about a lot is type annotations, which add pluggable type systems to Java with the Checker framework:<p><a href="http://docs.oracle.com/javase/tutorial/java/annotations/type_annotations.html" rel="nofollow">http://docs.oracle.com/javase/tutorial/java/annotations/type...</a><p><a href="http://types.cs.washington.edu/jsr308/" rel="nofollow">http://types.cs.washington.edu/jsr308/</a>
I'm surprised no one mentioned the departure of permgen space and the dreaded PermSize and MaxPermSize JVM arguments. While it was actually replaced with a new "metadata" space, the latter is mostly transparent, unlike the former. You can read more about the change here: <a href="http://java.dzone.com/articles/java-8-permgen-metaspace" rel="nofollow">http://java.dzone.com/articles/java-8-permgen-metaspace</a>
The install of JDK 8 on OS X is surprisingly straight forward. I just double clicked, selected yes a few times in a standard OS X install dialog, and I was up and running... now running applets with all of this security is another matter.
Download the JDK/JRE from Oracle: <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html" rel="nofollow">http://www.oracle.com/technetwork/java/javase/downloads/inde...</a>
I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see:<p>- Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a dependency or package manager. I know jigsaw is going in this direction, but I fear they are going to go the same way as J2ME with profiles. They should also clean up the cruft while they are doing this. This would allow the libraries to evolve separately from the JDK and even allow 3rd party framework to flourish while still keeping things reasonable manageable.<p>- Multiple return types. Scala has hacked around it, Python has them, Go has them. Bite the bullet and implement them so you can do sensible error handling without exceptions or returning `null`. While they are at it they could also fix the type system to finally allow `Integer hello()` and `String hello()` to exist in the same class.<p>- Implement Categories (or mix-ins). Seriously if I have to see another class called StringUtils or IntegerUtils I will gouge my eyes out.<p>- Get rid of the primitives. I read somewhere that this was on the cards for Java 10.<p>- Implement proper Generics.<p>- Implement @property just like Objective-C and .NET so that 80% of class files aren't getters and setters. I'm really surprised they never did this when they implemented annotations as this was the first obvious annotation to add. I know you can do it with Aspect J but you shouldn't have to. There was a JSR for this at one point but it seemed to disappear into the ether.
Here is Chief Java Platform Architect: Mark Mark Reinhold’s Blog about JDK 8 and the key main features: <a href="http://mreinhold.org/blog/jdk8-ga" rel="nofollow">http://mreinhold.org/blog/jdk8-ga</a>
> The expiration date for JRE 8 is 05/15/2014<p>How long till most people will target 8? I think we will wait for at least a few patches first.
For those who may not have seen it, here's a good primer/tutorial for Java 8:<p><a href="http://winterbe.com/posts/2014/03/16/java-8-tutorial/" rel="nofollow">http://winterbe.com/posts/2014/03/16/java-8-tutorial/</a>
There's a Node.js implementation on top of Nashorn, the JS engine that comes with JDK 8 <a href="https://avatar-js.java.net/" rel="nofollow">https://avatar-js.java.net/</a><p>Pretty cool stuff! I hope someone makes an easy way to render FB react modules on the server without relying on a separate Node.js process.
Hopefully JDK 8 will have a better release than JDK 7:
<a href="http://searchhub.org//2011/07/28/dont-use-java-7-for-anything/" rel="nofollow">http://searchhub.org//2011/07/28/dont-use-java-7-for-anythin...</a>
Free updates for Java 7 will end in a year: <a href="http://www.oracle.com/technetwork/java/eol-135779.html" rel="nofollow">http://www.oracle.com/technetwork/java/eol-135779.html</a>
People will look back upon this date with utter lament because the world of lambdas has been unleashed upon a much more dangerous and wider world of programmers.
Does anybody know if static libraries made it in?<p><a href="http://openjdk.java.net/jeps/178" rel="nofollow">http://openjdk.java.net/jeps/178</a>
pg had an interesting take on "hackers radar" wrt Java. worth a read. <a href="http://www.paulgraham.com/javacover.html" rel="nofollow">http://www.paulgraham.com/javacover.html</a>