> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9.
Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?
I don't really think that applies? If anything, you know that you can add 2000 to the version version number to get the year.month... if we're to the point where that rolls over, I think we have much bigger problems.
They'll be running the JVM in a Docker container in Linux written in JS in the browser compiled to web assembly running on a Rust WebOS. But it will be okay, because it the hardware will be a 1024 core quantum processor.
>So, let’s ship a feature release every six months.
I agree with the proposed plan, when I worked on the JVM, there was a mad dash to get features in by a certain date, otherwise you'd have to wait till the next release of Java to ship your changes.
From interacting with the service teams (L3 and above) customers prefer new features in a new version of Java, with the long release cycles, you have to ship new features in a service packs which made the service team queasy.
It also removes the stigma that Java and its ecosystem is slow compared to V8, .NET and the other platforms.
I'm fully in support of defined, rolling release trains. 6 months is a good start considering where they're coming from. I feel like that's still slightly too long though, and is one of the things I wish the Go team would change. The Go team's argument is that it takes time to fully test features before being able to release them, which I understand, but that's the whole point behind a multiple release train model.
But I digress. Faster Java & JVM updates will help Kotlin out as well moving forward. :)
My point is that "smaller" features like pattern matching and data classes will land in Java well before big ticket items like value types; not that JVM enhancements will be strictly limited to LTS.
Of course, you have the inside word: when are value types coming to the JVM? Hopefully by Java 10.
I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying some of these features because they really are quite nice once you get the hang of them.
You seem to have jumped to the conclusion that I haven't tried the FP features. If I hadn't tried them, I wouldn't be criticizing them. If I wanted to work in FP style, I would choose an FP language; not encourage a traditional, solid language to be perverted to do something that is completely against the nature and design of that language.
Not really; FP and OOP are dissimilar in their approach to mutable state and it's management, for instance. You can come up with a synthesis (or probably many different syntheses) of ideas from the two styles to make a style blending inspiration from each, but they aren't directly compatible, and most direct combinations mhave tension between the two styles, or directly subordinate one to the other, for that reason.
The venerable master Qc Na was walking with his student, Anton.
Hoping to prompt the master into a discussion, Anton said
"Master, I have heard that objects are a very good thing - is this true?"
Qc Na looked pityingly at his student and replied, "Foolish pupil -
objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his
cell, intent on studying closures. He carefully read the entire
"Lambda: The Ultimate..." series of papers and its cousins, and
implemented a small Scheme interpreter with a closure-based object
system. He learned much, and looked forward to informing his master of
his progress.
On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures." Qc Na responded by
hitting Anton with his stick, saying "When will you learn? Closures are a
poor man's object." At that moment, Anton became enlightened.
It's only very special circumstances where my POD types do not consist entirely of `final` fields. Though I usually skip defensive copying within PODs... One should know better than to trust values from random places. So I defensively copy at use time instead if I want to modify it.
Kotlin, Java's superior offspring, is even better, as the use of data classes provides an automatic implementation of a `copy` command. (Scala does too, but Scala also explodes when I look at it, so, enh.)
To be fair, the implementation of Streams within Java is certainly filled with ugly boilerplate compared to LINQ in C#. But that's no reason to criticize their mere existence.
Slow releases weren't the only problem. Sometimes they even promised things that one year into development would be candidly postponed of other two years. I can't recall of any project being managed as poorly.
As I keep saying, more and smaller releases cause a constant, low amount of pain. That's good, because you avoid the teeth-yanking bullshit of deploying 6 month of care-free development to prod. And even though I hope the OpenJDK community develops more responsibly than my devs, but the point still stands given scaled time frames.
If you've never had a chance to meet Mark in person, he is an incredible guy and a really nice person. Totally on-board with this idea. The execution is going to be the tricky part.
As of Android 7 they do use the OpenJDK. If you're implying that they should replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The OpenJDK and JVM were never designed to work within the constraints of embedded mobile devices.
Why can't Google submit patches to make it work for embedded devices? I don't see the point of a separate version of Java. Imagine if you could develop Android apps against the latest version of Java.
Yes. I don't care about their petty squabble. As an Android dev, I'm sick and tired of not being able to use things because Google thinks they're special.
I think it's more of a legal/licensing move than a technical challenge. You write and compile Java but then it's translated to bytecode for a different VM (Dalvik, I presume this is still the case though I hear there's additional native compilation that occurs now). Net result, developers get to write Java but Google doesn't have to pay royalties for a proper VM on every device.
What would you use to build the UI for your app? AWT? Swing? JavaFX? There is also the issue of all of the Android specific SDK code that would probably never be applicable for cross platform reuse. And then there's the JVM which would also probably require massive changes to adhere to Android's VM requirements (as it stands right now, ART and the JVM aren't even in the same architectural ballpark as one is register based and the other is stack based). The level of resistance to these changes would introduce would also be a major issue and more so than the friction Google faces when trying to upstream Android related changes to the Linux kernel.
Incidentally, there's a project called OpenJDK Mobile[1] on the OpenJDK project site that aims to port the OpenJDK to popular mobile platforms. Not sure where they're at with it, but it seems to be a WIP.
Then there are quite a few embedded device OEMs that don't have the same problems than Google has supporting standard Java, some of them targeting real time embedded devices.
Maybe Google should ask them how they manage to do it.
No Sun did not have it figured out and history has proven this. Sun just couldn't compete from a technology perspective because no OEM was going to choose a vastly inferior OS.
BTW, here's a picture of your SavaJe phone. No wonder OEM's fled in horror.
Stolen OS LOL. Just when you think the BS couldn't be piled any higher you take it to another level. Why would you say something as embarrassing as this?
If you think using 38 open source Java API declaration packages constitutes an OS then you clearly have no idea as to what an OS is.
Well if Java on phone is really fine then Google's pathetic attempts at Android should not matter as billions will keep buying those great Oracle certified Java phones.
And in any case, market failure is not an excuse to steal someone's else work, by not licensing it like every other company was doing at the time, and still are.
Since when is using 38 Java API open source declaration packages considered stealing? It's not except to the people that are upset that Oracle lost repeatedly in court. The courts have spoken. It's time to move on so perhaps you should too.
Thanks Oracle support team lead and Oracle legal fund contributor, but I have to wonder if you even know what the actual definition of a fork is because there was no fork. So you're either being disingenuous or deliberately trying to construct a false narrative.
>I just got bored to post links, there are many more I can keep on posting.
If you feel I bother with your ad hominem attacks being called Oracle support team lead and Oracle legal fund contributor, you are wasting your time.
Actually now that you mention it, maybe I should add "Sun support team lead and Sun legal fund contributor" to my profile.
Google should be penalized just like Microsoft was, but sadly it is the love child of Silicon Valley wannabe Google employees, so they get a free pass while Microsoft was bashed to death.
Ever hear the one about the pot calling the kettle black?
Google did nothing wrong with its use of 38 open source Java API header files. Neither did the juries that presided over the trials. What I do find troubling, however, is your improper use of the word "Fork", to describe what happened.
To be honest I didn't even know what Java Flight Recorder was - and I've been doing Java, Clojure and Kotlin for a number of years. I don't see this being a major change for those that have always been on OpenJDK
This is actually a huge change for operations / devops. JFR is the only tooling out there today that can accurately and safely gather important performance metrics from the JVM in a low impact manner. All other APM vendors like ourselves (jClarity) have to perform hacks of some sort to try and emulate JFR's capabilities. This high quality data source is something that our engineering team is very excited to have opened up!
This may be an unpopular opinion, but I don't want Java to move forward faster. I don't really want it to move forward much at all unless there is a huge, tangible benefit from the new feature(s). I am of the belief that programming languages should be a solid, fixed foundation on which lasting software can be reliably built. Every time a feature is added to a programming language, it becomes larger, more complex and harder to learn. Rapid changes to languages can also result in regrets, and it is essentially impossible to take something back in language development.
In general, I think too much stock is put into language features, perhaps because many developers are bored with the actual software they are writing/maintaining, and so new language features are relatively fun. As a mental experiment for those who know both Java and Kotlin, or both Java and Scala: Suppose you were asked to estimate the time required to implement a system in Java, and you arrived at an answer of 2 months. Now what would be your estimate for the same system, but written in Kotlin? How about Scala? Admit that it would be the same. (Well, probably a little longer for Scala, but just because it takes forever to compile, ha.)
I think that good languages offer features that make your code better, not let you write it faster.
Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward.
Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don't know better, it's definitely easy to write worse code in it.
The reality is there is an easy blueprint for Java, because C# is Java, but done better. It's moving at a good clip, but the features coming in are very useful and well thought out.
Language greatness is pretty subjective and task specific. There are some languages I will never declare great (i.e. PHP, JavaScript, Ruby), but others could be great for different tasks..
> Language greatness is pretty subjective and task specific. There are some languages I will never declare great
If greatness is subjective AND task specific, then the languages you will never declare great could be considered great by others for the tasks they perform. And by your own admission if they were great subjectively AND for a particular task, that would make those languages great. But, you still claim that you would never declare them great?
Not to mention the implicit dismissal of developer happiness. That's one of the best things about the ruby and rails communities: why shouldn't our tools be nice to use? Kotlin has (imo) that same attitude as compared to java.
Sorry, can't do that. If my estimate was 2 months in Scala, it would be 6 months in Java: 2 to write the software, and 4 to find and chase down all the NPEs, casting exceptions, and concurrency bugs, while building a test kit for things the scala compiler already verified the moment my scala code compiled.
Last time I've had casting problem was when someone passed Scala Map to Freemarker.
If it takes 4 extra months to debug NPEs, then someone still needs to learn how to code, because things that compiler can fix, experienced programmer should be able to do avoid at first place.
That's what I hear. I personally think it's a shame that we have to live through years of terrible bugs in terrible languages just to become an experienced programmer that can finally know how to always avoid those mistakes in the first place.
If you're already there, great. I applaud your superior experience, and hope you really enjoy your C++ footguns. But don't tell me that the scala compiler doesn't have value to me just because you're a code god and don't need it. I actually benefit from languages that help me avoid stupid mistakes.
I agree with what you say about language evolution, but this proposal isn't just about the language—it’s also about APIs, tools, and implementation-specific features (e.g., JITs and GCs), which can evolve more flexibly than the language itself.
Common Lisp has moved forward exactly zero "officially" for decades. Yet, modern CL implementations are largely compatible with one another, largely interoperable with modern multicore hardware and multithreaded operating systems, largely capable of using Unicode and other representation formats, etc.
Of course, CL was designed with "extending CL" as a feature, and not locking the CL user into CL as it is "today." Shame so few other languages bother with this (Java and Clojure on the JVM come to mind immediately as hard to extend). Other languages have very active language evolution (Haskell/GHC comes to mind).
I like my languages to evolve. Preferably not the way Java did (I still hate the 1.5 type erasure hack).
We did this (at a much smaller scale) with Apache HBase (starting at 0.94, which I release-managed). We went to a monthly release cadence.
We saw the frantic last minute commits just before a release (and followed by multiple smaller releases just after the big release to stabilize the code base) essentially vanish. If the feature wasn't done, it simply got in a month later.
For us it required an "transitive compatibility" (i.e. one can go from version X to version X+3 without upgrading to X+1 and X+2 first), and stable functional tests, so that confidence in a release is automatic and does not need to be established manually.
I represent the London Java Community (LJC) on the Java Community Process (JCP) Executive Committee (EC), aka the Java standards body. I also help run the Adopt OpenJDK programme for OpenJDK outreach and onboarding new developers to work on Java itself.
Now that the acronyms are out of the way :-). We're working at the JCP with Oracle to streamline the standardisation process in order to facilitate these faster releases and provide other Java vendors the ability to run their reference implementations against an in flight Technical Compatibility Kit (TCK), which is what you need to pass in order to call yourself Java.
I'm really, really pleased that Oracle is increasing the cadence. Java 9 allows for incubation modules and so if something isn't ready, it can simply be put in there for early testing without it impacting the main release.
Some folks asked about alternative platforms. In terms of providing high quality releases of OpenJDK for alternative platforms we've created a portal at https://www.adoptopenjdk.net with the build farm run via https://ci.adoptopenjdk.net (code in various repos at https://www.github.com/AdoptOpenJDK). We've only just received the Java Test Compatibility Kit J(TCK) from Oracle and once we have the binaries tested against that then folks will be able to get the latest OpenJDK binaries for all of the esoteric platforms (ARM, z360, AMD variants, AIX, Solaris and so forth).
We'd love for folks with devops skills to come and join us (Docker, IaaS, Jenkins, make skills welcome).
If you have any specific questions please throw them my way!
83 comments
[ 3.3 ms ] story [ 47.5 ms ] thread* Accelerating the JDK release cadence http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...
* Faster and Easier Use and Redistribution of Java SE https://blogs.oracle.com/java-platform-group/faster-and-easi...
Oracle will also ship binary distributions of OpenJDK, and OpenJDK will become the canonical JDK distribution.
Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?
https://blog.codinghorror.com/sorting-for-humans-natural-sor...
I agree with the proposed plan, when I worked on the JVM, there was a mad dash to get features in by a certain date, otherwise you'd have to wait till the next release of Java to ship your changes.
From interacting with the service teams (L3 and above) customers prefer new features in a new version of Java, with the long release cycles, you have to ship new features in a service packs which made the service team queasy.
It also removes the stigma that Java and its ecosystem is slow compared to V8, .NET and the other platforms.
But I digress. Faster Java & JVM updates will help Kotlin out as well moving forward. :)
More likely faster updates will be to Java itself, while JVM enhancements will be limited to LTS.
Pattern matching and data classes, for example, will arrive far sooner in Java than value types in the JVM.
Of course, you have the inside word: when are value types coming to the JVM? Hopefully by Java 10.
No one benefits of fragmentation.
Search for Google.
http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.h...
http://openjdk.java.net/projects/mlvm/summit2014/agenda.html
Incidentally, there's a project called OpenJDK Mobile[1] on the OpenJDK project site that aims to port the OpenJDK to popular mobile platforms. Not sure where they're at with it, but it seems to be a WIP.
[1]http://openjdk.java.net/projects/mobile/
Then there are quite a few embedded device OEMs that don't have the same problems than Google has supporting standard Java, some of them targeting real time embedded devices.
Maybe Google should ask them how they manage to do it.
BTW, here's a picture of your SavaJe phone. No wonder OEM's fled in horror.
https://www.engadget.com/2006/05/13/savaje-releases-jasper-s...
It is easy to fail when a competitor is giving away for free a stolen OS.
Of course OEMs will choose free.
If you think using 38 open source Java API declaration packages constitutes an OS then you clearly have no idea as to what an OS is.
>Of course OEMs will choose free.
Is that why they also chose Windows Phone?
The JVM is doing just fine controlling embedded devices in factories, printers and phones.
http://www.ricoh-developer.com/content/device-sdk-type-j-sdk...
https://www.aicas.com/cms/
https://developer.cisco.com/media/onePKGettingStarted-v1-1-0...
https://developer.gemalto.com/taxonomy/term/39/group/80?view...
http://www.gemalto.com/m2m
https://www.ptc.com/en/developer-tools/perc
http://www-03.ibm.com/software/products/bg/real-time
I just got bored to post links, there are many more I can keep on posting.
All from companies that used to work with Sun, nowadays with Oracle, without doing the forking game Google has done.
Nothing to do with technical capabilities, rather money.
And lets not forget that also helped Oracle getting Sun.
If it was Microsoft, Apple, <whatever corp> everyone would have bashed them, but it is Google, so it is fine.
And in any case, market failure is not an excuse to steal someone's else work, by not licensing it like every other company was doing at the time, and still are.
Google is the only notable exception.
>I just got bored to post links, there are many more I can keep on posting.
Here's a link on what forking is.
https://en.wikipedia.org/wiki/Fork_(software_development)
Actually now that you mention it, maybe I should add "Sun support team lead and Sun legal fund contributor" to my profile.
Google should be penalized just like Microsoft was, but sadly it is the love child of Silicon Valley wannabe Google employees, so they get a free pass while Microsoft was bashed to death.
Google did nothing wrong with its use of 38 open source Java API header files. Neither did the juries that presided over the trials. What I do find troubling, however, is your improper use of the word "Fork", to describe what happened.
"After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds " http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...
Java Flight Recorder will be open source.
Java Flight Recorder and Visual VM are great tools, only matched by .NET ones to monitor application performance.
In general, I think too much stock is put into language features, perhaps because many developers are bored with the actual software they are writing/maintaining, and so new language features are relatively fun. As a mental experiment for those who know both Java and Kotlin, or both Java and Scala: Suppose you were asked to estimate the time required to implement a system in Java, and you arrived at an answer of 2 months. Now what would be your estimate for the same system, but written in Kotlin? How about Scala? Admit that it would be the same. (Well, probably a little longer for Scala, but just because it takes forever to compile, ha.)
Sure, it may take me two months to write that thing in Scala still, but I'll have more confidence it will work well, and it'll be nicer to read, maintain and work with moving forward.
Scala is an interesting example for this, because the language is a grab-bag of features that definitely can be abused by people who don't know better, it's definitely easy to write worse code in it.
The reality is there is an easy blueprint for Java, because C# is Java, but done better. It's moving at a good clip, but the features coming in are very useful and well thought out.
And great languages let you do both.
Language greatness is pretty subjective and task specific. There are some languages I will never declare great (i.e. PHP, JavaScript, Ruby), but others could be great for different tasks..
If greatness is subjective AND task specific, then the languages you will never declare great could be considered great by others for the tasks they perform. And by your own admission if they were great subjectively AND for a particular task, that would make those languages great. But, you still claim that you would never declare them great?
I highly recommend anyone with these very valid concerns to view it once.
[1] https://www.youtube.com/watch?v=2y5Pv4yN0b0
Sorry, can't do that. If my estimate was 2 months in Scala, it would be 6 months in Java: 2 to write the software, and 4 to find and chase down all the NPEs, casting exceptions, and concurrency bugs, while building a test kit for things the scala compiler already verified the moment my scala code compiled.
If you're already there, great. I applaud your superior experience, and hope you really enjoy your C++ footguns. But don't tell me that the scala compiler doesn't have value to me just because you're a code god and don't need it. I actually benefit from languages that help me avoid stupid mistakes.
Perhaps the same, but the code is going to be much safer.
I think that is something you've missed we want features in Java that let us write more reliable code. Otherwise we will migrate.
I'm already starting the process of migrating to Kotlin for any Java work and I'm learning Haskell for side projects.
Of course, CL was designed with "extending CL" as a feature, and not locking the CL user into CL as it is "today." Shame so few other languages bother with this (Java and Clojure on the JVM come to mind immediately as hard to extend). Other languages have very active language evolution (Haskell/GHC comes to mind).
I like my languages to evolve. Preferably not the way Java did (I still hate the 1.5 type erasure hack).
We did this (at a much smaller scale) with Apache HBase (starting at 0.94, which I release-managed). We went to a monthly release cadence.
We saw the frantic last minute commits just before a release (and followed by multiple smaller releases just after the big release to stabilize the code base) essentially vanish. If the feature wasn't done, it simply got in a month later.
For us it required an "transitive compatibility" (i.e. one can go from version X to version X+3 without upgrading to X+1 and X+2 first), and stable functional tests, so that confidence in a release is automatic and does not need to be established manually.
I represent the London Java Community (LJC) on the Java Community Process (JCP) Executive Committee (EC), aka the Java standards body. I also help run the Adopt OpenJDK programme for OpenJDK outreach and onboarding new developers to work on Java itself.
Now that the acronyms are out of the way :-). We're working at the JCP with Oracle to streamline the standardisation process in order to facilitate these faster releases and provide other Java vendors the ability to run their reference implementations against an in flight Technical Compatibility Kit (TCK), which is what you need to pass in order to call yourself Java.
I'm really, really pleased that Oracle is increasing the cadence. Java 9 allows for incubation modules and so if something isn't ready, it can simply be put in there for early testing without it impacting the main release.
Some folks asked about alternative platforms. In terms of providing high quality releases of OpenJDK for alternative platforms we've created a portal at https://www.adoptopenjdk.net with the build farm run via https://ci.adoptopenjdk.net (code in various repos at https://www.github.com/AdoptOpenJDK). We've only just received the Java Test Compatibility Kit J(TCK) from Oracle and once we have the binaries tested against that then folks will be able to get the latest OpenJDK binaries for all of the esoteric platforms (ARM, z360, AMD variants, AIX, Solaris and so forth).
We'd love for folks with devops skills to come and join us (Docker, IaaS, Jenkins, make skills welcome).
If you have any specific questions please throw them my way!