The vast majority of projects, at my employer. I personally upgraded several hundred JVMs running several dozen services - upgrading was simple and almost entirely painless.
In addition to benefiting from the new features, being up-to-date is good for recruiting. You tell someone they'll be working with Java 6 and (in the absence of other evidence) they'll assume it's a legacy product suffering from chronic under-investment. Not exactly the impression you want to give job seekers!
The annoying thing is that Java 8 is the only currently supported version of the language. The glacial development speed somehow still manages to deprecate versions faster than they fall out of use.
Are you serious? Even the worst shops I've been at have at least moved their JVMs to Java7 back around 2014. I mean you can take all your existing JARs from Java4 and run them on Java8 and nothing should break. Recompiling them might be another issue, but still not a huge one.
Most not totally old projects are on JDK8. Don't look at some crufty apache product, but look at medium size business apps... those have all been JDK8 for a while now.
Been coding Java for close to 20 years. Can anyone show me what's being done in the language to bring on newcomers, or did that ship sail 10-15 years ago?
Some ideas that would bring people back:
* Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named.
* Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
* Similarly be able to generate the JavaScript front-end code that use those JS client libraries with easily writable/pluggable generators so that it can generate Angular 1.x, 2, ReactJS, Bootstrap, etc. in "best-practice" ways that can be updated frequently as the community changes.
* Simultaneously provide the option to serve very similar pages using straight HTML, degrading even to the point that a text only browser could use the site easily.
* Easily define responsiveness of pages.
* Support multiple 3D, 4D, etc. interfaces with customizable inputs to be forward-compatible without overdoing complexity (i.e. it's really pluggable).
* Similarly support generation of almost any kind of service integration, with easy pluggable authN/R.
* Easily scalable.
* Relational, noSQL, versioning DB (noms) support.
* Make fun books for kids and a site where they can share what they've written, write games, build things, etc.
* Make it integrate with every browser, even some older versions, operating systems.
* Make it compile low-level vs. byte code so it's fast as shit.
> great library of built-in tools that are briefly and intuitively named.
I dunno, guess this depends on what you need. The Java class library has so much in it, but I guess it's not overly intuitive due to the age of a lot of the packages. Personally, I don't think I'd have a hard time getting my .Net-loving colleagues accustomed to everything as is.
Java EE is another matter entirely, I gave up on it after the Java EE 8 clusterfuck that's going on and have just decided to use Spring for everything.
> Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
What are you looking for here? Automagic API's? spring-data-rest says hello. I still find it's better to write my own, but if you need something for a quick prototype there you go.
> Easily scalable.
How are you wanting to scale? Where is your bottleneck? This isn't on the language to solve, it's how you design your application. I can throw up 2,000 instances of an application, but whether the database behind it can handle 100K/tx/sec is another story entirely.
> Relational, noSQL, versioning DB (noms) support.
We've had JDBC, JPA, jOOQ, QueryDSL, etc, forever for the relational story. There's plenty of support out there for various NoSQL databases (Spring even has spring-data-cassandra which I am looking at using right now for an ES/CQRS design).
> Make it integrate with every browser, even some older versions, operating systems.
Why? Java in the browser is dead. If you want to write client-side stuff just use JavaFX and package using WebStart or an installer that bundles your JRE and dependencies.
> Make it compile low-level vs. byte code so it's fast as shit.
Java is already "fast as shit". The warmup time for HotSpot and initializing the JVM is probably the big complaint everyone has, but unless you are writing small command line tools it is a complete non-issue.
With that said, Java 9 will support limited AOT compilation of modules to reduce the time to get basic compiled versions of your classes - HotSpot will still profile the compiled modules, and if finds it is required it will deoptimize, re-profile through bytecode interpretation and reoptimize - just like it does with normal .class files (which are still required to run).
Thanks for the bullets. This is a good list but some of the points like "Easily scalable" and "DB support" are not cheaply available in any runtime and require careful attention to detail as well as domain-specific thinking. IMHO, the JVM already does a lot of heavy-lifting in this regard.
>Make it compile low-level vs. byte code so it's fast as shit.
AOT compilation is not automatically faster than JIT compilation. Java already is fast as shit. If you're worried about that first 100 milliseconds, works is being done on AOT compilation.
Most of that seems overly specific and wouldn't be appropriate for the core of a general purpose language. There's a whole world of software outside of web applications. Leave that stuff to separate libraries and frameworks.
While I can't say with 100% confidence, I listened Graal presentation at Voxxed Days Belgrade one month ago and the presenter (IIRC, Martin Tonchev) said it won't be ready for JDK9 and that they aim at JDK10.
Or you could not make assumptions like this. There are more ways to represent dates than there are bones in my body. What seems like a silly way to you might be the preferred way for someone else, for a variety of reasons.
[+] [-] spullara|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
[+] [-] bitmapbrother|9 years ago|reply
[+] [-] namelezz|9 years ago|reply
Edit: It seems removing unsafe is just a rumor.
[+] [-] merb|9 years ago|reply
[+] [-] jwn|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
[+] [-] geodel|9 years ago|reply
http://openjdk.java.net/projects/jdk9/
[+] [-] javanese|9 years ago|reply
I still see projects using Java 5...
[+] [-] michaelt|9 years ago|reply
In addition to benefiting from the new features, being up-to-date is good for recruiting. You tell someone they'll be working with Java 6 and (in the absence of other evidence) they'll assume it's a legacy product suffering from chronic under-investment. Not exactly the impression you want to give job seekers!
[+] [-] ygra|9 years ago|reply
[+] [-] djsumdog|9 years ago|reply
Are you serious? Even the worst shops I've been at have at least moved their JVMs to Java7 back around 2014. I mean you can take all your existing JARs from Java4 and run them on Java8 and nothing should break. Recompiling them might be another issue, but still not a huge one.
[+] [-] brianwawok|9 years ago|reply
[+] [-] elygre|9 years ago|reply
[+] [-] theandrewbailey|9 years ago|reply
[+] [-] renyalvarado|9 years ago|reply
[+] [-] haalcion3|9 years ago|reply
Some ideas that would bring people back:
* Wildly new, terse, and clear syntax and a great library of built-in tools that are briefly and intuitively named.
* Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
* Similarly be able to generate the JavaScript front-end code that use those JS client libraries with easily writable/pluggable generators so that it can generate Angular 1.x, 2, ReactJS, Bootstrap, etc. in "best-practice" ways that can be updated frequently as the community changes.
* Simultaneously provide the option to serve very similar pages using straight HTML, degrading even to the point that a text only browser could use the site easily.
* Easily define responsiveness of pages.
* Support multiple 3D, 4D, etc. interfaces with customizable inputs to be forward-compatible without overdoing complexity (i.e. it's really pluggable).
* Similarly support generation of almost any kind of service integration, with easy pluggable authN/R.
* Easily scalable.
* Relational, noSQL, versioning DB (noms) support.
* Make fun books for kids and a site where they can share what they've written, write games, build things, etc.
* Make it integrate with every browser, even some older versions, operating systems.
* Make it compile low-level vs. byte code so it's fast as shit.
[+] [-] hota_mazi|9 years ago|reply
I don't think Java needs any help in that department given how crazy popular it is.
And Android has made it even more popular than it ever was these past eight years.
Java has a few issues but the learning curve is not one of them.
[+] [-] snuxoll|9 years ago|reply
Kotlin
> great library of built-in tools that are briefly and intuitively named.
I dunno, guess this depends on what you need. The Java class library has so much in it, but I guess it's not overly intuitive due to the age of a lot of the packages. Personally, I don't think I'd have a hard time getting my .Net-loving colleagues accustomed to everything as is.
Java EE is another matter entirely, I gave up on it after the Java EE 8 clusterfuck that's going on and have just decided to use Spring for everything.
> Easily write and design interfaces that generate both/either back-end or matching integrated front-end code which is off in its own directory and can easily be used by existing JavaScript and HTML.
What are you looking for here? Automagic API's? spring-data-rest says hello. I still find it's better to write my own, but if you need something for a quick prototype there you go.
> Easily scalable.
How are you wanting to scale? Where is your bottleneck? This isn't on the language to solve, it's how you design your application. I can throw up 2,000 instances of an application, but whether the database behind it can handle 100K/tx/sec is another story entirely.
> Relational, noSQL, versioning DB (noms) support.
We've had JDBC, JPA, jOOQ, QueryDSL, etc, forever for the relational story. There's plenty of support out there for various NoSQL databases (Spring even has spring-data-cassandra which I am looking at using right now for an ES/CQRS design).
> Make it integrate with every browser, even some older versions, operating systems.
Why? Java in the browser is dead. If you want to write client-side stuff just use JavaFX and package using WebStart or an installer that bundles your JRE and dependencies.
> Make it compile low-level vs. byte code so it's fast as shit.
Java is already "fast as shit". The warmup time for HotSpot and initializing the JVM is probably the big complaint everyone has, but unless you are writing small command line tools it is a complete non-issue.
With that said, Java 9 will support limited AOT compilation of modules to reduce the time to get basic compiled versions of your classes - HotSpot will still profile the compiled modules, and if finds it is required it will deoptimize, re-profile through bytecode interpretation and reoptimize - just like it does with normal .class files (which are still required to run).
[+] [-] gshx|9 years ago|reply
[+] [-] pgwhalen|9 years ago|reply
AOT compilation is not automatically faster than JIT compilation. Java already is fast as shit. If you're worried about that first 100 milliseconds, works is being done on AOT compilation.
[+] [-] nradov|9 years ago|reply
[+] [-] ksec|9 years ago|reply
[+] [-] ivanche|9 years ago|reply
[+] [-] ape4|9 years ago|reply
[+] [-] Tharkun|9 years ago|reply
[+] [-] DiabloD3|9 years ago|reply
[+] [-] sytringy05|9 years ago|reply
[+] [-] Bjartr|9 years ago|reply
[+] [-] Scarbutt|9 years ago|reply
[+] [-] geodel|9 years ago|reply
[+] [-] puppetmaster3|9 years ago|reply
I see no JSON, I have to use a 3rd party lib. And ... no word on fixing logging divergence.
[+] [-] benjiweber|9 years ago|reply
http://paste.debian.net/883460/
( May be incredibly unsafe, only just thought of it now. )
[+] [-] theandrewbailey|9 years ago|reply
https://docs.oracle.com/javaee/7/api/javax/json/package-summ...