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

Does it make Minecraft run faster?

[Anonymous Coward]

Probably the most important question in the mind of the general public.

Re:Does it make Minecraft run faster?

[Anonymous Coward]

No joke. Minecraft is the one and only reason I have Java installed on my PC at all. I find it quite annoying that such a popular and fun game to play is made to run on such a poor platform for gaming. The one thing they need to do is make Java run multi-threaded, so that it can actually take advantage of more than 1/4 or 1/8 the processing power of gaming PCs. Oracle should not ignore it's Minecraft userbase.

Re:Does it make Minecraft run faster?

[iced_773]

The answer is probably no. Java isn't terribly inefficient itself, it's the people who write things for it. Minecraft mods in particular tend to be fairly heavy on memory leaks.

Re:Does it make Minecraft run faster?

[viperidaenz]

java.lang.Thread

Re:Does it make Minecraft run faster?

[Anonymous Coward]

If you're really not trolling, then quit using the 32 bit version and go get the 64 bit one.
Protip- you'll have to work a little bit because Oracle's site doesn't like to show you the download to the 64bit if you're using a 32bit browser.

Re: Does it make Minecraft run faster?

[Anonymous Coward]

Java has supported parallel execution threads for ages. If minecraft isn't coded to use them, blame Mojang.

Re:Does it make Minecraft run faster?

[ahabswhale]

Java has supported threads for many years now.

Re:Does it make Minecraft run faster?

[petermgreen]

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

Re:Does it make Minecraft run faster?

[Anonymous Coward]

Not to mention the inability to use primitive types in generics and the wrapping of primitive types (Integer for int for example) which then led to the attempt to fix the problem with auto-boxing/unboxing which was one of the worst language design decisions.

Re:Does it make Minecraft run faster?

[mark-t]

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:Does it make Minecraft run faster?

[Anrego]

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 themselves via a mod (tickthreading).

Re:Does it make Minecraft run faster?

[philip.paradis]

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:Does it make Minecraft run faster?

[cristiroma]

Yeah, and it was implemented just from 1.0

Re:Does it make Minecraft run faster?

[zarlino]

You're wrong, Java always passes parameters by reference.

Re:Does it make Minecraft run faster?

[Pieroxy]

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.

Re:Does it make Minecraft run faster?

[Pieroxy]

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:Does it make Minecraft run faster?

[Anonymous Coward]

You are wrong. Java always passes parameters by value. Object references are also passed passed by value.

http://javadude.com/articles/passbyvalue.htm

Re:Does it make Minecraft run faster?

[linzello]

No, objects are NOT passed by reference. Java is purely pass by value - Google it.
I should know, been programming Java since version 1.0

Re:Does it make Minecraft run faster?

[Laz10]

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?

[dintech]

All of these things appear to reflect an uninformed poster.

...or a well fed and satisfied troll!

Re:Does it make Minecraft run faster?

[Anonymous Coward]

You're wrong, Java always passes parameters by reference.

BZZT! WRONG!

Java passes EVERYTHING by value. When you have an object you actually have a reference to an object and the reference is passed by.... VALUE!

Re:Does it make Minecraft run faster?

[Anonymous Coward]

And the same to you, dumbass.

Re:Does it make Minecraft run faster?

[Anonymous Coward]

Oracle had better care about Minecraft.

It's the only thing keeping me (and a bajillion others like me) from uninstalling their security hole deployment framework.

Re:Does it make Minecraft run faster?

[Anonymous Coward]

You idiots are just being pedantic. In that since EVERYTHING is passed by value. Pass by reference means to pass a pointer to an object and not the object itself. OF COURSE the reference itself is passed by value. Sheesh!

Re:Does it make Minecraft run faster?

[Anonymous Coward]

You are being thick. Of course the reference itself is passed by value! That doesn't make it pass-by-value. You are passing a reference to an object. That is pass-by-reference. God, there are so many idiot programmers on Slashdot!

Re:Does it make Minecraft run faster?

[angel'o'sphere]

No one really misses user defined value types.

And passing values by reference makes not much sense in an multithreaded environment anyway. Objects are passed as a "value of a reference" ... so strictly speaking it is passing by value, however what is passed is a reference to an object.

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 No, it is not much extra work, the GC is optimized for such cases.

Re:Does it make Minecraft run faster?

[Pieroxy]

Objects are passed by reference, in that the callee shares the same instance as the caller, not a clone.

Re:Does it make Minecraft run faster?

[Pieroxy]

It would add convenience, not save space. That said, on a 64bit JVM, passing an int by ref *could* save 32bits.

Re:Does it make Minecraft run faster?

[Pieroxy]

Also, whenever you have a method that has to return a couple of longs, it would also save an object to wrap the result.

Re:Does it make Minecraft run faster?

[Anonymous Coward]

You're wrong, Java always passes parameters by reference.

This is a common misconception, Java is 100% pass by value for both primitive types and references. If you pass a reference the value gets copied to a new reference in the new call space, it is not the same reference. You can test this yourself, pass an object reference to a function, change what that function's reference points to, now return to the calling method, your original reference will be unchanged.

Since both references point to the same object in memory, calls to that object actually do whatever they are supposed to do and may result in changed data, but it is a mistake to say Java is "pass by reference" for that reason, a pass by reference example would be C++ aliases. The classic example is the swap(&a, &b) function.

Re:Does it make Minecraft run faster?

[viperidaenz]

and its a major language feature, with thread synchronisation part of the syntax.

Re:Does it make Minecraft run faster?

[danskal]

Either Slashdot is full of trolls, or there is an extraordinary dearth of knowledge about Java on Slashdot. So much FUD....every... time.

If you are super worried about the performance of one particular algorithm you need to implement, by all means implement in C. If you have an application that actually does lots of stuff, use Java - it's likely to perform better than what you could create in C or C++ in the same time. And it will be much easier to support.

Generally, to write performant code in Java, don't try to write C++ and bitch about the fact that Java isn't C++; write good Java, let the JIT compiler do it's thing and go to the pub on a friday night instead.

Re:Does it make Minecraft run faster?

[MikeBabcock]

Java is one of the few languages that's rapidly named as being designed around threading from the start.

Re:Does it make Minecraft run faster?

[MikeBabcock]

The first answer here: http://stackoverflow.com/quest... is an excellent reference as to why your statement doesn't mean what most people think it means.

Re:Does it make Minecraft run faster?

[Anonymous Coward]

No - all parameters are passed by value. Pointers/references to objects are passed by value - big difference from pass-by-value. See http://javadude.com/articles/passbyvalue.htm for a detailed explanation

Re:Does it make Minecraft run faster?

[teefal]

Actually, yes. Here's how to wire it for the Mac:

http://bigfractaltangle.com/20...

Re:Does it make Minecraft run faster?

[Anonymous Coward]

Java passes nothing by reference.

If it works like pass by reference it is because the object is mutable.

Pro-tip: Java references are gimped pointers.

Java is pass by value, period.

Re:Does it make Minecraft run faster?

[vilanye]

Pass by reference means passing the address of the pointer, not the address stored in the pointer.

Re:Does it make Minecraft run faster?

[vilanye]

Can you sort an array like so in Java

public void swap(int a, int b)
{
    int tmp=b;
    b=a;
    a=tmp;
}

swap(array[i],array[j]); ...

Answer: no you can not.

references in java are gimped pointers and have nothing to do with passing parameters.

What gets passed is a value, if it is a primitive, or an address if it is an object.

  http://javadude.com/articles/p...

It is amazing how ignorant Java devs are.

A Javascript Engine in the JVM!?

[Stormy Dragon]

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!?

[Anonymous Coward]

Same for me, but it was with programmers.

Re:A Javascript Engine in the JVM!?

[DMUTPeregrine]

Java and "Mocha Java" are both coffees, and both use beans from the island of Java, but are very different drinks. Java and Javascript are both programming languages, and both were originally created by Sun Microsystems, but they're very different languages.

Re:A Javascript Engine in the JVM!?

[ZombieBraintrust]

Why would you need to do that? What could they possibly do with such trivia?

Re:A Javascript Engine in the JVM!?

[gutnor]

Javascript was originated at Netscape. Nothing to do with java at all except some desire by Netscape to ride the java wave of that time: http://en.wikipedia.org/wiki/J...

Re:A Javascript Engine in the JVM!?

[Anonymous Coward]

JavaScript was created by Netscape, the initial browser company.

Re:A Javascript Engine in the JVM!?

[ackthpt]

Just refer to it as The Down Side of the Schwartz.

Re:A Javascript Engine in the JVM!?

[wolfgang.groiss]

Wasn't JavaScript actually created by Netscape and not by Sun?

Re:A Javascript Engine in the JVM!?

[fahrbot-bot]

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!?

[pjt33]

"New" is an important qualifier in the summary, because Java has had a Javascript engine since version 6, which included Rhino.

Re:A Javascript Engine in the JVM!?

[gnupun]

The Netscape folks did license the use of the "Java" brand name from Sun:

The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. The final choice of name caused confusion, giving the impression that the language was a spin-off of the Java programming language, and the choice has been characterized by many as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new web-programming language.

http://stackoverflow.com/quest...

Re:A Javascript Engine in the JVM!?

[Anonymous Coward]

You're a bit late to that realization...the JDK has shipped with a modified version of Rhino since 2006. Rhino is the Mozilla JavaScript implementation written in Java. The new JavaScript engine, Nashorn, is just a faster, more compliant implementation that takes advantage of a number of JVM features like INVOKEDYNAMIC.

Having JavaScript in the JDK is nothing new.

Re:A Javascript Engine in the JVM!?

[viperidaenz]

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!?

[Anonymous Coward]

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.

If you'd ever seen source code written by the original Netscape, you'd be cursing too.

Some of the crappiest shiite anyone ever paid billions of dollars for.

Too bad I signed an NDA and can't tell you what code I'm talking about, but it was a turd through and through.

Re:A Javascript Engine in the JVM!?

[Stormy Dragon]

Stop assigning people well versed in one to programming projects written in the other, hopefully.

Re:A Javascript Engine in the JVM!?

[Chrisq]

Java and "Mocha Java" are both coffees, and both use beans from the island of Java, but are very different drinks.

Oh shit that's why I have being having problems installing Java into my PC.

Re: A Javascript Engine in the JVM!?

[Anonymous Coward]

You guys are both misspelling Mosaic

As a beginning Java programmer...

[Anonymous Coward]

Is this something everyone should install? How does compatibility work with existing Java 7 projects?

Re:As a beginning Java programmer...

[cowwoc2001]

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

[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:As a beginning Java programmer...

[Anonymous Coward]

It's a maintenance fix for the original Java. I'd recommend switching to the Java SE branch when you can.

Re:As a beginning Java programmer...

[jrumney]

(often times using stuff that's been deprecated since like java 3).

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:As a beginning Java programmer...

[Anonymous Coward]

I guess that just makes it REALLY deprecated.

Re:As a beginning Java programmer...

[ChunderDownunder]

~$ 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:As a beginning Java programmer...

[Pieroxy]

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:As a beginning Java programmer...

[Anonymous Coward]

i think java 8 is backward compatible , is not ?? project big like java is always backward compatible. this is not for toy or messing around , java and project like that is for implementing real big project (financial and ...) and company like oracle never mess with some thing like backward compatibility . if i remember correctly , there is api from java 1.2 , which deprecated , but not removed at all . this is not Python (with respect for python community , but python does not provide backward compatibility at all)

Re:As a beginning Java programmer...

[Anonymous Coward]

Point is, there was never a Java version referred to by anyone as Java 3, either as a version number or a marketing name.

The closest thing was Java 1.3.x, marketed as J2SE 1.3, but nobody ever called that "Java 3" or "Java 3.0" or "J3EE" or anything like that.

Damnit

[Stargoat]

Great. A new version of Java. Many of my vendors do not support 7u51. Now we got 8. When I hear someone propose a Java solution, I reach for my firewall.

Re:Damnit

[Anonymous Coward]

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.

Re:Damnit

[Anonymous Coward]

Try living in the real world for a change.
"Write once, run anywhere" is a complete and utter joke.

For a "Hello World" program it just might and even then I'm not to sure.

For real world software. Not a chance.

Re:Damnit

[RobertM1968]

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

[Anrego]

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

[clerum]

That is likely going to be an issue for any large neglected code base regardless of language.

Re:Damnit

[Anonymous Coward]

Have you ever actually worked as a software developer?

Your university projects may be all neat and tidy, but real code sure as hell isn't, and re-writing all the incompatible shit isn't exactly a weekend project.

Re:Damnit

[dshk]

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

Re:Damnit

[Anonymous Coward]

ahhh yes another fool whose experience in the real world with Java doesn't go beyond reading the marketing speak. In the real world many tools and Java based products are dependent on previous versions. Java is NOT 100% backwards compatible at all for anything but the most basic of shit.

Re: Damnit

[Anonymous Coward]

What the hell are they doing with gigabytes of code? I think you just exceeded all of the open source repositories in the world...

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?

Re: Damnit

[geekoid]

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:Damnit

[thesandbender]

And don't forget about bugs with Java itself. We spent about half a day trying to figure out why an application that had been functioning until a Java upgrade stopped talking to the MS-SQL server it used, until we stumbled across JDK-7103725. We had to rollback until it was fixed (which actually took a few builds). There is a tiny bit of truth to the "Write once, break everywhere." troll.

Re:Damnit

[Anonymous Coward]

When he talks about deprecated stuff he likely means internal stuff that nobody should ever touch unless they provide a fall back changing. Or he refers to brain dead developers hard coding existing JVM vendors and the resulting breakage once ORACLE bought Sun - afaik that hit even eclipse.

Re:Damnit

[Anonymous Coward]

I see you stopped short of upgrading from 6 to 7. That was the one where any code that imported com.sun... packages broke. A lot of older Java apps had that dependency.

Re:Damnit

[Anonymous Coward]

but because so many libraries are shared (including *SUN* libraries that don't work in Java 6/7)

Um, are you talking about the sun internal packages(com.sun.whatever)? The internal packages that when used will generate a compiler warning? If so then yeah, it' no wonder you cannot move forward. Backwards compatibility usually only covers cases where the original coders stuck to the guidelines that were in place when the original code was written. Backwards compatibility usually does not, and should not cover programs that willfully violate those guidelines. The compiler generates warnings for a reason.

Re:Damnit

[Anonymous Coward]

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.

Not when the vendor changes default settings in the middle of a release and breaks your applications. The changes in Java v7 u45 were indeed for the better, however, common sense says you do NOT make changes to default settings in the middle of a release. You wait for the next major release to introduce changes in default settings.

Nevermind, this is Oracle we are talking about. Carry on.

Re: Damnit

[Anonymous Coward]

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:Damnit

[Anonymous Coward]

com.sun.whatever isn't part of the core Java. Those packages are extra Java libraries Sun decided to shop along with their implementation of Java. If you have problems with them, you're having library problems not problems with the Java language itself.

Re:Damnit

[mythosaz]

-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:Damnit

[Anonymous Coward]

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.

... Is there a fifteen year old runtine environment that upgrading today WOULDN'T give you headaches?

Re:Damnit

[Anonymous Coward]

I completly agree with RobertM on this front.
A prime example is Oracles own products - we are currently attempting to upgrade to Java 7, but are hampered by Oracle financials which currently only works on Java 1.6.30 and earlier. - and our own confirms this. Java is a real mess from a sys admin point of view - all good and well for your lovely little web apps and games, but when you come across to Java solutions from vendors for the enterprise it's a complete mess (Oh our product only works on 1.6.30 or our one only works on 1.6.15).

Re:Damnit

[ahabswhale]

Deprecation of Java APIs is irrelevant since Java never gets rid of old calls...ever.

Re: Damnit

[yenic]

Not breaking backwards compatibility is a feature of C++, not Java. The problem here is that he has code on 1.5, written 10 years ago. You're going to have deprecated features in that timeframe. If unmaintained you'll end up with a mess. I can't think of many languages meeting your requirements, just C++ for mainline work, or something esoteric.

Re: Damnit

[clerum]

Not saying Java is neglected. I'm saying if his systems are dependent on Java 1.4 then the code written in Java has been neglected.

Re:Damnit

[dysmal]

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.

Re:Damnit

[Anonymous Coward]

Many places I've worked at the developer develop on Windows but the code runs on a linux server.

So you're writing it one place and running it in one other place. That is not an example of WORA and thus I am highly skeptical on your claim of experience.

At my current place of employment, we code on Macs and deploy on Linux.

Once again, that is not an example of WORA. Where you write it makes no difference, I can write code in Notes on my iPhone and deploy it on Irix but that isn't Write Once Run Anywhere.

We never, ever get platform issues.

Of course you dont, you only deploy it on one platform.

Re:Damnit

[jrumney]

with the security slide bar thingy set to "Medium"

You need to look into security policies so that does not become a wide open hole for any remote site to exploit.

Re:Damnit

[jhol13]

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

[The Snowman]

I've been coding in Java for over a dozen years now and I can say without equivocation you're either a liar who's never actually worked with it or you're a fucking troll. Write once, run anywhere is is 100% real and is so common that it's a joke.

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, and broke on Java 6. Recoding the sections that took advantage of "undocumented features" restored it to correct functionality regardless of the JRE version. Again, using documented, supported parts of the JFC is key. Not actively trying to do things that ought not to be done is important.

For example, building filesystem paths where the path separator is hard-coded.

The I/O library in Java automatically corrects this. You can even mix "/" and "\" in the same path and it will work.

Re:Damnit

[Anonymous Coward]

We've got a two year long project going on to upgrade everything

Fuck me, two years to update your code from Java 1.4 to 1.7??
Write a script to go through each of your 100s of projects, decompile all the classes and jars, recompile, write regular expressions to replace deprecated code that barfs, rinse and repeat. Sounds like a week of work to me.
Two fucking years? Fuck me.

Re:Damnit

[ChunderDownunder]

I guess the point here is whether '8' introduces any new incompatibilities over '7'.

Re:Damnit

[Anonymous Coward]

In total, we have GIGABYTES of code, spread across a pretty large infrastructure (comprised of over a hundred servers and 5 racks of SAN).

Perhaps you simply haven't done any real Java coding on an Enterprise level?

My mind is boggling at the "Enterprise level" architect that designed your horseshit system.
Are your gigabytes of code source code, or class files/jar files? And why the fuck are they spread across hundreds of servers?
I can't even guess what enterprise system you've bought. It sounds like it's shittyness surpasses PeopleSoft and SAP level shittyness.
I can only guess that you bought some kind of applet hosting system which contains 1000's of applets...maybe for training or something? Am I close?

Re:Damnit

[Anonymous Coward]

Fuck you, Sun. Right in the goat ass.

Sun got fucked right in the goat ass when Larry bought them I'm afraid.

Re:Damnit

[Vellmont]

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 had quite a few issues upgrading Application servers, but that's a different matter.

Re:Damnit

[LordWabbit2]

80 000 lines? Come back when you work on a real system.

Re:Damnit

[phantomfive]

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:Damnit

[LordLimecat]

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:Damnit

[LordLimecat]

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:Damnit

[Pieroxy]

I once worked for a medium-sized startup where we had hundreds of thousands of lines of code. We went from a Solaris Java 1.3 32 bit JVM to a Windows 1.4 64bit JVM with not even needing to recompile the project. Just a few config files needed some path to be rewritten, but nothing java-related.

So unless you're using JNI, I'd say the WORA is pretty much alive on Java, and that from day one.

Re: Damnit

[Pieroxy]

But it works

Re:Damnit

[delt0r]

And none of this is limited to java.

Re:Damnit

[delt0r]

So don't use freaking applets. It was a stupid idea to begin with.

Re:Damnit

[Anonymous Coward]

Of course you tested on a staging platform before going live right? So this was caught in time and no harm was done?

Re:Damnit

[Anonymous Coward]

The problem I'm fighting is that we have vendor-supplied applets (SSL VPN stuff, workflow stuff in advertising) that when it runs, explicitly implies Java 6. That may have been a good idea when Java 6 first came out, but now it's a damn nightmare.

Re:Damnit

[Anrego]

Oh definitely granted, I've found Java to be much better in this regard than just about anything else still under active development.

Java keeps deprecated stuff around forever and seems to at least generally understand that people can't rewrite their whole code base every few years. I'd put Java's built in libraries over just about any other lib I've ever used as far as likeliness to still work in 10 years goes.

Re:Damnit

[sproketboy]

That's not been my experience. We've been maintaining a large web app under tomcat with Struts for 12 years and have upgraded from Java 3 though Java 7 without any significant compatibility issues. Basically at the beginning of our release cycle we put in the new Java and the new Tomcat and deploy and get to work....

Re:Damnit

[ears_d]

Waking up in today's world with a Java 1.4 code base would be one big hangover. Mix in a large helping of early Struts/JSP from the same period and, well, life would suck. Rather then a problem with Java, it's really a code issue; without diligent oversight code gets pretty damn ugly. My day job is dealing with this problem - 10 year old code where 95% of the JSP are made up of Java code instead of tags. Business needs are finally forcing a rewrite. My architecture for the replacement is based on components. Small blocks of code distributed as jars with an expected live of around 2 years. Maybe that''s the lesson Java updates...

Re:Damnit

[swillden]

I am working on a 80 000 lines long Java web application in the last 15 years.

So... a part-time task for a single developer. It's not surprising a trivial app has few problems.

Re:Damnit

[Anonymous Coward]

-people use methods that have been deprecated since java3

What is Java3?

Do you mean Java 2SE 1.3?

Java didn't use single number versions until Java 5.

Re:Damnit

[Anonymous Coward]

It could also mean they stay clear of crap like Cisco, Dell, HP, Fiery, etc.

Re:Damnit

[nine-times]

Yeah, I've seen enough Java software that no only requires 1.4 or 1.5 of the plugin, but might require a specific version (e.g. 1.4.2_23) or else it simply won't work. Earlier or later, it won't work. Now maybe the developers who made that app are completely retarded, but I've seen enough of them that I think there must be some fault in the approach Sun took in the first place.

It's definitely not the case that if you install the latest Java plugin, it will support all code written for prior versions.

Re:Damnit

[Anonymous Coward]

Applets are the kiddy-toys of java programming. No serious java dev gives a rats fucking ass about applets.

Re:Damnit

[MachineShedFred]

If it's the same shitty Kodak SmartReview applet that I've had to work around, you can still install Apple's Java 6 from here: http://support.apple.com/kb/DL...

Works fine on everything up to and including 10.9.2. Also works with Juniper's shitty HostChecker and JSAM applets.

Re:Damnit

[Anonymous Coward]

Sorry, you used INTERNAL com.sun libraries. There's your problem.

Re: Damnit

[RobertM1968]

Not saying Java is neglected. I'm saying if his systems are dependent on Java 1.4 then the code written in Java has been neglected.

Oh so horrendously neglected. Gigabytes of it. Good news is, me and my team are guaranteed a job for ages to come. ;-)

Bad news is, ugh... bringing gigabytes of inter-related Java code up to snuff is oh so much fun. :-P

Re:Damnit

[RobertM1968]

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

(1) Try Java 7 - more breaks there than in 6

(2) 80,000 lines of code is a joke compared to 74 GIGABYTES of code with tons of shared custom and outside vendor libraries, running to interconnect FIVE DOZEN servers running a multitude of server daemons, spread across RHEL, RHAS, RHES, Solaris (multiple versions), CentOS, Windows (multiple versions), on x86/64 and non x86/64 hardware - and those run on multiple Java versions in various Java engines (Sun, Oracle, IBM) and in various Java application servers (WebLogic, WebSphere, Tomcat, Covalent, and more). And since it covers virtually everything (in scope of calls and libraries), both Sun and outside vendor wise, we've run into a lot of deprecated calls - and numerous other issues.

(3) Some of the infrastructure components will need to be "upgraded" onto a new OS - for instance, components of IBM FileNet P8 that used to "run best" on Solaris are now being "upgraded" onto RHEL 7 ("upgraded" is in quotes, because it's an upgrade migration where the actual installed version isn't really being upgraded - its settings and data are being migrated onto the newer FileNet version).

(4) Numerous of the outside libraries (for instance the ancient FileNet libraries that *FileNet* (not IBM) wrote) are not compliant with Java 6 or above (IBM for instance, fixed that in later releases - doesn't help us until the rest of the code is corrected to work with the new libraries and Java 7).

I think comparing a tiny (in comparison) 80,000 line project to the scope of our infrastructure is where and why you're seeing different results. I envy you.

Re:Damnit

[RobertM1968]

And don't forget about bugs with Java itself. We spent about half a day trying to figure out why an application that had been functioning until a Java upgrade stopped talking to the MS-SQL server it used, until we stumbled across JDK-7103725. We had to rollback until it was fixed (which actually took a few builds). There is a tiny bit of truth to the "Write once, break everywhere." troll.

I HAD forgotten the bugs... until I took on this project. That too has been part of the problem. I remember all too clearly now. :-/

And since the original project actually started in January 2002, a bunch of the code was actually written for Java 1.3 (and then, 3 years later, when the project was complete and in testing, ran on Java 1.4 and eventually a combo of 1.4.2 and 1.5).

Re:Damnit

[RobertM1968]

but because so many libraries are shared (including *SUN* libraries that don't work in Java 6/7) Um, are you talking about the sun internal packages(com.sun.whatever)? The internal packages that when used will generate a compiler warning? If so then yeah, it' no wonder you cannot move forward. Backwards compatibility usually only covers cases where the original coders stuck to the guidelines that were in place when the original code was written. Backwards compatibility usually does not, and should not cover programs that willfully violate those guidelines. The compiler generates warnings for a reason.

First, as someone else said...

Those packages are extra Java libraries Sun decided to shop along with their implementation of Java.

Second, some of Sun's old add on libraries use functions that were deprecated and will no longer compile on Java 7. Not give "warnings" - but won't compile because the calls are no longer in Java 7. I mean really... all you need to do is look at the deprecated functions list and see which have been totally removed (and replaced) to see that the problem is different than what you think.

Re:Damnit

[RobertM1968]

Of course not. But that was my point. The OP was wrong. Many headaches - and I was simply using our situation as an example. ;-)

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.

... Is there a fifteen year old runtine environment that upgrading today WOULDN'T give you headaches?

Re:Damnit

[RobertM1968]

We've got a two year long project going on to upgrade everything

Fuck me, two years to update your code from Java 1.4 to 1.7?? Write a script to go through each of your 100s of projects, decompile all the classes and jars, recompile, write regular expressions to replace deprecated code that barfs, rinse and repeat. Sounds like a week of work to me. Two fucking years? Fuck me.

The Java component is just one piece of the puzzle. The system uses (not IBM) FileNet P8 v3.5 which needs to be upgraded to the radically different IBM FileNet P8 5.2 (which resolves the issues of having various Java versions and code likely to be deprecated) across multiple clustered servers duplicated in a Dev environment, a QA environment, the Production environment and the off site Disaster Recovery environment. The new FileNet environment will run on 8 clustered servers.

There are two separate clustered application servers running various components each in 6 different Java Server environments (spanning WebLogic, Covalent, Tomcat and more)

There are also 9 document generation and print servers, 2 business services servers, 5 scanning, indexing, validating servers, multiple fax servers, one big message server (ancient version of MQ), 7 dedicated scan stations with customized scan and release software, five racks of SAN storage (in old EMC2 SANS that are getting decommissioned during this project), 5 additional web interface servers, four dozen client stations that utilize some or all of those, and a collection of miscellaneous servers that provide other functionality. Each of those sets is replicated in (besides the production versions I described) Dev, QA and DR.

Our industry requires a development cycle, a QA testing cycle, and then migration into production AND the disaster recovery location.

Now, to top it off, various non-compliant third party libraries have been replaced with brand new ones for various of the software we use - meaning code changes above and beyond dealing with deprecated stuff in Java. Oh, and switching everything to Oracle Java 7. And switching almost a dozen servers from the no longer supported Solaris to RHEL.

So, yes, two years. Somehow I think a lot of the ACs here have never dealt with a big infrastructure before.

Re:Damnit

[RobertM1968]

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

(yup)

"Cisco, Dell, HP, Fiery," FileNet (pre-IBM), Oracle (pre-Java purchase).

Re:Damnit

[RobertM1968]

The problem I'm fighting is that we have vendor-supplied applets (SSL VPN stuff, workflow stuff in advertising) that when it runs, explicitly implies Java 6. That may have been a good idea when Java 6 first came out, but now it's a damn nightmare.

Ugh, I feel for you. That's our problem too (except our requirements are Java 1.4 or Java 1.5), and the vendor supplied stuff needs to be replaced with newer versions that require code revisions. :-/

Good luck.

Re:Damnit

[RobertM1968]

Waking up in today's world with a Java 1.4 code base would be one big hangover. Mix in a large helping of early Struts/JSP from the same period and, well, life would suck. Rather then a problem with Java, it's really a code issue; without diligent oversight code gets pretty damn ugly. My day job is dealing with this problem - 10 year old code where 95% of the JSP are made up of Java code instead of tags. Business needs are finally forcing a rewrite. My architecture for the replacement is based on components. Small blocks of code distributed as jars with an expected live of around 2 years. Maybe that''s the lesson Java updates...

I'm looking at a similar method. And since our vendor supplied libraries seem to tend to change, I want to wrap the heck out of those in simple class files that can be easily modified so that I only have a dozen or two files to worry about code changes in, instead of files spread out all over the place, across a variety of projects that all rely on the vendor supplied shitware.

Re:Damnit

[RobertM1968]

That's not been my experience. We've been maintaining a large web app under tomcat with Struts for 12 years and have upgraded from Java 3 though Java 7 without any significant compatibility issues. Basically at the beginning of our release cycle we put in the new Java and the new Tomcat and deploy and get to work....

a large web app - how nice. Half of FileNet is a massive collection of FileNet provided, and previous company modified Java Server apps - not a web app. Much of the underlying server stuff are Java Server apps running across a multitude of servers and Java Application Servers, on various operating systems and very diverse hardware.

Re:Damnit

[sproketboy]

Well dude if you're maintaining an app this complex what do you want? To be baby sat or something? Java is the least awful thing about your situation.

Re:Damnit

[dshk]

Actually we also upgraded to Java 7 I just forgot to mention that in my original post.

I am not sure what do you mean on deprecated calls. In new Java releases they deprecate functions or classes but they never remove them. Therefore deprecated functions do not cause backward compatibility issues. As others already mentioned likely you mean calls into JRE internal sun.* classes. Those are never deprecated, because they were never public! No code should call them, except very special applications in very special circumanstances, but then they should always provide a default fallback algorithm, and advertise this issue on the very first page of this documentation. Actually the only software I know which has a good reason to call internal sun.* code is the big data database, Cassandra, which is assumed to manage memory in the hundreds of gigabytes range.

However, I understand you, because with such a large amount of code you likely run into each and every bug in the JRE class libraries at some point in your code. But your situation is definitely not the usual, and based on your disappointed tone, I believe your organisation is doing something strange. You say that you have 74 gigabytes of code, but the entire Java EE codebase is less than 80 megabytes of binary code. It is quite strange that you blame that 0.1% code for all your problems. You should either pay for Oracle support, and receive bug fixes early, or pay developers who can quickly fix JRE bugs themselves, and that will be still a tiny fraction of your IT budget. Java related costs must be compared to the similar cost of some alternative technology, so you could tell whether Java or that alternative is the more cost effective in your situation. I do not know anything else which seems to be better for us.

Re:Damnit

[RobertM1968]

Actually:

(1) The earlier compiler logs show no errors or warnings (neither does compiling it with the target version of Java).

(2) This seems to indicate all sorts of problems, and doesn't even touch Java 7: http://www.oracle.com/technetwork/java/javase/compatibility-137541.html

(3) Some Java 1.3 and earlier functions that were earlier deprecated have been removed (in Java 7) for security reasons (the reasons they were deprecated to begin with).

I believe your organisation is doing something strange.... You should either pay for Oracle support, and receive bug fixes early, or pay developers who can quickly fix JRE bugs themselves, and that will be still a tiny fraction of your IT budget.

WE didn't create the problem, and we are well versed on fixing it. When the previous code owners had to pay IBM to fix custom code for FileNet (written by a company kicked off the project), it cost half a million. I think you missed the part above where I mentioned we got stuck with this disaster during a purchase of another company and their antiquated infrastructure. Also, what I didn't note was that the project was actually started around 2002 on Java 1.3 and possibly earlier.

Re:Damnit

[RobertM1968]

Well dude if you're maintaining an app this complex what do you want? To be baby sat or something? Java is the least awful thing about your situation.

I'm NOT complaining. I love this job - when I am done, this problem will never happen again. I was pointing out that the OP was grossly wrong. That's all. Nothing more. And the ACs comparing what we have to some little dinky web app or 80,000 lines of code (after I spelled out how large this project was) is ridiculous at best.

Re:Damnit

[RobertM1968]

And here's more...

...was deprecated in J2SE 5.0. It has been disabled in Java SE 6, and it will be removed in the next release.

There are a lot of those if you step through the Java versions. Most people don't realize it ever. I ran into it first hand. ;-)

Either way, I love this job, especially since part of my project is to make sure this gets done correctly (instead of what happened under the previous code owners).

Re:Damnit

[sproketboy]

Cool. It just reminds me of a talk someone gave about a big project in C++ which had a hellish 20 hour build. :) What's your relationship with Star Trek Phase II? It looks like you write a number of articles for them on their site.

Re:Damnit

[Anonymous Coward]

"(including *SUN* libraries that don't work in Java 6/7)"

You know that com.sun.* was never intended to be a stable API, right? You were using private APIs, now complaining that they broke, and blaming Java? That's some misdirected anger IMHO.

Re:Damnit

[RobertM1968]

Cool. It just reminds me of a talk someone gave about a big project in C++ which had a hellish 20 hour build. :)

It's great stuff. One of the things I am enjoying the most about it is cutting the number of needed interlinking systems and technology down to a bare minimum using methods in one messaging system that everything can connect to (with MQ once again giving the assist where needed). Also wrapping EVERY vendor function from EVERY vendor library I deal with - in the end, with everything compiled with that one new wrapping library, it means all we ever have to do is deploy a new vendor library with an updated wrapper library - instead of changing code across hundreds of projects.

What's your relationship with Star Trek Phase II? It looks like you write a number of articles for them on their site.

One of the producers and the lighting guy (Gaffer). One new episode out this past Dec 31st, and another coming soon (once we manage the daunting task of color correcting from the original raw footage).

Re:Damnit

[RobertM1968]

"(including *SUN* libraries that don't work in Java 6/7)"

You know that com.sun.* was never intended to be a stable API, right? You were using private APIs, now complaining that they broke, and blaming Java? That's some misdirected anger IMHO.

I used no such thing. I inherited the code when the company I work for bought another company and their infrastructure.

Re:Damnit

[sproketboy]

"cutting the number of needed interlinking systems and technology down to a bare minimum"

Yeah that's the beauty of Java. In our company they use a lot of .NET and many of the teams gave up on moving things to 64 bit. For us with Java we were done in a week.

"One of the producers and the lighting guy (Gaffer). One new episode out this past Dec 31st, and another coming soon (once we manage the daunting task of color correcting from the original raw footage)."

Very cool! I wrote a script a long while ago which you might like (or find a use for).

https://web.archive.org/web/20...

It's a next-gen script but could be adapted. It's got good pacing and it's an easy read. :)

Re:Damnit

[RobertM1968]

Very cool! I wrote a script a long while ago which you might like (or find a use for).

https://web.archive.org/web/20...

It's a next-gen script but could be adapted. It's got good pacing and it's an easy read. :)

Cool - please contact me via the Facebook link in my sig or via our startreknewvoyages.com website's contact page.

Re: Damnit

[Anonymous Coward]

It is a rare occasion when deprecated methods actually get removed from Java.

Re:Damnit

[Anonymous Coward]

So basically you have a bloated mess written by morons and that is somehow Java's fault or proves anything about WORA?

Right

Re:Damnit

[Anonymous Coward]

2 years to fix something that can be scripted and ran in a matter of weeks and you are crying about it?

STFU

whohoo! Swiss cheese!

[nurb432]

Just what we need, yet another version to fight with and worry about..

Re:whohoo! Swiss cheese!

[ebonum]

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:whohoo! Swiss cheese!

[Threni]

So, you've not used LINQ on .net yet?

Re:whohoo! Swiss cheese!

[fsterman]

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:whohoo! Swiss cheese!

[viperidaenz]

The ExecutorService from Java 5 does that. Lambda expressions are a fancy way to write anonymous inner classes.

Re:whohoo! Swiss cheese!

[Anonymous Coward]

This.

I don't know what kind of stupid shit they are feeding CSC majors these days, but the lambda shit in java is nothing more than fancy syntax for an anonymous implementation of an interface.

Re:whohoo! Swiss cheese!

[jfengel]

It's a bit more to it than that. It's actually done with a new opcode in the underlying JVM, which allows them to implement those classes without having to construct new inner classes for each. There were cases where large numbers of nearly-identical inner classes were costing too much memory in certain parts of the JVM, and the new opcode makes that more efficient. (This was more a problem for Scala than for Java itself.)

But yeah, from a Java perspective, it's just syntactic sugar for anonymous inner classes. It's a particularly nice piece of syntactic sugar, since it makes the code more robust to certain kinds of changes by eliminating redundancy. You could, for example, change the name of the implemented class or the name of the method without breaking every lambda. Plus, it's nice to have that redundancy gone: a good IDE could resolve some of it for you but it makes the code more verbose than is strictly required.

Re:whohoo! Swiss cheese!

[viperidaenz]

So I had a read about it, lambda are done with the new invokedynamic instruction.
A JRE may still choose to implement them as classes though.

If you changed the name of the interface, you'd still need to recompile your code though because invokedynamic requires a MethodHandle, which requires a class/interface.

Re:whohoo! Swiss cheese!

[Anonymous Coward]

You expect people to learn the language they're using? Hah! It's much easier to call the language stupid than to say you don't know all of it. Most people don't even know they don't know it.

Re:whohoo! Swiss cheese!

[Anonymous Coward]

lambdas are far more powerful than shitty anonymous inner classes.

Need to sort a collection of objects in a way not defined by the shitty Comparable and Comparator interface implementations in those objects?

Lambdas can do it without having to touch the objects class code.

Fanboy Glee

[allcoolnameswheretak]

Yaaaaaaay! :D :D :D
More coding shinies!

Re:Fanboy Glee

[vux984]

And another round of everyone getting ask.com toolbars.

Boooo.

Re:Fanboy Glee

[allcoolnameswheretak]

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.

Re:Fanboy Glee

[rmdingler]

You know, like telemarketing, they wouldn't keep pushing that crap if people weren't still falling for it.

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:Fanboy Glee

[Anonymous Coward]

Always hit up http://java.oracle.com/ and get the developer-intended versions rather than java.com - no Ask toolbar crap. Yet.

Re:Fanboy Glee

[Anonymous Coward]

>when you're a winner at the cerebrally capable sweepstakes, you infer intelligence by others that may not exist
Positive projection?

Re:Fanboy Glee

[Dster76]

I wonder why Oracle's own page describing the Ask.com toolbar doesn't describe a single benefit -- that is, unless the end user already thinks that "[searching] the Web using the Ask.com search engine directly from the browser" is a benefit.

https://www.java.com/en/downlo...

Re:Fanboy Glee

[rmdingler]

I'm not sure I like your tone.

Re:Fanboy Glee

[Anonymous Coward]

It's 2014 and Larry still thinks trojan style toolbar installs are the shite.

Re:Fanboy Glee

[Anonymous Coward]

I installed Java 8 today at work (I'm a SW engineer whose primary project targets multiple versions of the JVM and wanted to get an idea of how many of our unit and integration tests would fail when we starting making the switch to support Java 8). When the installer didn't ask me if I wanted to install the toolbar I assumed the worst: it had installed it without asking me. But there wasn't a toolbar to be found in this release. I was pleasantly surprised.

Re:Fanboy Glee

[peppepz]

I think that in that case the JRE will try to install the toolbar the next time it auto-updates.

Re:Fanboy Glee

[WinstonWolfIT]

Most relevant post on here.

Re:Fanboy Glee

[Anonymous Coward]

Where else would we be asking our Java-related customer support questions?

Re:Fanboy Glee

[tsotha]

The problem is while the java platform is extremely important to you and me, it costs money for Oracle to maintain and they don't see much benefit from it. I don't blame them for trying, in some small way, to monetize it.

Re:Fanboy Glee

[Anonymous Coward]

It seems like no-one except me and the guy who made the site actually knows about this: http://www.oracle.com/technetw...

All downloads there are Ask-toolbar free. You'd think geeks of all people would have fucking shared this knowledge by now.

Re:Fanboy Glee

[martin_dk]

In Denmark we're forced to install Java in order to access our banks and tax accounts because the national two-factor security plugin is Java only.

This way the public is elegantly taught that installing browser toolbars is a good thing in order to browse the web securely.

Oracle Denmark does not reply when asked if this is not a serious security or privacy concern.

Nets, the vendor of the Java applet, explains that Oracle can do what they want, and see no reason to argue with Oracle.

Christians Panton, a danish researcher, wrote an experimental JavaScript replacement by reverse engineering the applet, and was met by serious threats from Nets that they would sue him for patent infringements if he was to release the source code or product.

I sure hope that future politicians are more aware of digital social responsibility and enforce stuff like open protocols and open source for our digital infrastructure. In particular bundling or side installing thirdparty products should be strictly forbidden as a contractor for the public. In this case it would force Nets to reimplement their product the day Oracle bundled the Ask Toolbar crapware.

Re:Fanboy Glee

[greg_barton]

I have yet to have that problem with the new java8 install on osx.

Re:Fanboy Glee

[vux984]

I have yet to have that problem with the new java8 install on osx.

or any other platform for which ask.com hasn't gotten around to showing up. Give them time. Apple only fairly recently stopped distributing java directly.

Re:Fanboy Glee

[Anonymous Coward]

It doesn't do with linux installers from Oracle.

I guess they figure that if you are stupid enough to develop on a shitty OS, you won't care.

99% of java code is run on servers, not clients.

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

Re: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

Of course Ellison... that founded Oracle by selling database software to the CIA... cares about protecting their customer's privacy.. Clearly if I someone wanted to protect their data from CIA and NSA snooping their first thought would be to use Oracle software. No conflict of interesting going on there.

~ Revenge of the Tin Foil Hatters

Jigsaw

[Anonymous Coward]

The whole jigsaw thing has a very EJB feel to it. If they ever roll it out, I suspect it'll see a bit of initial usage, then eventually people will decide that it's more of a pain than it's worth and just go back to what we're currently doing.

I've done the java thing for awhile (and not tiny projects either) and have never run into any of the problems that jigsaw would fix. Even using all kinds of weird proprietary 3'rd party libs, I've yet to run into a situation where 2 libraries depend on incompatible versions of the same library. As for managing it all, ivy and/or maven have worked well for me.

Re:Jigsaw

[allcoolnameswheretak]

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

[benjfowler]

I wouldn't say EJB...

More like OSGi. Anybody familiar with writing Eclipse plugins will understand the benefits. And no, it' s nothing like writing EJBs.

Re:Jigsaw

[Miamicanes]

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

[lokedhs]

You realise that that is exactly how the JVM works already? The upper limit you asked for is, in fact, the max heap size that you specify using -mx. The -ms flag specifies the initial heap size. If you never allocate more than that, the VM will not request more memory from the operating system.

Re: Jigsaw

[rastos1]

That is not what he asked for. He asked for the upper limit to be the available ram. Not some stupid low number suitable only for small apps.

Re:Jigsaw

[Gothmolly]

Because Java was developed on Unix, and under Unix you're expected to know what you need the system to do. "It Just Works" is the Windows philosophy which people are now only starting to dig out from under.

Re: Jigsaw

[lokedhs]

Right, and while one might think that that would be an easy and logical thing to do, it turns out that there are very few (if any) situations where raising the -mx to that of available RAM is the right thing to do. That said, I admit that the the defaults today are somewhat messed up too, but raising the default limit to the total RAM is an even worse idea.

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

[cbhacking]

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

[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:Modularity

[Miamicanes]

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 with some app that's so utterly niche, the likelihood of having some other app on the same system that uses the same meaningfully-huge library is almost nonexistent anyway.

Ten years ago, we could cheat & copy the thirdparty jarfiles we used all the time to the JRE's /ext directory. That doesn't work anymore, because Java's near-weekly auto-updates mean it's now a moving target. The /ext subdirectory of today's JRE will be an orphaned wasteland by the middle of next week, and every app that depends upon automagically finding Log4j, HttpComponents, JSAP, and everything else in that directory will break unless we give our app its own copy anyway.

Re:Modularity

[peppepz]

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.

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 which clashes with another library used by another library that is dynamically loaded by another library that you use. Without you knowing.

I get a native application without Java's huge runtime dependencies

What are Java's huge runtime dependencies? For instance the Linux version only requires the X11 libraries if you want to display graphics. It will run on a Pentium 1 machine with 16 MB of RAM.

Providing binaries for every current modern chipset including ARM and MIPS takes me about 30 minutes total to build with my cross compilers.

This is assuming that you write code that doesn't interface with any existing software on the target, which is a rare occurence. Do you talk directly to the hardware? Your cross compiler won't spare you from having to write hardware-dependent code for each of the flavours of your target.

However, saying that cross platform C/C++ is more of a headache than Java is ridiculous. They're all "write once, debug everywhere" options.

With C and C++, you get in the best case to fix up your application to port it into a new operating environment, which is what Java requires you to do in the worst case. And we're not even considering the case of mutually incompatible runtime dependencies.

Re:Modularity

[phantomfive]

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:Modularity

[phantomfive]

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:Modularity

[peppepz]

That's not really a problem on modern systems.....at least OSX

Linux is a modern system, yet that's a problem in Linux. I just had to recompile dozens of libraries because one of them had littered the namespace with its own unprefixed symbols, one of which clashed with another's library's -init function, which didn't get called - so I got a segfault on exit of any application that was using that library. Fortunately the library in question was open source and its binary wasn't stripped, so the problem was easy to spot.

You can use versioned symbols on Linux, but that's not a design requirement, and not a majority of the developers do that.

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.

Not in Java, because all symbols are namespaced by design. It would be a problem if you had two versions of the same library and wanted to use both of them at once.

Re:Modularity

[delt0r]

C/C++ across multiple runtimes on *one* platform are relatively easy, though.

Bullshit. Sure it can be done. But its anything but relatively easy, unless you define relatively easy and sticking a porcupine up your arse. Of course i wouldn't say its all that much harder than java either.

Re:Modularity

[cbhacking]

Uh, what? It's trivially easy to have multiple C/C++ libraries, even including libc itself, present and in use on one machine. It's a pain in the ass to do so with Java.

Random (Windows) example: old game that requires some long-dead version of MSVC that doesn't ship on modern Windows versions? Grab the relevant msvcrt.dll from an older machine and drop it into the program's install folder. Quick, simple, successful.

Re:Modularity

[Anonymous Coward]

make

yeah, simple call, but a firestorm to setup (CMake, autogen, ....)

No different from
git pull && ant

and don't give me the crap about build.xml. I'd take it any day over configure, CMake mess, or makefile logic.

Re:Modularity

[vilanye]

Two libraries could concievably have the same package and class name causing conflicts. Of course that is why the verbose and nasty com.myurl.ten.layers.of.packages.to.get.to.a.class namespacing occurs.

Re:Modularity

[vilanye]

Why?

It just makes updating take that much more bandwidth and time.

When I do use Java(it is usually JRuby) I use 1 jar per top level package and try very hard to make each jar file follow the Unix way(do one thing and do it well). It works great to keep things properly separated and is fantastic for updating.

Lambdas could be interesting

[msobkow]

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:Lambdas could be interesting

[Laxori666]

Yes, finally Java added features that other languages have had for years and years.

Re:Lambdas could be interesting

[Anonymous Coward]

If you want your data free of backdoors, I would stay far away as possible from java (Ellison started his business selling software to CIA and is a long time apologist for the NSA). Even Windows is highly questionable given Gates muted stance on NSA spying. Essentially what it boils down to is listening to management's position on NSA spying to figure out where the backdoors.

IBM, Google, and Cisco seem to be the main ones that are fed up with the national security letters to cover up wholesale spying (in violation of the Constitution I would add).I think others will follow when they start losing billions in international sales because of their lame support for the draconian NSA and GCHQ spying

Re:Lambdas could be interesting

[benjfowler]

Lambdas in Java is a massive development. For most developers, it'll absolutely slash the amount of boilerplate they need to crank out.

They're also an incredibly powerful and expressive construct in their own right.

Re:Lambdas could be interesting

[timeOday]

I don't agree with 'massive.'  It will be more terse, compared to anonymous overrides which are currently used for that.

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");
            }});

Re:Lambdas could be interesting

[Anonymous Coward]

It would now be something like:

button.addActionListener((e) -> System.err.println("Button pressed"));

Re:Lambdas could be interesting

[vilanye]

The point is that lambdas don't have to be tied to the class and can easily change on the fly.

I never understood the draw of anonymous inner classes, or plain old inner classes, especially for GUI code. I never used it, because I hate repeating myself and that is what this clunky mess causes, and it also makes it difficult to reuse the code with different behaviors. I always just had a method in the GUI widget class that accepted listeners dynamically so behaviors could easily change in my Swing library I built up.

Following Java conventions leads to a bloated, un-DRY and ultimately difficult to maintain code base.

It's Official

[AlphaBro]

More vulnerabilities to sell. Thanks, Oracle.

Criticality of JigSaw

[Anrego]

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:Criticality of JigSaw

[gtall]

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:Criticality of JigSaw

[benjfowler]

For the vast majority of 9-to-5 developers, there's no way to make Swing not suck.

Because it simply takes a very high clue level to build good GUIs, period. Swing is nothing special; you can write shit GUIs using AngularJS, Vaadin, SWT _or_ Swing.

Re:Criticality of JigSaw

[pjt33]

Java 8 sort-of has unsigned types.

Re:Criticality of JigSaw

[Anrego]

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:Criticality of JigSaw

[Anonymous Coward]

Java 8 have a new, weak, version of Multiple Inheritance using Default Methods. http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html

These are methods that can be put in to an Interface. So now interfaces are not just abstract method signatures, but also actual implementations. What they can not have, however, is any actual state, those have to be defined in the class implementing the interface.

Re:Criticality of JigSaw

[IamTheRealMike]

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 and bundling it makes your apps have a big download. Boo. JWrapper looks like a good way to make stripped down cross platform native installers though, but I didn't get a chance to try it yet.

Multiple inheritance is a feature nearly no modern language has, but Java 8 does support mixins which are how most languages provide similar functionality (interface method definitions can now have bodies).

Re:Criticality of JigSaw

[cbhacking]

... 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:Criticality of JigSaw

[Anonymous Coward]

While reading on multiple inheritance on Wikipedia, I noticed the following:

Java 8 introduces default methods on interfaces. If A,B,C are interfaces, B,C can each provide a different implementation to an abstract method of A, causing the diamond problem. Either class D must reimplement the method (the body of which can simply forward the call to one of the super implementations), or the ambiguity will be rejected as a compile error.

This sounds like a form of multiple inheritance, and sounds like a somewhat intuitive addition instead of changing fundamental functionality. Of course you need to get the variables from getters instead of accessing them directly, but that shouldn't be too much of a problem.

Re:Criticality of JigSaw

[hibiki_r]

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:Criticality of JigSaw

[Anonymous Coward]

JTable? That's easy. Now, make me a true multicolumn JTree.

Re:Criticality of JigSaw

[JoGiles]

JTable? That's easy. Now, make me a true multicolumn JTree.

JavaFX ships with a TreeTableView control specifically to do this.

Re:Criticality of JigSaw

[JoGiles]

What do you find missing from JavaFX - I'm one of the engineers on the JavaFX team and am curious about what exactly you need?

Re:Criticality of JigSaw

[sproketboy]

- JavaFX
- MI - Java 8 now has defaults in interfaces.

Re:Criticality of JigSaw

[phantomfive]

- multiple inheritance (yes I know, old argument, but I want it damnit!)

They got closer.......interfaces can have default implementations.

Re:Criticality of JigSaw

[Anonymous Coward]

1.System Tray support 2.bi directional font for supporting rtl language ( this one i think should supported in jdk8 ) 3.camera and mic 4.better file chooser but Congratulations , if you can improve javaFx , with more Api, it will be more than enough for java developer

Re:Criticality of JigSaw

[Anonymous Coward]

How about proper support for the taskbar & tray? From my last use of JavaFX, it didn't look like this was supported. You need a Swing hack to get tray support in a JavaFX app, and new taskbar features like download progress on Windows is not supported.

There was limited / no support for dialogs. You needed to use a 3rd party library (ControlFX) for that (or roll your own dialogs).

Also, there seems to be some inconsistency with the controls. Some controls support changing font, colors etc via the API, others don't and require modification through CSS.

Re:Criticality of JigSaw

[vilanye]

Swing is a little verbose and unwieldy, but people tend to forget(or maybe they just don't know) that it is a very low level GUI library that is great for creating custom, reusable widgets(assuming you don't use crap like anonymous inner classes). It is not meant to be a high level GUI library. For a layout manager use Miglayout, seriously, how did this not get included into the standard library?

JavaFX 2 is much easier to manage and layout as long as your requirements don't call for seriously complex GUI elements. It ditched that crappy language that plagued JavaFX 1 and uses a simple functional approach.

File choosers - again Swing is meant to be a low level GUI library.

Java doesn't integrate well with underlying system so why are you using java for command line apps?

Unsigned types? I would prefer that they add in integer overflow protection instead.

They should deprecate interfaces and add in mixins over multiple inheritance. It has all the advantages of both, without the boilerplate of interfaces and potential mess of MI. Could you imagine the mess that the typical over-engineering of Java would make of MI? The horror!

No properties

[SumDog]

...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:No properties

[Ksevio]

It's nice to see they've added lamda expressions, but the lack of properties is a serious oversight in Java that should have been added years ago. It's not even a hard concept to add and it fits in just find the OOP model.

Re:No properties

[iced_773]

Try Project Lombok. It completely abuses the original intent of annotations, but it does cut out a lot of boilerplate.

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:No properties

[ahabswhale]

You've clearly never used a language with a properties construct.

I passionately despise getters and setters.

Re:No properties

[AuMatar]

Really, you're complaining about typing 3 extra letters? THe fact that they didn't add properties is the smartest thing they've done in decades. Properties are a stupid idea. If you want them to set a variable directly, make it public. If not, don't hide the fact a function is being called by making it look like an assignment- it causes bugs and inefficiencies for absolutely 0 gain.

Re:No properties

[cbhacking]

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.

Re:No properties

[Anonymous Coward]

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.

A massive list of setters (or writable properties) means the object is not encapsulated, time to rethink the object model.

Re:No properties

[Slashdot Parent]

Seriously? getBlah()? setBlah()?

Eh. I just add accessors via AOP since I hate maintaining 'em. Or even looking at 'em, frankly.

6 Years behind .NET?

[Anonymous Coward]

Cute. Also, pretty sure that we have had Native Interop and runtime dependency binding since 2001. With Mono finally catching up with .NET and Xamarin putting together good tools, I have no reason to ever use Java again (and haven't since Oracle picked it up.)

Bundled Crapware?

[germansausage]

Does it still come bundled with Crapware? Why can't Oracle just put a bullet into whoever signed the deal with Ask.com, and start behaving like a big software company again?

Re:Bundled Crapware?

[Anonymous Coward]

Just install the JDK., or even the runtime from the JDK; never even knew about the scumware.

Re:Bundled Crapware?

[evilsofa]

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

You evidently don't have any idea what you're sayi

[Anonymous Coward]

Why don't you mention 5 of these so many libraries in your hundreds of projects that are backwards incompatible? In my 11 years of using Java I have never ever heard of this issue, so maybe I learn something! The problem is always the opposite, code compiled on newer compilers can't run on older JVMs, not the opposite! Backward compatibility has always been guaranteed in Java and issues are very rare. So its either your vendors are sucking money out of you with some imaginary two year project, or you are just talking out of your behind.

Why don't you share with us your problem and your 'gigabytes' of code? (If you really have something of that sort its probably written by a bunch of retards who just copy and paste code anyway... I wonder what is this magical enterprise level software of yours which needs to be so bloated).

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

Re:Too little, too late

[Anonymous Coward]

Scala is a mess and it's already imploding, and Clojure is dynamically typed. It's blatantly obvious that neither of them have a future.

Re:Too little, too late

[phantomfive]

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.

Re:Too little, too late

[shaven_llama]

Well, you're probably right... but I think that says more about your average programmer than about the utility of lambda expressions. The biggest complaint I hear about Scala (or any other FP language) is that it's too hard to learn. I've even had a coworker tell me that since Java does "everything", there is no need to learn any other language (I didn't know how to respond to that).

I'm still waiting for that FP renaissance....

Re:Too little, too late

[Daniel Hoffmann]

Explain calmly what Turing Complete means and then say you can do "everything" in algol too!

Re:Too little, too late

[phantomfive]

I'm still waiting for that FP renaissance....

Would you satisfied with Haskell, or would you prefer something with more features? What is it about functional that you really really like?

Re:Too little, too late

[shaven_llama]

I'm quite satisfied with the current crop of functional languages, what I'm waiting for is widespread adoption so I can stop working with Java to pay the rent. What do I like about it? The expressiveness of FP and immutability-by-default (makes concurrent programming much less headache inducing), are two major benefits, I suppose.

Re:Too little, too late

[phantomfive]

The expressiveness of FP and immutability-by-default

I guess that's what I like about it, too

Fire Up the Regression Finder

[organgtool]

Now is the perfect time to build out a test server, fire up your applications, and start looking for all of the regressions. File the bug reports early and make sure that all of them are fixed before you even attempt to deploy this to your servers. Lately Oracle has been one of the worst offenders for regressions to the point that it seems like they threaten death to developers who test anything other than the new features.

Why don't you mention them?

[Anonymous Coward]

You need to state the open source projects you are referring to, if your argument is real.
The only reason for something like that to happen is if the code is not pure Java but has some kind of native concoction of things, which is outside of the JVM control.
If it is a pure Java project you should have no issue whatsoever.

Re:Why don't you mention them?

[ultranova]

The only reason for something like that to happen is if the code is not pure Java but has some kind of native concoction of things, which is outside of the JVM control.

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.

What open source projects are they?

[Anonymous Coward]

Why don't you mention them so that we understand. This sounds highly unlikely.

Are you kidding!?

[Anonymous Coward]

Almost any time I installed a new jar into an existing project, I had jar conflicts. It happens constantly. especially with log4j and xerxces.

Re:You evidently don't have any idea what you're s

[ClioCJS]

B.S. ... I downloaded Slime Volleyball and set it up on my own webserver. 1 java upgrade later, it wouldn't work right. Explain. (This was 2001.)

.NOT

[Anonymous Coward]

Sigh...no one outside the Windows world gives a shit about .NET

Re:.NOT

[Anonymous Coward]

And no one who doesn't have a full beard running halfway down their neck gives a shit about "open source". Fucking neckbeards.

Re:.NOT

[am 2k]

Sigh...no one outside the Windows world gives a shit about .NET

Don't forget Unity3D developers, they care much about C#. Although Unity3D uses an ancient version of the mono runtime...

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.

We get font and occasional video driver...

[Anonymous Coward]

issues between platforms. So it's not perfect. But it's pretty damn good.

Re:You evidently don't have any idea what you're s

[jrumney]

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.

Re:Did they finally straighten out the 64-bit mess

[msobkow]

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.

Aww, they caught up to C# 3.5!

[RightSaidFred99]

How cute! Java is only about 5 years behind. They'll catch up one day, by gum!

I kid, I kid. I have to do some Java stuff and this is definitely welcome but sorry - given the choice I will pick .NET/C# every time where possible.

Re:Aww, they caught up to C# 3.5!

[IllusionalForce]

I do have to wonder: Which platforms does your software target?

Re:Aww, they caught up to C# 3.5!

[Anonymous Coward]

Windows, with a Java CLI. Or it did. Recently moved to a Python and UNIX type job, which sucks balls. I feel like I am slumming.

Re:Aww, they caught up to C# 3.5!

[angryfeet]

If Java can't compete now, just imagine what a whitewash it's going to be once C#6.0/Roslyn arrives.

Re:Aww, they caught up to C# 3.5!

[sproketboy]

Then you're an idiot. We Java people appreciate C# being the beta test language for us.

Re:Aww, they caught up to C# 3.5!

[Anonymous Coward]

And we C++ people find you Java/C# paint-by-number programmers cute for arguing which of your toy languages is superior.

Re:Aww, they caught up to C# 3.5!

[Anonymous Coward]

and we C developer are very happy with C++ bullshet and OOP scientific computing and template metaprogramming crap is away from us

and yet...

[slashmydots]

I think by now everyone knows Java was responsible for the vast majority of drive by infections on the web. Lately they've made Adobe look secure by comparison. By adding development features instead of fixing their security of even just their stupid updated that stalls out permanently all the time, they've shot themselves in the foot. Half my customers at my computer repair shop absolutely refuse to use or install java under any circumstances. Lots of companies are banning all java-based software for security reasons. My former employed switched their multi-million dollar bank account to another bank to avoid the original bank's java web plugin-based internet banking. Java is dying. Who cares if 8 is coming out?

Re:and yet...

[Chrisq]

I think by now everyone knows Java was responsible for the vast majority of drive by infections on the web. Lately they've made Adobe look secure by comparison. By adding development features instead of fixing their security of even just their stupid updated that stalls out permanently all the time, they've shot themselves in the foot. Half my customers at my computer repair shop absolutely refuse to use or install java under any circumstances. Lots of companies are banning all java-based software for security reasons. My former employed switched their multi-million dollar bank account to another bank to avoid the original bank's java web plugin-based internet banking. Java is dying. Who cares if 8 is coming out?

That's why the dropping of Jigsaw was a shame. If implemented properly it would have given modules with a defined interface but no ability to access, substitute or alter the classes underneath by other means.

Re:and yet...

[Anonymous Coward]

Mr Computer Repairshop Guy - please let us know where your repair shop is so we can avoid it. Your head is way too far up your ass.

Re:Did they finally straighten out the 64-bit mess

[evilsofa]

But java.com states that it's about whether you're using a 32 or 64 bit browser, not OS:

http://www.java.com/en/downloa...

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:Did they finally straighten out the 64-bit mess

[Miamicanes]

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.

Solution

[xded]

http://superuser.com/a/562869/...

Re:Did they finally straighten out the 64-bit mess

[msobkow]

And why, pray tell, are you installing a 32 bit browser on a 64 bit OS when every browser I know of comes with targetted builds?

Monetizing java

[rve]

The problem is while the java platform is extremely important to you and me, it costs money for Oracle to maintain and they don't see much benefit from it. I don't blame them for trying, in some small way, to monetize it.

I don't quite agree with the parts of your post that I quoted.

- Control of Java was probably one of the main reasons for Oracle to buy Sun
- Java makes Oracle a lot of money through licensing and support contracts. You may not be paying for it, but large corporations are.
- The Ask toolbar thing started with Sun, not with Oracle. It actually started with the Google toolbar, but when Google started to push Android (killing Java ME), the relationship soured, and Sun started to promote a competing toolbar instead.

Re:Did they finally straighten out the 64-bit mess

[delt0r]

This is the applications installers fault. Properly installed the user never need know its java/C/C#/Lisp whatever you want. I have my java apps installed properly and most have no idea its java. Well pedantic UI nut jobs know its not native. But they are a minority.

On the flip side there are plenty of native apps that have all sorts of issues on Windows as well. Just look at any "install problems" section on a game forum.

anonymous coward

[Anonymous Coward]

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?

Standing on the shoulders of giants is different than tackling and gang raping the giant. No wonder the giant slit its wrists.

Oh my, another person criticizing Open Source because of their own laziness and incapabilities.

Wants everyone to build everything for them, for free, so they can mooch.

Whine whine whine. If you want something to grow, you have to water it. You don't sit and bitch that noone else is watering it and it died, you WATER THE DAMN THING.

Where did all these crybabies come from?

Re:anonymous coward

[tompaulco]

I don't necessarily want to use open source. It is more of a company mandate to never write a line of code that is not necessary. Me, I would prefer to write something that does A myself in a day, having full knowledge of how it works and be certain it works with our system rather than spend weeks trying to understand and integrate a package that does A-Z, where only A is required, but does not quite work in the way that our system needs it to, and fails in various difficult to troubleshoot ways deep in the heart of some code three dependencies deep.

Re:Did they finally straighten out the 64-bit mess

[rastos1]

Let me introduce you to Firefox on Windows - 32-bit only.

Re:Did they finally straighten out the 64-bit mess

[rastos1]

Are you saying that the java classes in .jar are compiled differently for 32 and 64-bit JVM? Bollocks. But yes, the idea of platform independence can be torpedoed by a well aimed .dll hidden in the .jar. Blame the vendor.

ODBC?

[Anonymous Coward]

I see they've removed the ODBC bridge. Is there any other way to talk to ODBC databases with Java?

Re:ODBC?

[kiwipom]

I see they've removed the ODBC bridge. Is there any other way to talk to ODBC databases with Java?

JDBC

Re:You evidently don't have any idea what you're s

[Muad'Dave]

That's because websphere runs by default on IBM's proprietary JVM.

Re:Did they finally straighten out the 64-bit mess

[sproketboy]

Call the wahhhmbulance! Dude spend any time in .NET and you will learn to appreciate Java. Try porting any non-trivial .NET app to 64 bit. Have fun with that. Once COM comes in to the picture (and you can never avoid &*^*&^*&^ COM even now in the 21st century) you're already fuked.

Ob

[Hognoxious]

So how many years experience in it do I need to get a job?

Finally has lambdas?

[Anonymous Coward]

It is almost 1962 in Java Land.

By 2050, it will be 1990.

Re:You evidently don't have any idea what you're s

[aled]

you are joking, right? I can't tell for sure.
Or are you really complaining from a problem in year 2001?

Re:You evidently don't have any idea what you're s

[ClioCJS]

Were java's promises different in 2001 than 2014? No. It only takes one counterexample to execute a tautology.

Re:Did they finally straighten out the 64-bit mess

[Anonymous Coward]

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.

If there's one thing Java doesn't need, it's more security holes.

Re:You evidently don't have any idea what you're s

[Anonymous Coward]

You didn't follow the guidelines somehow, and the implementation became less flexible with how much it was prepared to do for you. I remember something like this also, but didn't blame Java.

Re:Did they finally straighten out the 64-bit mess

[McLoud]

Try to use PKCS12 in windows 64bit jvm and see how far you get. Hint: it's non existent because the original code is C and nobody's bothered to compile it because "they didn't have a 64 bits smartcard to test it on"

Re:Did they finally straighten out the 64-bit mess

[hfranz]

Any program that uses JNI and bundled libraries, i.e. anything that uses SWT like Eclipse _is_ bound to the architecture of the native library.

Re:Did they finally straighten out the 64-bit mess

[hfranz]

Shouldn't java -d32 -version:1.7 -jar myapp.jar on Windows make Java use any installed 32bit Java 7 runtime without the User having to specify the full path to the installation directory?

Re:Did they finally straighten out the 64-bit mess

[jwhitener]

I have about 10 different java versions installed on my windows 7 computer at work. When I want to use one particular version of java I run a script to set JAVA_HOME, PATH, etc.. to the appropriate java. Ditto if I'm working on Solaris, Linux, or any other system.

I'm not exactly sure how this could be: "Java is my main language & I end up using it for almost everything" without knowing how to handle multiple java versions in windows.

I do think it would be nice (if possible) to install 32bit and 64bit and have the exe determine which jvm to use.

In terms of UAC, why aren't you launching java.exe as administrator and bypassing the uac headaches..or simply turning UAC off?

Re:You evidently don't have any idea what you're s

[RobertM1968]

You didn't follow the guidelines somehow, and the implementation became less flexible with how much it was prepared to do for you. I remember something like this also, but didn't blame Java.

What part of "we inherited this disaster during a company buy-out" did you miss? Nor are most of the issues not "follow(ing) the guidelines" - some of the Java 1.3/1.4 calls have been totally removed, or revised.

Re:You evidently don't have any idea what you're s

[RobertM1968]

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.

And you guessed correctly. So... IBM WAS, Oracle App Server/WebLogic with IBM Java, and Oracle (pre-Sun purchase) Java - plus good ol Sun Java in the mix. Each (of the first two) to use specific libraries written by FileNet (not IBM - IBM cleaned things up in later releases *after* they bought FileNet) or for OAS. :-/