Slashdot Mirror
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.'"
Probably the most important question in the mind of the general public.
Crap, I already have a hard enough time getting non-programmers to understand that Java and JavaScript aren't the same thing.
Just what we need, yet another version to fight with and worry about..
---- Booth was a patriot ----
And another round of everyone getting ask.com toolbars.
Boooo.
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 to remove this "feature" for some time now, but despite the millions of Java developers, it never took off.
Person that says "runtime dependencies and interoperability are still a huge problem in Java" clearly never used C/C++ on multiple platforms.
839*929
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!)
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).
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.
StarTrekPhase2 - The Five Year Mission Continues!
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)
That is likely going to be an issue for any large neglected code base regardless of language.
I am working on a 80 000 lines long Java web application in the last 15 years. I have upgraded through 5 major versions, from Java 1.1 to 1.2 to 1.3 to 1.4 to 5 to 6. I do not remember a single issue related to any of these upgrades. There vere about 2 minor issues when we migrated from Unix to Windows to Linux (related to the case sensitivity of the file system).
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.
There's no place I could be, since I've found Serenity...
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?
If you are not allowed to question your government then the government has answered your question.
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).
I'm not sure I like your tone.
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
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.
-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.
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.
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 finally dies.
I'd gladly embrace /. Beta if it would somehow rid the world of Java.
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"
IBM WebSphere was always tightly tied to specific versions of Java. My guess is that as an "enterprise" application, they decided to rely on "enterprise" vendors that have a tendancy towards this kind of stupidity. Using mostly Apache projects you don't tend to run into these problems.
~$ 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
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 crapware, not Java.
I do not fail; I succeed at finding out what does not work.
You only get the crapware if you get it from java.com, so don't get it there. If you get it from oracle, you'll get it without crapware:
http://www.oracle.com/technetw...
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 software development under Eclipse on a computer with ONLY a 64-bit JRE. It would randomly forget how to find the SDK, fail compilation due to bugs in your code that didn't actually exist (if you cut the class into the clipboard, saved the now-empty class, then pasted it back, all the errors would go away), completely mangle R.java, and would do a phantom cursor-left whenever you typed a semicolon at the end of a line, so that when you pressed return a quarter-second later, it moved the semicolon down to the next line and caused an error.
There a other examples of vehemently-32bit apps, but it's late and Android-Eclipse is the huge one that drove me nuts for about 2 years. Note that I'm not conflating Android and Java... Eclipse itself is what was screwing up when run on a 64-bit VM.
That's because websphere runs by default on IBM's proprietary JVM.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.