JDK 8 Release Notes

http://www.oracle.com/technetwork/java/javase/8train-relnotes-latest-2153846.html

by vkhuc • 12 years ago

320 310 12 years ago

oracle.com

netcraft3• 12 years ago

The expiration date for JRE 8 is 05/15/2014

How long till most people will target 8? I think we will wait for at least a few patches first.

lmm2• 12 years ago

My employer was using it already, via the prerelease builds (until we found new relic didn't work with it).

kyrra3• 12 years ago

For clarity, expiration date[0] is just means the JRE will not be considered "up-to-date" anymore. At that point, the JRE will check for updates and ask the user to upgrade.

[0] http://docs.oracle.com/javase/8/docs/technotes/guides/jweb/c...

maaaats3• 12 years ago

We only do backend stuff here, which means we have perfect control over versions. So we're already ready for running 8, and will do so soon.

mtct• 12 years ago

3-5 years as usual

benjiweber5• 12 years ago

We've using 8 in production for some time, as we slowly migrate things to it. We didn't want to start new projects without using Java 8 language features as it's such a dramatic change.

It has been feature frozen for a long time and even the pre-release builds have had a lot more testing and stabilisation than other software that people don't think twice about using.

There is of course a risk adopting new technology early, it depends what kind of things you are building/running.

bane5• 12 years ago

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.

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.

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.

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

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.

edit

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.

netcraft3• 12 years ago

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

this is what groovy and kotlin attempt to do. groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

bane5• 12 years ago

I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.

eropple4• 12 years ago

Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)

lmm2• 12 years ago

I'd say Ceylon is the interesting project here - it keeps the JVM but drops the standard library.

(I'm a big fan of Scala - its sheer power is second to none - but it definitely has its ugly parts and many of them can't be fixed as long as it's to remain compatible with the Java standard library)

vorg6• 12 years ago

groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

Whenever I read that meme I get damn suspicious about why java code isn't valid groovy code in all cases. Why only most cases? It all sounds like a recipe for spending half a day debugging simple scenarios where things don't run as intended.

To be taken seriously (or as seriously as a language called Groovy can be taken), embrace and extend Java fully, don't embrace only 99% of it before extending. That's what Microsoft tried with J++ and lost a lot of trust with developers that took them a decade to win back.

jpitz• 12 years ago

There are warts in the standard library to be sure, but many of them have already been filled in by third parties like Apache Commons, Google Guava, and Joda-time. I'm sure there are others I'm not thinking of.

latchkey• 12 years ago

Agreed ...and jdk8 includes what was effectively joda-time (jsr-310) now.

projectlombok.org also makes a lot of the language syntax ugliness quite bearable.

bane5• 12 years ago

Yeah, and I've already come across most of those. Integrating lots of that stuff into the standard libraries that Java ships with would be exactly what I'm thinking of...and jettisoning all the broken GUI frameworks and such. And cleaning up the disaster pile that is I/O. I mean, I think there's still stuff sitting around in javax.* from when I last touched Java 14 years ago. I thought that was supposed to be the experimental branch where things might change without warning? Let's clean that up.

I know most IDEs just ship with all that stuff included, but I've found it makes packaging up things to give to somebody else a little more complicated than I'd like...which would be resolved in the standard libraries.

nicobn2• 12 years ago

I was going to reply with exactly the same thing, and I'd add slf4j.

bradleyjg2• 12 years ago

Filing in the holes is nice, but without actually making it a design choice java embodies TMTOWTDI more than perl ever did.

For many common tasks there are 5 or 6 different standard library calls that seem to do the same thing, but 4 of them are to be avoided at all cost, but there's no depreciation tag and the official javadocs don't contain any pointers to the newer classes.

michaelt• 12 years ago

If you aspire to make Java into the type of language we would arrive at if we redesigned Java from scratch today, it's not just a matter of adding good features but also removing bad ones.

For example, you'd go directly to Joda-Time or JSR-310. Date and Calendar wouldn't be present at all.

Whether Java should break compatibility to remove all the old cruft I'm not sure. The benefits of the cleaner design might not be worth the costs/inconvenience.

puppetmaster33• 12 years ago

The problem is not java the lang. It's the java developers. Looks like they moved on to do angular now.

edwinnathaniel5• 12 years ago

That's a good sign. Y'all JS devs need to learn something from Java community (especially the engineering/quality side) even if you guys have to go through the pain of Java growth (small => medium => bloated => denial => acceptance => cleaning up => shaping up for the future).

asdafa• 12 years ago

I partly agree with this.

I'm a systems engineer, but I have to touch some Java code from time to time. I always have an hard time with the amount of indirection an average Java developer can reach. Luckily a few smart guys were hired recently and they have past experience in contributing to the JVM and their approach to the code is completely different and much, much more simple to understand, and since they came onboard the performance of critical parts of our main application increased dramatically with a few lines of code instead of the previous 400 or so.

edwinnathaniel5• 12 years ago

Those warts have been addressed by 3rd-party libraries.

The ecosystem is much better (more stable, higher quality, higher "engineering" effort) than Ruby or Python.

Might not suit to one's taste but we all have different taste buds.

kovacs• 12 years ago

You know I'm not sure I completely agree on this point. As someone that's lived in both the Java and Ruby worlds for a long time I'd say that in a many number of cases you're right. The "shiny object" syndrome is much less of a factor in the Java world and things like backward compatibility are engrained in the culture which manifests itself in the various open source projects. In the ruby world things are simpler to get started with and the surface area of a project is usually smaller and fairly easy to get integrated compared to Java. But ruby projects tend to "rot" much more quickly and aren't nearly as strict about compatibility. That's probably because Rails, the biggest reason for ruby's popularity, is very much about breaking compatibility without a second thought if it means improving the framework. But I've also seen some really well written and tested ruby gems in my time, compared to some java projects... and visa versa.

praetorian84• 12 years ago

Definitely a promising little language. Might make it big in the enterprise.

mariusmg• 12 years ago

C# is a nice languae. Java...not so much.

Properties, delegates, proper generics, LINQ and so on.

sremani• 12 years ago

I agree C# from pure language point of view had a better road map and unlike Java which was sort of kind of run by committee did not need colossal consensus from disparate groups for new language features.

JVM vs CLR its a different story - I am hearing Microsoft in negotiation with Xamarin to buy/invest, that may make Mono get feature/implementation parity with CLR. Till then JVM is the only thing close to platform agnostic environment in town.

benjiweber5• 12 years ago

A lot of the things you can do with LINQ you can do in Java now there are lambdas and method references. e.g. http://benjiweber.co.uk/blog/2013/12/28/typesafe-database-in...

Properties you could simulate with lambdas now. something like Property<String> name = get(() -> name).set(name -> this.name = name);

You would lose all the existing framework support that assumes getters and setters doing that though.

Some of the generics failure will likely be fixed in 9 (Primitive specialisation). Other things are not as bad as some people think (At least generic supertype params are available at runtime)

goalieca• 12 years ago

I would say that C#'s language evolution is too closely tied with the terrible frameworks as well as legacy they have to support.

mjt0229• 12 years ago

The real problem with C# is that it is still basically Windows-specific. Yes, Mono is out there, but have you actually tried to build a Mono app without using Xamarin? Have you looked at what the Xamarin licenses cost? Once your project reaches a certain level of complexity, you have to pay them outrageous fees. And even with it, it still feels like you're operating something that could keel over at any second. The ecosystem there is just terrible, which is a shame because F# is such a great language.

The thing that makes Java so great as a platform is that there are so many totally reasonable tools that you can just download and use. Eclipse, IntelliJ (community version, which is still pretty good), the myriad of excellent alternative JVM languages, all freely available and cross platform.

pron9• 12 years ago

A major cleanup of the Java libraries is scheduled for Java 9. The JVM actually does not surprise anyone who's been working with it for a while: it is downright the most performant, flexible and awesome runtime environment ever developed. I've been playing around with lots of languages and environments in my pretty long career and, in the past decade, have always come back to Java (or the JVM). It feels like driving a Ferrari where everything else is at best a Toyota - might be easier to handle at first, but it's not your dream car.

This pattern, by the way, has been going on in lots of tech companies. They always end up going back to the JVM.

Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use), cool and extremely useful capabilities like dynamic linking and bytecode instrumentation, and unparalleled monitoring and profiling tools. It's the most professional platform you can choose (unless you're limited to Windows, in which case .Net is also an option). It's so far ahead than anything else out there, that the competition can only beat it in very specific use cases (e.g. Go is much better at startup time as well as standalone packaging, and C has better performance, though mostly in single-threaded programs). But nothing else gives you the whole package of performance, flexibility, maturity and monitoring.

chaostheory• 12 years ago

Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use)

It's getting easier

http://akka.io/

http://gpars.codehaus.org/

I think clojure is also actor based.

mongol• 12 years ago

Do you have more info on the cleanup in Java 9? Will they remove some deprecated methods then?

hugofirth2• 12 years ago

Is there any chance you could briefly enumerate some of the things that make the JVM's approach to concurrency so strong? I'd be interested.

hkphooey• 12 years ago

What is best practice when it comes to Java GUIs?

Would you recommend Java for building cross-platform desktop apps with near native UI performance?

The IntelliJ IDE looks great but most Java desktop apps I've come across just look and feel weird. Not sure why there is such a big difference.

radiantsand4• 12 years ago

I've been using Java since the 90s. The JVM is a pretty solid piece of engineering, but your post is pretty heavily loaded with hyperbole. There are plenty of other excellent concurrency platforms for example Erlang, Go, even the. NET CLR.

kriro• 12 years ago

I agree that the JVM is pretty awesome and will only improve (lots of money is bet on it after all) but I think BEAM may fulfil some of the items on your "awesome runtime" list :)

SkyMarshal• 12 years ago

Agreed, in fact what's surprising is that anyone thinks it's surprising that the JVM with its billions of man hours and primary usage in mission critical finance/banking/etc is anything but one of the most performant, scalable, robust, well-tooled platforms around.

Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use)

Though I'd probably still reserve that accolade for Erlang OTP/BEAM.

hibikir3• 12 years ago

The JVM has a couple of pretty significant problems when trying to work with functional-style languages. The biggest one is the way it deals with the stack: It's not in the heap, and it's pretty limited, so with something like scala, and more specifically with scalaz, you have to do some contortions to avoid overflows. 90% of usages of scalaz trampolines are nothing but ways to work around JVM limitations.

I'd argue that today, you are better off with the .NET VM, as far as features are concerned. But being stuck in windowsland is really a non-starter for all kinds of applications. I can send a major task that will take 400 computers for a week to Amazon if my code relies on the JVM. If I write it in .NET, not so much

ape4• 12 years ago

Lots of things in the library have multiple ways of doing things. Eg File, NIO. Generally if you use the new class you're in for a nicer time.

I agree about the regex literals. JavaScript does it right.

Pxtl• 12 years ago

Breaking backwards compatibility isn't really an option, but if the compiler and IDE would discourage the use of legacy features that would be best.

Just remove the legacy/ugly methods and packages from the autocomplete process, and warn with recommendations/flag as deprecated. You don't actually have to break anything.

iSnow• 12 years ago

Actually, every IDE warns you if you try to use a deprecated method. They show as strikethrough in your source too.

There are things like http://docs.oracle.com/javase/7/docs/api/deprecated-list.htm... and IDE's know about this.

elwell• 12 years ago

lots of over-objectizing everything

This. This is what I think of when I think of Java.

tormeh2• 12 years ago

Object orientation isn't a bad thing per se, but everything should be done in moderation and, well, the argument can certainly be made that Java has gone a bit or two too far.

piokuc• 12 years ago

JVM is fast these days, indeed. I was playing with Solr lately and was shocked with its speed... Also saw a comparison of HTTP servers lately and the fastest one was written in Java, I think.

mbillie1• 12 years ago

This sort of reaction is surprising to me. Java has been a useable, performant language for some time now. The tooling is excellent, the JVM is astonishingly good, and it will run circles around Python, no less Perl. I don't think many of the arguments against Java are based on how it works once you've written it, but rather to the horrendous verbosity, class-explosion-as-a-design-pattern, painfulness to read (not debug with an IDE, which is easy, but to actually read Java code), and so on. I'm not a Java developer by trade, but I'm surprised that other people are surprised by Java being high-performing, and the JVM being a good platform. I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time!

ephemeralgomi• 12 years ago

painfulness to read (not debug with an IDE, which is easy, but to actually read Java code)

This is incredibly important and I never see any Java advocate addressing it. I _do_ see tons of people pointing out how easy it is to automate refactoring, and then they leave dozens of ugly, poorly-thought-out methods lying around...

bane5• 12 years ago

Of course you have to understand in my context I've really come in close intimate contact with Java twice. The first time about 14-15 years ago when the JVM was pretty doggish. I think it was Java 1.4 or 1.5. I don't think Eclipse was even out then, and the first version I remember seeing was so dog slow at the time compared to Visual C++ that I remember just writing off Java entirely.

To my surprise it stuck around in Enterprise spaces and I ended up running a team that ported a pretty large-ish Perl project (about 20k lines of Perl) into a piece of Java middleware. I didn't do any of the coding, but I knew the Perl bits inside and out so I knew what kind of testing and performance to expect and getting the Java port up to 1/3rd to 1/2 the performance of the original Perl was a pretty big challenge at the time. This was about...8 year ago. But to the credit of the team and I guess the tooling, they were able to get the port done remarkably quick.

So I've been pretty surprised to see that Java code can get fast, really fast. I've also managed to bang out some pretty slow code if I wasn't paying attention. For my latest touch into it, I ended up spending a week just benchmarking various collections to see how they actually worked under the kind of real-world uses I'd be putting them through (vs. what their big-O sheets claimed) and came away with a set of practices for me to get going with.

I've also had to come to terms with benching code a bunch of times to give the JIT compiler or whatever runs under the hood in the JVM some time to optimize, the first few runs are invariably much slower than run 1000.

vorg6• 12 years ago

I mean, Clojure Scala and Groovy all run on the JVM, and we talk about them all the time!

5 years ago those 3 languages were the talk of the town for alternate JVM languages, but things change. Scala's pulled way ahead of the pack, Clojure's consistent, and Groovy's on a downward trajectory, following in Beanshell's and JPython's footsteps. Eclipse users are drifting into Xtend, and IntelliJ users may look at Kotlin more. JDK 8's Nashorn is likely to scoop up those who just want to write quick-n-dirty's manipping Java classes.

dragonwriter3• 12 years ago

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.

Java has caught on to this, and a number of the new JDK 8 features reflect this (lambdas and everything related to them, default methods for interfaces, etc.) But Java isn't as unconstrained as a new language like Go is, because its got to support a huge stack of established code as well as making things more streamlined for new code.

suyash10• 12 years ago

Java is the #1 language in the world. It's the best out there, period.

http://jaxenter.com/java-is-the-world-s-1-programming-langua...

radiantsand4• 12 years ago

Best at what? You've link to a notoriously unscientific index which counts search engine results. How does that make one language universally better than all others "period". I've coded in Java for most of my career, but the blind blinkered faith in the language within the Java community never ceases to amaze me. It's one tool available among many, look a little further than that single hammer which you worship in your toolbox.

gamegoblin4• 12 years ago

Popularity != Quality

cia_plant• 12 years ago

No, actually, Java is a really bad language.

It has a very complicated type system, but doesn't even allow you to express things like function composition or generic sums at the language level.

Its syntax is stunningly verbose (e.g., no map literals; only now adding lambda literals; no type synonyms; no operator overloading).

There is no macro system or method_missing or any other way of really extending the language, except the ugly, unsafe reflection system ... so now all the libraries (Spring, Hibernate, etc.), use annotations and reflection to modify object behavior at runtime.

stusmall2• 12 years ago

What is complex about the type system?

mercurial3• 12 years ago

It has a very complicated type system, but doesn't even allow you to express things like function composition or generic sums at the language level.

Yeah, sure, it doesn't have Haskell's . or algebraic datatypes, just like lots of other languages. I'm not sure what's complicated about the Java type system, but I suspect you're trying to say you don't like subtyping. Moving on...

Its syntax is stunningly verbose (e.g., no map literals; only now adding lambda literals; no type synonyms; no operator overloading).

No map literals, but Guava has leveraged generics in a brilliant way to reduce the duplicate declaration of types. Also, it brings a little bit of functional-style goodness with transform/filter. It turns even JDK 6 into something you can be productive with. I'm not sure the lack of type synonyms is really an issue, the type signatures are rarely complex enough that you need to obfuscate them. On the other hand, I'd give somebody else's right arm for an equivalent to newtype and deriving.

There is no macro system or method_missing or any other way of really extending the language, except the ugly, unsafe reflection system ... so now all the libraries (Spring, Hibernate, etc.), use annotations and reflection to modify object behavior at runtime.

Not to forget proxy objects and interceptors. But yes, Java could definitely use a macro system.

But you're missing the elephant in the room, the existence of null. The bane of every Java programmer, dreading NPEs at each function call.

peterashford8• 12 years ago

Java is not a bad language. It was written as a reaction to C++ - a simpler, more consistent systems programming language. In that regard it has been wildly successful. It doesn't really look like a dynamically typed scripting language because it was never trying to be one.

You pick a bunch of language flavour / syntactic sugar and say that Java is bad because it doesn't have those. Personally I like it because it doesn't have things like operator overloading. These are you own preferences, not inherent flaws with the language.

bane5• 12 years ago

Its syntax is stunningly verbose (e.g., no map literals; only now adding lambda literals; no type synonyms; no operator overloading).

I can see both side of this. My favorite language to work in is Perl, which is loaded with all kinds of little context sensitive literals. But Java "the language" is pretty quick to pick up and get working with if you're already familiar with another Algol family language, and you can usually read other people's code without too much fuss because the language doesn't support all sorts of ways of writing something.

But on the other hand, you do end up with lots of lines to do something that should be relatively few lines if a more context specific syntax was supported. For example, the last time I worked with Java, code was littered with a half dozen lines of Iterator mess every time you wanted to go through some collection, the new for syntax is very very nice...but there's still little hard corners it's not that well supported in, like maps, because the underlying structure of the map means I have to build some temporary object to handle an item on the map in the loop...even though the map collection I'm using is in the standard library and should be part of the language via some syntactic sugar.

I'm still stunned that operator overloading isn't supported, I have a few use-cases already where that would be very helpful.

mahyarm• 12 years ago

Go work with C++, and you'll pine for Java.

gamegoblin4• 12 years ago

@regex

I think a simple enough solution would be to introduce raw strings which is how regex is usually done in python.

why-el• 12 years ago

Well you are basically quoting Joshua Bloch of Effective Java fame when he says "please don't abandon the JVM, a lot of work went into it"(My paraphrasing).

jonalmeida• 12 years ago

I've gained an affection towards IntelliJ after having to use Android Studio for some development.

Much more flexible nicer and customizable (from a UI pov) than Eclipse-based IDEs.

rurounijones• 12 years ago

One reason I love JRuby.

The ruby language syntax with the power of the JVM and Java library interop.

As far as I am concerned that is a match made in heaven.

NerdfaceKillah• 12 years ago

What IDE do you use?

keypusher3• 12 years ago

You might want to check out Groovy. It's built on the JVM, you can use all the standard library and third party Java packages including stuff off Maven, and you can even just run straight Java code through it. However, at any time you can also drop into Groovy land, and write in a much more concise and functional style. Closures are very common (just look at anything in Gradle), it was clearly influenced by Python/Ruby as far as syntax and type optionality, there's a REPL (groovysh), there's a modern web framework (Grails), all in all it's pretty nice.

virtualwhys2• 12 years ago

Meh, used Groovy for 2 years followed by a year of Grails 1.3.x hell.

Both the language and the framework have likely improved since then, but after switching to Scala + Play there's simply no going back ;-)

p.s. Haskell + Yesod (or Snap) look interesting as an alternative web stack to explore, but otherwise not seeing much out there that would draw me away from Scala land.

suyash10• 12 years ago

Yay!! Java 8 is released!!

My favorite parts:

- invokedynamic : http://stackoverflow.com/questions/6638735/whats-invokedynam...

- Project Nashorn : http://openjdk.java.net/projects/nashorn/

- lambda expressions : http://openjdk.java.net/projects/lambda/

aardvark1792• 12 years ago

InvokeDynamic came in with Java 7. I've got a large code base here that uses it extremely heavily and it's great, though you do need to do some careful tuning to really make it perform, and then retune when they change the implementation. :-)

acchow• 12 years ago

As noted in your link, invoke dynamic isn't intended to be used for Java developers - it's intended for non-Java languages running on the JVM.

suyash10• 12 years ago

yes, that's the magic of it! You can run code dynamically from other languages.

hansjorg• 12 years ago

Nashorn is said to be high-performance, and I've looked around for benchmarks several times since it was announced, but I still can't find anything but this:

https://github.com/tadas-subonis/java-nashorn-performance-sa...

What gives? Wouldn't a real comparison to Rhino and V8 (at least) be interesting?

Edit: strike that. Found someone who ran Octane and SunSpider and compared it to V8 and Spidermonkey: http://wnameless.wordpress.com/2013/12/10/javascript-engine-...

eropple4• 12 years ago

I've been using JDK8 for a while, but no Nashorn on Android keeps me on Rhino. Which is unfortunate. Rhino's a pain.

suyash10• 12 years ago

Nashorn is going to get faster with time. It is not a browser engine so don't try to compare it directly with V8 etc.

pron9• 12 years ago

I also like the pluggable type systems: http://docs.oracle.com/javase/tutorial/java/annotations/type...

WoodenChair• 12 years ago

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.

suyash10• 12 years ago

Download the JDK/JRE from Oracle: http://www.oracle.com/technetwork/java/javase/downloads/inde...

melling• 12 years ago

Anyone know what Google is going to do about Java 8 compatibility on Android? Not being able to adopt lambdas on mobile is a bummer.

masklinn• 12 years ago

AFAIK they still don't support all of Java 7 so...

jug6ernaut• 12 years ago

They support "parts" of java7, but not everything.

chwahoo• 12 years ago

Maybe worth a look for you: https://github.com/orfjackal/retrolambda

mihn• 12 years ago

Apparently Android is not using Java, but something that looks like Java. I bet Google vs. Oracle trial can be attributed to that. :)

octopus2• 12 years ago

Actually they use Java the language, except that the code doesn't run on JVM but on a different VM (Dalvik at this time). Dalvik supports Java 6 and parts from Java 7.

ZoFreX• 12 years ago

They added support for try-with-resources in KitKat, maybe they will continue to add support for new Java features in newer versions?

jayd16• 12 years ago

You can use most of Java 7 but not the new dynamic stuff. I'm told that lamdas will require this feature so we won't be getting that for a while.

This is total speculation, but they're also moving away from the DalvikVM to the new ART runtime. I'm hoping that they're keeping Java 8 in mind as that gets implemented.

maaaats3• 12 years ago

IntelliJ just pinged me with an update, and checking the release notes it says "ships final support for java 8". Sweet!

suyash10• 12 years ago

A better light weight alternate is Netbeans 8 that also just got released and has full Java 8 support in addition to many many other features: https://netbeans.org/community/releases/80/

maaaats3• 12 years ago

I'm not sure why you felt the need to add "a better light weight", why not just say "Netbeans also got Java 8 support"? This isn't the place to start a flamewar.

afsina2• 12 years ago

Java 8 made our in-house ASR engine %5-10 faster. Free performance is always welcome.

vladimirralev• 12 years ago

What kind of operations do you do? Fixed/floating point? Allocate memory or pool?

afsina2• 12 years ago

A lot of floating point operations are done in GMM likelihood calculations. Dynamic decoding with Viterbi beam search and language model queries are other operations. We pool some memory but we do not try hard for this. Allocation is cheap in Java. Cache aware design saved a lot of performance for us.

brunnsbe• 12 years ago

Hopefully JDK 8 will have a better release than JDK 7: http://searchhub.org//2011/07/28/dont-use-java-7-for-anythin...

suyash10• 12 years ago

Here is Chief Java Platform Architect: Mark Mark Reinhold’s Blog about JDK 8 and the key main features: http://mreinhold.org/blog/jdk8-ga

tete• 12 years ago

I'd really start considering Java if it wasn't for Oracle.

keypusher3• 12 years ago

Use OpenJDK.

ivanr• 12 years ago

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.

The list of improvements is quite long, actually:

- Server Cipher Suite Preference

- Strong Server Ephemeral Diffie-Hellman Parameters

- Authenticated (GCM) Suites

- Hardware Acceleration on Intel and AMD processors

- Server-Side SNI Support

- Ability to disable client-initiated renegotiation

- TLS 1.2 enabled by default in client mode

- Clients support Ephemeral DH over 1024 bits

More details here: http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-j...

And there are more security improvements documented here: http://openjdk.java.net/projects/jdk8/features#core/sec

kyrra3• 12 years ago

The DH size support is required for some US gov certifications I believe. Maybe FIPS 140-2 or -3.

lvh• 12 years ago

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.

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.

pron9• 12 years ago

They are working on this. See this talk about the modularization of the JDK in Java 9, which includes bundling of lean Java runtimes: http://parleys.com/play/52549d02e4b0a43ac12124be

democracy4• 12 years ago

Can you please give a use case of a program that a few hundred ms delay during startup would be an issue?

gkya4• 12 years ago

Few hundred milliseconds? I played with clojure a month or so ago and invoking lein repl was ~7.5 seconds.

duaneb2• 12 years ago

syncsynchalt• 12 years ago

Practically any command line utility? eg. ls, cat, sort, uniq, ps, what have you.

I'm constantly amazed that make(1) can do successive recompiles of a 50k LOC project in less than a second, while gradle / maven / etc takes upwards of a minute.

yuhong• 12 years ago

Free updates for Java 7 will end in a year: http://www.oracle.com/technetwork/java/eol-135779.html

sev• 12 years ago

For those who may not have seen it, here's a good primer/tutorial for Java 8:

http://winterbe.com/posts/2014/03/16/java-8-tutorial/

MBlume• 12 years ago

Packaging Java 8 for debian/ubuntu: http://michaelblume.tumblr.com/post/80003780922/packaging-ja...

hrjet2• 12 years ago

I am waiting for the OpenJDK release on Debian. In the meanwhile, you can also use the WebUpd8 PPA:

http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-...

bhauer• 12 years ago

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.

[1] http://www.techempower.com/blog/2013/03/26/everything-about-...

film422• 12 years ago

Superb post! Thanks for sharing.

hnriot• 12 years ago

Java+Guava is decent. Without the work that Google has done Java is incomplete and missing too much.

pron9• 12 years ago

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:

http://docs.oracle.com/javase/tutorial/java/annotations/type...

http://types.cs.washington.edu/jsr308/

javajosh• 12 years ago

It's really too bad lambdas in Java 8 don't do non-final variable capture; other than that, I'm very pleased with this.

film422• 12 years ago

I believe it will let you as long as you don't modify the variable. Am I wrong?

boohoofoodoo• 12 years ago

any sources for apt-get available?

webreac• 12 years ago

Does anyone know if all the security issues that have given bad reputation to java are fixed in java 8 ? Is it safe again to develop java applets ?

hibikir3• 12 years ago

It is never safe to develop Java applets. It was a silly concept when it was devised, and it's still a silly concept today. We aren't developing ActiveX controls either, right?

If you have an environment where you need a full client, and the developer is trusted, use Webstart: You have to actively accept something on Webstart. If you do not trust the developer, make the interface in a regular webpage.

datawander• 12 years ago

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.

nickbauman• 12 years ago

Lack of Tail Call Optimization is still a bummer in some cases.

jevinskie• 12 years ago

Does anybody know if static libraries made it in?

http://openjdk.java.net/jeps/178

spiralpolitik4• 12 years ago

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:

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

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

- Implement Categories (or mix-ins). Seriously if I have to see another class called StringUtils or IntegerUtils I will gouge my eyes out.

- Get rid of the primitives. I read somewhere that this was on the cards for Java 10.

- Implement proper Generics.

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

rossjudson• 12 years ago

Multiple return types: Questionable benefit there. Exceptions are nice when used properly. Option classes handle the rest.

Categories: Default methods probably do what you want.

Get rid of primitives: Are you nuts? It turns out computers work on primitives. It's good to support them.

"Proper" generics: maybe you mean specialization, or maybe you mean reification. It's a choice.

Properties: If they irritate you that much, just use something that will generate them for you, using standard annotation processing.

spiralpolitik4• 12 years ago

Default methods work nothing like categories. For example you can't use a default method decorate String with an additional method usable on every instance of String.

http://rypress.com/tutorials/objective-c/categories.html

aardvark1792• 12 years ago

There is work going on to introduce value types which would allow for primitives to be got rid of in their current form and unification of the type system.

larsmak• 12 years ago

I admit I find my-self thinking from time to time that I need to "return multiple values from this method". But this is not often, and in most cases I find that it is a result of bad design. A method should be short and have a single responsibility, that is at-least the java best practice mantra, having only a single return type help enforce this.

spiralpolitik4• 12 years ago

The problem with this is you are forced to violate Occam's Razor by introducing unnecessary classes and methods when you need to return two related but distinct results from an operation.

For example a method to calculate the value of an asset portfolio could return the value of the portfolio and the set of assets that are missing prices in a single call rather than having to make two separate ones (and potentially two iterations through a data collection). Cleaner to be able to return a number (or a money class) and a set of assets rather than having to return CalculationResult. As a bonus you also get to dodge the hardest problem in programming, naming things ;)

Most of my issues with Java stem from violations of Occam's Razor of this manner.

Compare with say Python where introducing classes is much less necessary and ends up with cleaner and clearer designs.

frowaway0014• 12 years ago

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

Heh? How are these things related to each other? Who in their sane mind would use tuples for error handling?

spiralpolitik4• 12 years ago

`Go` uses them in that manner.

f, err := os.Open("filename.ext") if err != nil { log.Fatal(err) }

drderidder• 12 years ago

pg had an interesting take on "hackers radar" wrt Java. worth a read. http://www.paulgraham.com/javacover.html

RyanZAG3• 12 years ago

2001

It's silly to compare Java8 with Java1.4? 1.3? from 2001.

donniezazen2• 12 years ago

Why does Android requires obsolete JDK 6 and not the latest stable version? Android should probably be the biggest project that uses JVM.

asmosoinio2• 12 years ago

Because it does not use JVM. The language is Java, but the virtual machine is Dalvik.

donniezazen2• 12 years ago

Why do they still use JDK 6 and not the current default version?

augustl• 12 years ago

There's a Node.js implementation on top of Nashorn, the JS engine that comes with JDK 8 https://avatar-js.java.net/

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.

AmrMostafa• 12 years ago

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: http://java.dzone.com/articles/java-8-permgen-metaspace

JDK 8 Release Notes

Related Stories