Java 8 Officially Released 302
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.'"
Does it make Minecraft run faster? (Score:5, Funny)
Probably the most important question in the mind of the general public.
Re: (Score:2)
Re: (Score:2)
Java isn't terribly inefficient itself, it's the people who write things for it.
Yes and no, you can write fast efficient code in java but you have to fight the language to do so. In particular java lacks both user defined value types and parameter pass by reference. The obiovus way round this is to just create objects on the heap willy nilly thereby creating a load of extra work for the GC. There are more efficient methods (using paralell arrays, passing in an object purely so the next level down of functions can use it as parameter passing space) but they all make your code uglier and
Re:Does it make Minecraft run faster? (Score:5, Informative)
Your mistake is in thinking that constructing classes in Java with new would put them on the heap.
It does not. It puts them into a special cache that is very similar to a stack, and which gets destroyed when the function exists. Objects that require more persistence than the scope they are allocated in migrate to another storage space automatically when the scope or function ends. This check isn't quite as free as just incrementing a stack pointer, but it is still extremely efficient... taking far less time than it would to manipulate values on a global heap.
Re: (Score:2)
You're wrong, Java always passes parameters by reference.
Re: (Score:2)
Not primitive types, not it doesn't. Objects, yes. Hence the need to create objects when all you want it to pass an int as a reference.
Re: (Score:3)
And how much space would you imagine passing a reference to an int would save, compared to just passing the value of the int?
Re:Does it make Minecraft run faster? (Score:5, Funny)
java.lang.Thread
Re: (Score:2)
Re: (Score:2)
Java has supported threads for many years now.
Re: (Score:2)
I assume parent was talking more to Minecraft itself not being threaded rather than Java itself.
It's a very annoying and frustrating problem for just about anyone who has tried to run a server, especially if one liked to play with a lot of mods. You've got this killer server with 8 cores, but minecraft can only use one of them, and the log file is filled with complaints of things not executing fast enough.
It got bad enough that someone has actually made a pretty damn good attempt at adding threading themsel
Re:Does it make Minecraft run faster? (Score:5, Insightful)
Quoting the grandparent:
The one thing they need to do is make Java run multi-threaded ... Oracle should not ignore it's Minecraft userbase.
Three things seem plain. First, the poster appears to believe that applications may be rendered multithreaded by mere virtue of the programming language they are written in, without special consideration; in other words, an application that would otherwise be singlethreaded may be made instantly multithreaded without special work. Second, the poster did not know Java has threads. Third, the poster believes Oracle cares about Minecraft. All of these things appear to reflect an uninformed poster.
Re: (Score:2)
And now you're the one trolling ;-)
Threading has always been there in Java, from version 1.0. 32 and 64 bits have nothing to do with it.
A Javascript Engine in the JVM!? (Score:5, Funny)
Crap, I already have a hard enough time getting non-programmers to understand that Java and JavaScript aren't the same thing.
Re:A Javascript Engine in the JVM!? (Score:5, Funny)
Same for me, but it was with programmers.
Re: (Score:2)
Re: (Score:2)
Stop assigning people well versed in one to programming projects written in the other, hopefully.
Re: (Score:2)
Just refer to it as The Down Side of the Schwartz.
Re:A Javascript Engine in the JVM!? (Score:5, Funny)
Crap, I already have a hard enough time getting non-programmers to understand that Java and JavaScript aren't the same thing.
Javascript is just Java written in cursive - duh.
Re:A Javascript Engine in the JVM!? (Score:4, Informative)
"New" is an important qualifier in the summary, because Java has had a Javascript engine since version 6, which included Rhino.
Re: (Score:3)
They've had one for nearly a decade. Rhino has just been replaced by a new one that takes advantage of a new JVM instruction.
Re:A Javascript Engine in the JVM!? (Score:5, Informative)
Re: (Score:3)
Re: (Score:2)
whohoo! Swiss cheese! (Score:4, Insightful)
Just what we need, yet another version to fight with and worry about..
Re: (Score:2)
But Java now has "critical new features, including Lambda expressions". Java really didn't work without Lambda expressions. Now I can FINALLY get a Java "hello world" to compile and run! Yippee.
(ok, so Lambda expressions are cool, but are they critical?)
Re: (Score:2)
ok, so Lambda expressions are cool, but are they critical?
Yes.
They allow you to distribute a job without doing all of threads and callbacks by yourself. Even if you ignore the electron wall Moore's law is hitting, "cloud" computing is all about doing many small computations simultaneously.
Re: (Score:2)
The ExecutorService from Java 5 does that. Lambda expressions are a fancy way to write anonymous inner classes.
Fanboy Glee (Score:2)
Yaaaaaaay! :D :D :D
More coding shinies!
Re:Fanboy Glee (Score:5, Insightful)
And another round of everyone getting ask.com toolbars.
Boooo.
Re:Fanboy Glee (Score:5, Insightful)
Yeah, that actually sucks some serious monkey balls right there. It doesn't make any sense at all for Oracle to do such a thing with something as important as the Java platform.
There has been a petition [change.org] to remove this "feature" for some time now, but despite the millions of Java developers, it never took off.
Re: (Score:2)
I see people's home computers covered with that Ask toll (yep) bar all the time.
Regulars here are familiar with Dunning-Kruger, but there exists a polar opposite condition thus far unnamed: when you're a winner at the cerebrally capable sweepstakes, you infer intelligence by others that may not exist. What should we call it?
Re: (Score:3)
Re: (Score:2)
https://www.java.com/en/downlo... [java.com]
Modularity (Score:4, Interesting)
Re: (Score:3)
C/C++ across multiple runtimes on *one* platform are relatively easy, though. Not so with Java. Trying to find a common version of Java that works on any three given enterprise apps can be a real pain in the ass, and I can guarantee you it's not going to be recent or up to date on security patches.
Re:Modularity (Score:4, Interesting)
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: (Score:2)
Writing your code is only part of the problem. Things become funny when you have to use code that has already been written by other people. For example, you're using a shared library which exports a symbol whic
Re: (Score:2)
For example, you're using a shared library which exports a symbol which clashes with another library used by another library that is dynamically loaded by another library that you use. Without you knowing.
That's not really a problem on modern systems.....at least OSX mach-o format allows it to know which symbol goes with which library.....even if they export the same symbols.
Of course, if you want to call a function that has the same name in both libraries, then you're in trouble, but that's a problem in Java, too.
Re: (Score:2)
This is how I port my code written on Linux into Windows, Mac, or BSD: git pull && make
Do you use Cygwin to do that?
Re: (Score:2)
It's not nearly as bad as the situation with C(++), but the way Java's classloader refuses to allow jars-in-jars is still pretty stupid. We should be able to create an executable jarfile with a virtual /libs directory that contains all the thirdparty jarfiles our own app needs.
It's 2014. Nobody *cares* how much space the compiled bytecode takes anymore, because it's insignificant compared to the amount of RAM needed at runtime for the various heaps. And when there's an exception to that rule, it's usually w
Lambdas could be interesting (Score:2)
Lambdas could be interesting for some GUI coding I have to do in the near future. I look forward to exploring them, but had no interest in playing with the betas.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Basically the second line of code below is junk that could be removed, right?
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.err.println("Button pressed");
}});
Criticality of JigSaw (Score:3)
It seems like a good idea and all, but I wouldn't consider this a critical must have feature.
My (on the spot off the top of my head) wishlist:
- swing that doesn't suck (seriously, how has this not yet been fixed)
- file choosers that don't suck (yes I already said swing, but file choosers just stand out as being particularly bad
- some standard command line argument processing
- unsigned types
- multiple inheritance (yes I know, old argument, but I want it damnit!)
Re: (Score:3)
Swing that doesn't suck? There's no way Oracle understands even as much as Sun about GUIs, and that's scraping the bottom of the barrel.
Re: (Score:2)
Re: (Score:2)
Java 8 sort-of has unsigned types [oracle.com].
Re: (Score:2)
Hmm, I haven't noticed that.
Definitely a step in the right direction, and certainly useful to anyone who has to deal with networking :)
Re: (Score:2)
... ugh. As they say, it beats casting to larger types all the time, especially with the performance hit of the Big* types, but it's still not as good as just giving us some damn uints.
Re: (Score:2)
Swing has been replaced with JavaFX, which is a very modern and rather slick UI framework. It's got a very nice skin, can be styled with CSS, is rendered via OpenGL or Direct3D with all the attendant features that provides, has a full blown animation and effects framework, a good visual designer (no longer left up to IDE makers), uses native file choosers, and can reliably hit 60 frames per second. Also the API is very clean and so far I found it a joy to work with.
The downside? Of course, Java 8 is huge an
Re: (Score:2)
JavaFX is still rather component poor, just like Swing was. It's ultimately Swing's biggest problem IMO: To do anything even mildly interesting, you have to build your own components, or do major extensions on the base ones. How much pain have people inflicted on themselves extending JTable? And no mention of the layout manager mess, only solved by third parties, back when Swing was already considered semi-dead: I'd trade every single layout option built into JavaFX for MigLayout.
Re: (Score:3)
No properties (Score:2)
...and still no properties. Seriously? getBlah()? setBlah()? I'm so glad I switched to Scala for newer development and that I even convicned my company to let us do more Scala development. The devs who are using Scala like it better and seem generally happier.
Java 8 == Absolutely none of the features we wanted and a lot of stuff I could care less about.
Re: (Score:2)
Re:No properties (Score:4, Interesting)
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: (Score:2)
Extensive C# and a bit of Scala, if any other languages I use support them (probably) I've never written one.
You did nothing at all to refute any of my arguments, or put forward any of your own. Thus, in the tone of your own comment, I surmise that you're just a fanboy and incapable of rationally defending your position.
Bundled Crapware? (Score:2)
Re: (Score:3)
http://www.oracle.com/technetw... [oracle.com]
Too little, too late (Score:3, Interesting)
Re: (Score:2)
Programmers that really cared about things like lambda expressions have already moved on to Scala and/or Clojure
Apparently not many people care about them, then.
Fire Up the Regression Finder (Score:2)
Did they finally straighten out the 64-bit mess? (Score:4, Interesting)
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.
Re: (Score:3)
It's simple. If you have a 32 bit OS, install the 32 bit version of Java. If you have a 64 bit OS, install the 64 bit version of Java.
I have never since Java 1.0 seen a Java program that required the 32 bit or the 64 bit version. That's the runtime, and has nothing to do with how the JVM byte code itself is structured. I don't even know how you could make a Java executable depend on the version of JVM short of using the bindings for calling binary libraries -- in which case you're dealing with crapwa
Re: (Score:2)
http://www.java.com/en/downloa... [java.com]
Isn't the 32-bit version of Internet Explorer still the default on Windows 8? Isn't Firefox (the one you normally get anyway) and Chrome still also 32 bit?
Re: (Score:3)
I only wish it were that simple. On my computer at work, I have at least one Java app that literally dies on launch unless you have BOTH 32-bit AND 64-bit Java installed. It exhibits this behavior on everybody's computer, and not just mine. Nobody, including its author, really knows why.
That oddball app notwithstanding, installing only a 64-bit JRE on a computer running 64-bit Windows 7 is NOT the universal solution. Google finally fixed it, but for the longest time, you literally couldn't do Android softwa
and yet... (Score:2)
Re: (Score:2)
Yes. I would recommend starting your development with Java 8. Any compatibility problems you run into will likely go away within the month as more libraries add Java 8 support. Most of them already work fine out of the box. Some of them depend on bytecode internals (e.g. the ASM library) so it'll take them a bit longer to run properly under Java 8.
Re:As a beginning Java programmer... (Score:5, Interesting)
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: (Score:2)
Which would be a bit difficult, as Java 3 never existed. It wasn't until Java 1.5 that Sun decided to drop the leading 1 for marketing purposes.
Re: (Score:3)
~$ java -version
java version "1.7.0_51"
Java has always been 1.x under the covers. We went through the 'Java 2' phase, now it's just Java SE.
FWIW, programmers will still refer to it as JDK 1.8
Re: (Score:2)
As usual, if you haven't been using behind-the-scenes classes that generate big fat warnings (cause you're not supposed to use them), it'll work right out of the box.
Re: (Score:2)
One of the nicest things about Jigsaw is being able to pick and package only those parts of Java that you need, potentially making your app considerably smaller, faster to load and consuming less memory, also thanks to the overdue housekeeping of breaking ancient, useless dependencies in the JRE apart.
Re:Jigsaw (Score:5, Insightful)
Far BETTER would be if Java could be aware of how much ram the computer has, and enlarge its heaps as necessary & possible. Few things piss me off more than getting OutOfMemoryException on a computer with 16 gigs because I forgot to manually specify a larger heap size when I launched some executable jarfile from the commandline.
I mean, seriously. Would it really be *that* hard for the JVM to handle TWO sets of memory pools instead of just one, so that if the Eden space (for example) gets exhausted and is due for GC, the JVM would check with Windows to see how much physical RAM is free, and if there's a lot of it, just allocate a new chunk that's roughly double the size of the old one, start sticking new data into the new one immediately, and consolidate data from the old one into the new one as a very, very low-priority non-blocking background thread that eventually returns the first chunk of RAM to Windows once everything in it has been either moved or freed. For longer-lived services where memory leaks are a real issue, you could tell it, "expand by doubling up to [max megs or percent free], then fall back to conventional garbage collection -- possibly, grabbing a new chunk of ram that's the same size as the old one if possible so the time-consuming object-copy can be deferred and done in the background"
Re: Jigsaw (Score:2)
Re: (Score:2)
Re: (Score:2)
Our accounting people have to have 7.17 installed so that JPMorgan/Chase will work for them. Another dept uses a site for a supplier of parts that only runs on Java 7.45 with the security slide bar thingy set to "Medium" (which is as low as you can go for some reason). Our Mac's (designer people) can't use a Kodak site because Apple forced out the latest version which is incompatible. Our SAN requires 7.17.
There's a special place in hell for Java and i can't wait to dance on it's charred corpse when it
Re: (Score:2)
You need to look into security policies [oracle.com] so that does not become a wide open hole for any remote site to exploit.
Re: (Score:2)
I guess the point here is whether '8' introduces any new incompatibilities over '7'.
Re:Damnit (Score:5, Insightful)
What the fuck are you going on about? Java 8 supports all the previous versions without a problem. Same for Java 7, and all the others before it. If you write code that breaks because of backwards compatibility issues, you're a retard.
No, they most definitely do NOT. We inherited an infrastructure (from a company we bought) that relies heavily on Java 1.4.2 and Java 1.5 (both on the server end and on the client end). Many of the (entirely internal) apps and servlets will not run in Java 6, much less Java 7. Believe me, we've tried. Too much deprecated stuff (not to mention security keys from Sun that haven't been changed in over half a decade).
We've got a two year long project going on to upgrade everything - but because so many libraries are shared (including *SUN* libraries that don't work in Java 6/7) across hundreds of projects, it's going to be an upgrade nightmare. In total, we have GIGABYTES of code, spread across a pretty large infrastructure (comprised of over a hundred servers and 5 racks of SAN).
Of course, our plans are to ensure that all code is up to snuff so we never run into this again - but we had no choice in this matter, since we neither wrote nor planned the original code bases. But what WE do going forward doesn't resolve what we have to do in order to move forward.
Perhaps you simply haven't done any real Java coding on an Enterprise level? If you had, you'd never had made such a post.
Re: Damnit (Score:2)
Re: (Score:2)
True, but I don't consider Java Neglected code, It poorly maintained and tested.
The whole point of Java is so you can upgrade the interpreter and not need to recompile or rewrite all your code.
That;'s it's selling point.
At this rate, we might as well go back to writing websites in C.
You heard me.
Re: (Score:2, Insightful)
No the selling point is that you move your code to any hardware platform that has an interpreter and not need to rewrite any code. Switching between supported Java versions isn't part of that.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Perhaps you simply haven't done any real Java coding on an Enterprise level? If you had, you'd never had made such a post.
Why is it everyone thinks THEIR situation obviously reflects EVERYONES. "I've programmed on the "enterprise level" (nonsense terminology), so that means that my experience is just like everyone else's.
Sorry, but bullshit. YMMV. While you're right, that sometimes you do run into crap that isn't compatible, by and large I've had few problems going from Java 3 to 4 to 5 to 6 to 7. I've
Re: (Score:2)
Because there are a WIDE swath of incredibly popular vendors whose java applets do not support anything newer than 1.6? Cisco, Dell, HP, Fiery, etc.
Claiming "there are no issues" just means youve been insulated in your own little world. I dont even do software dev, I do IT, and Ive seen way too many applets break with anything newer than ~1.6_u9
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
That's because websphere runs by default on IBM's [wikipedia.org] proprietary JVM [wikipedia.org].
Re:Damnit (Score:5, Insightful)
Meanwhile in the real world:
-people use methods that have been deprecated since java3 (including 3'rd party vendors that you have to deal with)
-massive (and expensive) libraries are used years after they stopped being maintained/supported
-new versions do break old functionality by adding new behavior (often around security)
-reasonable mistakes/oversights where new situations are introduced and not accounted for in code (statuses are reported differently / new things added to enums / etc)
Re:Damnit (Score:5, Insightful)
-new versions do break old functionality by adding new behavior (often around security)
Multiple programs each requiring unique versions of Java (and each only looking at the default Java on the system) coexisting on the same machine used to be my biggest nightmare.
Now though, it's security. Oh, I'm sorry. Did the vendor sign their .jar files in a way that makes 7_fourtywhatever not shit out dialog boxes? Oh they didn't? Did Sun include simple registry values to fix this? No. They moved to a crazy collection of files in %appdata%? Oh, that should be fun.
Do you want to run this code?
Are you absolutely sure you want to run this code?
No, you can't run it anyway, because your security settings are wrong.
Would you like to change your settings now?
No, you can't. You need to change obscure settings.
Fuck you, Sun. Right in the goat ass.
Re: (Score:2)
Fuck you, Sun. Right in the goat ass.
That's not Sun, it's Oracle. And it's just what you would expect from Oracle, so much that you wonder if they do it on purpose.
Re: (Score:2)
Deprecation of Java APIs is irrelevant since Java never gets rid of old calls...ever.
Re: (Score:2)
I'd be really surprised if the most of incompabilities were not bugs in the code itself (or libraries as you point out). Far too many a program rely on some undefined behaviour, and when it changes, you are screwed.
Re:Damnit (Score:4, Interesting)
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?
Re: (Score:2)
Or it could simply be buggy threaded code, doing things like starting new threads from object constructors. Those can sometimes do things like give the appearance of working under one garbage collector yet start throwing NullPointerExceptions under another.
Re: (Score:2)
Many vendors do this. See:
* HP / Dell iLo crap
* Cisco ASA / Pix interfaces
* Lots of ancient HP printers
* Any printer that comes with a Fiery controller (see: basically all modern Canons that have been upsold)
* I believe BES servers have issues with upgrades too
Not to mention all the inhouse crap that I hear immediately breaks when people upgrade.
Re: (Score:2)
I agree, with some minor caveats. Using public APIs, avoiding deprecated sections, is generally very safe. Using anything in the sun.* packages as well as undocumented behavior is no-man's land. I worked on a project that actively exploited bugs in Swing in Java 5,