GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-06) - page 2 of 10
 
___________________________________________________________________
Moving Java Forward Faster
89 points by pron
https://mreinhold.org/blog/forward-faster
___________________________________________________________________
 
filereaper - 4 hours ago
>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.
 
EddieRingle - 4 hours ago
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. :)
 
  virtualwhys - 3 hours ago
  > Faster Java & JVM updatesMore 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.
 
    mreinhold - 2 hours ago
    No, JVM enhancements will not be limited to LTS. If anything
    it's best to merge them long before an LTS, so that they're
    well-baked in the LTS itself.
 
      virtualwhys - 1 hours ago
      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.
 
        aardvark179 - 1 hours ago
        Minimal value types will arrive as an experimental feature
        at the VM level real soon now, language and library support
        will take a lot more work.
 
tetha - 2 hours ago
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.
 
newforice - 3 hours ago
As long as they stay away from the lambdas and FP trainwrecks that
was 8.
 
  callinyouin - 3 hours ago
  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.
 
    newforice - 2 hours ago
    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.
 
      jswizzy - 38 minutes ago
      FP and OOP are compatible styles. In fact, I would argue that
      FP is more object orientated than procedural code such as
      loops.
 
      shock - 2 hours ago
      Since lambdas and streams are optional, what is your critique
      of them?
 
sscarduzio - 3 hours ago
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.
 
exabrial - 1 hours ago
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.
 
doodpants - 4 hours ago
> 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?
 
  organsnyder - 2 hours ago
  Only if the first number is constrained to two digits. The
  release from March of 2100 would be 100.3, which would work just
  fine.
 
  swsieber - 3 hours ago
  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.
 
  fauigerzigerk - 2 hours ago
  Imagine the shock when our descendents wake up on Jan 1 2118 and
  all their systems are accidentially running on a 100 year old JVM
  :)
 
pron - 7 hours ago
See also:* 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.