Java 8 Officially Released

darthcamaro writes "Oracle today officially released Java 8, nearly two years after Java 7, and after much delay. The new release includes a number of critical new features, including Lambda expressions and the new Nashorn JavaScript engine. Java 8, however, is still missing at least one critical piece that Java developers have been asking for, for years. 'It's a pity that some of the features like Jigsaw were dropped as modularity, runtime dependencies and interoperability are still a huge problem in Java,' James Donelan, vice president of engineering at MuleSoft said. 'In fact this is the one area where I still think Java has a long way to go.'"

Comments

Jit also comes with NSA goodies

[Anonymous Coward]

Customers beware. Oracle doesn't value your privacy. Virtually Guaranteed Oracle slip in "extras" on NSA demand during updates.

Here's CEO Larry Ellison himself trying to once again downplay the NSA spying (which he's done on many occasions.. i.e. he's in bed with them)
http://www.reuters.com/article/2014/01/30/us-oracle-nsa-idUSBREA0T05U20140130

Modularity

[should_be_linear]

Person that says "runtime dependencies and interoperability are still a huge problem in Java" clearly never used C/C++ on multiple platforms.

Re:Modularity

[VortexCortex]

Meh, I wrote my own replacement for freeglut3 in a weekend. It's not hard to have a platform abstraction layer, and many already exist (I just needed my own lightweight one for my games). Since I started out with cross platform toolchain, I have no issue writing code that runs on multiple platforms.

This is how I port my code written on Linux into Windows, Mac, or BSD: git pull && make

Not that is is exactly the same as when I use Java, except I get a native application without Java's huge runtime dependencies. Look, Java is now essentially the proprietary option for when you don't want to give away source code. If you have the source code, then the program is cross platform. And if I don't want to distribute sources? Providing binaries for every current modern chipset including ARM and MIPS takes me about 30 minutes total to build with my cross compilers. Yeah, users still have to pick which binary to install, but it's actually less of a headache due to browser user agent string detection -- Less of a PITA than bundling a JRE or displaying, "You don't have (the right version of) Java, download and install Java from [here] before you download and this program."

Oh, the kitchen sink isn't a big deal? Yeah right, that's why Oracle is now relaxing on the requirements for "compliant" JVMs so they can drop a bunch of shit no one needs and still call themselves Java. Also, with native code you get a smaller attack surface. You see, the cost of cross platform capabilities is just deferred to elsewhere with Java.

Don't get me wrong, I like Java and still use it. It's the right tool for some jobs. However, saying that cross platform C/C++ is more of a headache than Java is ridiculous. They're all "write once, debug everywhere" options. Enterprise software is even falling out of love with Java given that hardware supports native virtualization now.

Re:As a beginning Java programmer...

[Anrego]

Yeah, go for it.

It's rare to see stuff break recently between even major versions of java (with some notable exceptions). Usually when it does, it's the result of people (inevitably the makers of 3rd party libraries you are forced to use) doing stupid shit (often times using stuff that's been deprecated since like java 3).

Re:No properties

[cbhacking]

Meh. Explicit getters and setters are annoyingly boilerplate-y but properties aren't much better. They let you save a few characters on the API-use side, but not enough that I find them that important. They do cut down on the massive list of "getFoo, getBar, getBaz, setFoo, setBaz" functions which are divided in your IDE by a bunch of other APIs (oh look, no at-a glance way to tell that Bar is read-only) but that's one of the few good things I have to say about them. They're also annoyingly magic-ish; functions that *look* like simple public members but can have all kinds of side effects and such (yeah, they *shouldn't*, but we already have language semantics for "this operation will invoke a function call" as opposed to "this operation will simply access a member variable" and properties overload the latter to tack on the former.

Re:Damnit

[tompaulco]

So I guess the open source community is a retard.
Where I work, we are still on Java 6 because certain Open Source projects upon which we depend do not work in Java 7. Now, it being Open Source, I suppose we could go in and fix that, but then what is the point of standing on the shoulders of giants if you have to build the giant?

Too little, too late

[shaven_llama]

Programmers that really cared about things like lambda expressions have already moved on to Scala and/or Clojure (and of course, it's not as if lambda expression support is the only thing those languages have going for them over Java). I work on a mixed Java/Scala codebase, and we just finished upgrading from JDK6 to 7. I don't see us tackling an upgrade to JDK8 anytime soon (probably won't be until JDK7 stops getting security patches).

Did they finally straighten out the 64-bit mess?

[Miamicanes]

The biggest problem with Java is the fact that it makes dealing with 32-vs-64-bit and user-vs-admin in shell and script environments needlessly painful under Windows.

I mean, seriously. Why, in 2014, do we STILL have bullshit like:

java -jar foo.jar arg1 arg2 arg3

(silent crash), or
[*very public crash*], or
"This application requires a 64-bit JVM"

then, have to screw around figuring out what the path is THIS WEEK to the right java.exe, because every goddamn semi-daily update changes the installation path, so you end up having to do something like:

{swear violently and with frustrated rage}
dir "c:\program files\java"
(see what the installation dir is this week)
"c:\program files\java\jdk1.7.0.69\bin\java.exe" foo.jar arg1 arg2 arg3

I mean, would it really kill them to give us an installer that installs BOTH the 32 and 64-bit JDKs, then creates a bunch of symlinks to a file named java.exe that -- when launched -- looks at the jarfile, determines whether it needs a 32- or 64-bit JVM, finds the latest 32- or 64-bit JVM as appropriate, and launches it -- passing the path to itself and the rest of the args as args?

This is an endless source of pain to me. Java is my main language & I end up using it for almost everything, and its awful handling of commandline launches has driven me crazy for years. When I write some tool I use a lot, I'll go to the trouble of setting it up to build with JSmooth so it can wrap the whole thing in a .exe file... but that's a royal pain in itself, and I'm dreading the day when I have to figure out how to use it to wrap a 64-bit Java app (I'm not even sure it can).

Java also needs to seriously improve the way it deals with UAC... like maybe install a privileged Java background service (that's normally asleep and idle) so we can launch apps as regular users under Windows 7, and programatically auto-elevate via UAC by having Java delegate sensitive tasks to that background service when necessary under Windows 7 or later. Or at least, create something like WindowsUACException that's a subclass of IOException (so Windows-aware apps can catch it explicitly and deal with it gracefully, without breaking Windows-unaware apps that are oblivious to UAC) that gets thrown when something fails due to UAC, instead of throwing some misleading Exception that makes it look like the filesystem is missing.

Regardless, Java's handling of Windows commandline launches of executable Jarfiles *sucks* under Java 7, and we can only hope they've had mercy on us and made it less dysfunctional under Java 8.