JDK 10: General Availability
mail.openjdk.java.net
mail.openjdk.java.net
https://www.opsian.com/blog/java-on-docker/
Relevant JEPs:
https://bugs.openjdk.java.net/browse/JDK-8146115
Thanks!
[0]: https://blogs.oracle.com/java-platform-group/java-se-support...
For example, 8u131 and 9 only supported cpu sets whereas 10 includes support for cpu shares. Available memory detection in 10 applies to the whole of the JVM rather than just the heap on 8u131 and 9.
Reading elsewhere they are apparently moving to a 6 month release cycle.
For people using Java in businessey environments, I'd love to hear your thoughts on this. Do you think you'll be able to keep up with the JDK changing twice a year? When I was in this game we were always on versions that were years behind, but maybe this has changed.
Why is it Oracles fault that you keep your components on Java version that has been deprecated and support dropped 4 years ago?
>What company with a reasonably large software base is going to keep up with a six-month release schedule?
What? No. That's now how it works. Every 3rd release is LTS and it support time is between 6 and 11 years as so far discussed. Java8 won't be supported after January 2019, Java11 (LTS) will be release in September this year.
> Java isn’t a web browser or some other user application. Who would even _want_ to spend the kind of resources required to constantly be testing new JDK releases?
You're not supposed to be testing it. You're supposed to write code to a contract, contract won't or shouldn't change. If you write code that follows implementation instead a contract (let's say you relay on HashSet order - I've seen it), it's your fault. We always make sure we write code that follows the contract. We're migrating our code base to Jigsaw now, after Spring 5 and SpringBoot1.5 were release with updated dependencies. If Spring and Tomcat teams made it available earlier, we would be on Java9 months ago.
What if part of your application is audited and certified by some regulatory body, when you upgrade, you need to go through the process again.
Java value is stability, you can assume your software will run for 20 years without touching it.
No, but they are restricting them from updating as easily as before -- unless they cough up dough.
Before you could go to any version and expect it to be supported for years.
Now, if you dare go to some version above 8, you're supposed to either pay (for long term support), jump directly to the next version after a few months, or stay without security fixes.
(Or go OpenJDK and screw them).
So, yeah, I think a faster release cadence is a good idea! Upgrading the runtime should be as simple as upgrading any other dependency.
Are they dropping support for the latest LTS just four month after releasing a new LTS? That sounds a bit harsh.
There are many examples of migration problems for any platform - just have to google it. When information that can challenge our assumptions is just a google search away, I don't see why one should hold on to blind faith in idealistic assumptions. Here's one writeup of a system whose performance suffered simply by migrating to Java 8 without involving any code changes [1].
[1]: http://engineering.indeedblog.com/blog/2016/09/job-search-we...
For the first time in years, I'm looking at alternatives to Java for my next project. Java was always seemed to offer a pragmatic compromise in terms of language design and features and the availability of developers and libraries. Rapid breaking releases destroys most of the value of Java for me.
It’s just now Java gets to iterate and improve more frequently and regularly.
Regardless there are still LTS releases (every 3 years) for people who lean more conservative.
https://stackoverflow.com/questions/34659055/java-8-incompat...
The real killer with the six month releases is not that they're every six months. That's doable. The killer is that they have zero support (even for security issues, I believe) once the next release comes out. As a result, you have to be ready to switch immediately. If you could upgrade to Java 10, then wait twelve months and go to 12, it would be less painful.
Almost nothing is broken in Java. Jigsaw modified who to use reflection to access data in an insecure manner. You should not be doing that in the first place for obvious reasons. But the code that was using reflection still works, you just get a warning when starting an application. That's all.
>No "user" is interested in comparing theoretical specs with the behaviour of the reference implementation
So you're probably not going to write any code in any strong-typed programming language, all of them have some kind of contracts you should/have to follow.
Do you know that Oak source code (what Java was called before) still compiles and runs in Java10?
You are just repeating that it's fundamentally the user's fault because they "should not be doing that". A properly designed tool prevents incorrect usage. If a version of Java allows you to do something and that something proves to be very useful to GET THE JOB DONE, then I'm with Linus - the blame is not with the user.
For example, there was simply no alternative to using Unsafe in the past to get reasonable Java performance for certain task. The fact that it was there allowed me to resist the pressure to move a significant part of our codebase to C++. Of course we "should not be doing that" (using Unsafe) but the alternative was abandoning a large existing code base and hiring a bunch of C++ experts or retraining our existing developers or spending 10 times as much on our server capacity. Using Unsafe was a simple pragmatic decision. You cannot say it was "wrong" without knowing all the factors that went into the decision.
This is why I like Linus' stance in this case.
This is the first time that has happened to me in nearly 20 years of using java.
Who care about his attitude? Is he the BFDL of Java or something? :)
On a separate note, good luck moving away from Java to a platform with better backwards compatibility! There's a reason Java is used for enterprise software, it's one of the best platforms for keeping compatibility. It's probably not perfect, but the others are just worse :)
Also I'm not considering alternatives just because Java 9 broke stuff. There are lots of other reasons why Java irritates me but I felt it was still a winner when you balance up all the factors. But if backward compatibility is no longer going to be prioritised, then this shifts the calculation so that it's at least worth it, in my mind, to evaluate alternatives. So we're going to try Kotlin on a fairly small self-contained project.
So we basically just have 3 months to migrate to the next LTS version??
Interested to hear which Java API you use which requires special modification in order to be compilable on Java 8?
Usually most of this breakage is caused by the com.sun stuff which isnt public API.
But then you are using a 1 year old framework (if you're lucky) that depends on a version of library X that is 2 years old that depends on a 3 years old library etc.
At the end of the chain you have a library that does low level stuff (bytecode instrumentation for example) and is a few years old. That is what may give you problems, and often the only practical solution is to update to a newer version of the framework, which can be quite expensive.
Because I worked at a fairly large tech company and every one of our applications required some amount of manual intervention beyond figuratively switching all the "7"s to "8"s. That's despite the fact that hardly any of them were doing anything particularly complicated, and absolutely none of them were doing anything involving hidden com.sun APIs. I think it's just a consequence of such a large build system.
From my experience it wasn't generally code written in-house that'd cause problems (but sometimes it was), it was dependencies and transitive deps that required the older JDK (sometimes they relied on old bugs or old tooling, sometimes they just couldn't be recompiled on the new JDK for whatever reason).
Build tools that relied heavily on JVM internals often couldn't upgrade for some time. Third parties integrating with your software and the new JDK brings a slight change in it's SOAP/XML/ser-deser stuff etc.
That said, Java has been the best at backwards compatibility that I've tried, given it's popularity, and most of the pain was in the early days (like anything I suppose, see the Javascript world atm). Microsoft's offerings probably do backwards compatibility well, but then you get all the rest of the technical- and wallet-pain that that environment brings with it.
They broke compatibility with v57 exactly for that: to make continuous small changes. The previous situation was untenable since there was no API for extensions, the extensions could just go through Firefox internals and change at-will whatever they wanted.
The whole point of WebExtensions is that they won't need to break compatibility after this huge leap.
Teams in charge of software release whenever they want or can, clients are free to use whatever version whenever they want.
The problems only happen with breaking changes - and I haven’t seen a single case of Java breaking backwards compatibility (not counting cases where users intentionally used or relied on private implementation details).
If your company is only discussing moving to JDK9 now, what difference does it make that JDK10 is out? If you are using the free version, there is no real support. If you are a paying customer, Oracle will support you to the end of time while wringing every last cent out of your company.
What difference does it make if the language keeps evolving? Do you expect the entire world to revolve around you and your company?
See http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.ht... for more insight.
All good Java developers I know make all local variables final to force better code.
Person p = ....
p = doSomething(p)
...
p = doSomethingElse(p)
Person p = ....
... lots of code
Person updated = doSomething(p)
... lots of code
doSomethingElse(updated)
You shouldn't be able to doSomethingElse(p) when you actually mean to doSomethingElse(updated).
What would help is splitting the function up so that you don't have multiple named variables representing multiple versions of the same thing in the same scope:
Person doSomethingAndDots() {
Person p = doSomething(...)
...
return p
}
main() {
doSomethingElse(doSomethingAndDots())
}That is to ease the pain of unwrapping nested types and error-checking intermediate steps so you don't have to come up with new names for each intermediate.
In the codebase I work on most, all variables that can be marked final are marked final. That means that whenever I see a non-final variable, I know that something tricky is happening and I need to be extra careful in reading the code.
The Optional class is typical of the halfassery that has accompanied many improvements to Java over the years. From java.util.logging to generics to streams, I'm invariably irritated by compromises particularly as they've decided that maintaining backward compatibility is now a secondary concern.
I've run out of patience in the direction Java has taken and I've been a user since 1.0.4 - I'm going to try Kotlin for my next project.
It also works in the opposite direction: a Java parameter or return value annotated as @Nullable (doesn't have to be intellij's, the Kotlin compiler understands several annotation libraries) will appear as a nullable reference to Kotlin code, and a @NotNull or @Nonnull annotation makes it appear as a non-nullable reference.
return Optional.ofNullable(applications).orElseThrow(NullPointerException::new);
return Optional.ofNullable(applications).orElse(new Application());
var i = 0;
final var i = 0;
int i = 0;
final int i = 0;
val i = 0;
In Scala, where var/val both exist, each time you declare a variable you are forced to think about its mutability. But if you only have "var", with the _option_ of tacking "final" to it, then a programmer can simply forget to make that decision, because the language allowed them to.
`Simple<List<Map<String, Demo>, OtherList<Map<Int, String>>` is a little bit painful.
I use scala and basically most often at least public Methods should (in scala you can omit even that, however some functional libraries need a return type) have a explicit type, which most often is enough.
So instead of typing:
AbstractConcreteFactoryFactory factory = new AbstractConcreteFactoryFactory();
var factory = new AbstractConcreteFactoryFactory(); var p = new Person();
p = 1234; // This will trigger a compile time errorC# is a huge breath of fresh air compared to java largely because of useful type inference. It's easy to make compilers do more work now.
Rust is doing type inference with drastically stronger types, for example.
Does Java fill any kind of niche aside from maintaining those gargantuan projects that are typical of governments and large corporations?
When I learned Java in the 90s, it was hyped up with the promise of microwaves and refrigerators and televisions and every little thing running Java software.
Instead, the only time I've found myself turning to Java was when I built an IDE on top of eclipse for a custom programming language, a few android apps, a few swing projects for school, and a few socket based projects. When dealing with IOT and smaller hardware, I've found myself using node(js) instead.
I've rarely ever found it enjoyable. The IDEs have been sluggish, the GUI libraries have felt cheap and unpolished, with those clunky diamond shaped radio buttons, and I always found myself writing too much code to do very simple stuff, because every library was wordy and verbose. When I looked at my work, it felt inelegant and cumbersome.
What is Java like in 2018? Are there any good, polished open source projects that work well ? What would make you look at a project and say "I think Java is the most suitable choice for that" today?
*Still hoping Oracle will be so good to allow TruffleRuby download without all the signing up and agreement.
This is definitely coming very soon.
When Oracle will remove it in Java11, it would be even worse
So if you care about long term support, you should stay on JDK8
If it’s one thing we’ve learned in software it’s embrace the change. Little and often is the way to stop technical debt accruing