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?

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

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

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

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

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

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

[teefal]

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

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

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

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

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

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

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

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

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

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

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

[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

[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

[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]

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

[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

[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

[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

[ChunderDownunder]

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

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

[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

[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

[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

[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

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

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!

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

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

[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

[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

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

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

[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

[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

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

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.

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

[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

[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

[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

[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

[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

[Slashdot Parent]

Seriously? getBlah()? setBlah()?

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

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.

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?

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

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

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

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

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.

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

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!

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

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

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

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.

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.

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

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

Ob

[Hognoxious]

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

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

[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. :-/