[HN Gopher] Java 17 / JDK 17: General Availability
___________________________________________________________________
Java 17 / JDK 17: General Availability
Author : 0xedb
Score : 310 points
Date : 2021-09-14 14:29 UTC (8 hours ago)
(HTM) web link (mail.openjdk.java.net)
(TXT) w3m dump (mail.openjdk.java.net)
| deepsun wrote:
| Are they going to introduce zero-cost structs?
|
| Kinda like Rust guarantees that Option<T> has the same size as T
| (aka free like in free beer).
| CodeIsTheEnd wrote:
| A clarification: Rust only makes this guarantee for certain
| types[1] which you would expect to be represented by a simple
| pointer under the hood (e.g., Box<U>, &T, function pointers)
| and for other types which can never be all 0.
|
| Making this optimization for something like Option<u8> is,
| naturally, impossible.
|
| (I assume you are aware of this and were implicitly referring
| to this optimization.)
|
| [1]: https://doc.rust-lang.org/std/option/#representation
| vips7L wrote:
| Primitive classes are being worked on in Project Valhalla.
| geophile wrote:
| I think this statement has been true since about 2014.
|
| Structs are nice, as they allow for control over locality, to
| a degree that is simply not possible in Java currently. But
| there is a second effect, which is possibly more important:
| If I can move gigabytes of my data into arrays of structs,
| then 1) I greatly reduce memory requirements (far fewer
| pointers), and 2) I greatly reduce the amount of work that GC
| has to do.
|
| This is such an important thing to add to Java, and it seems
| to be perpetually off the stove, not even on the back burner.
| pjmlp wrote:
| Because they don't want to do a Python move, and those
| compiled JARs from 2000 should keep working as much as
| possible on a Valhala aware JVM.
| vips7L wrote:
| Some features take a long time when you have millions of
| users and billions of loc. Goetz recently did a State of
| Valhalla interview here:
| https://www.youtube.com/watch?v=x1_DBqJrykM
| stickfigure wrote:
| Alternatively: This is such a (potentially) big change,
| it's important to get right. I'd be disappointed if an
| inadequately-baked solution gets rushed in.
|
| Another way of looking at it: This is fundamentally just a
| performance optimization. Java performance is already
| exceptional for most of Java's popular use cases (business
| processing). While valuable, I don't think this one feature
| is quite as important as you consider it.
| deepsun wrote:
| That makes sense, given the fact that they made "new
| Foo()" pretty lightweight anyway (for CPU, not for RAM).
| nlitened wrote:
| > If I can move gigabytes of my data into arrays of
| structs, then 1) I greatly reduce memory requirements (far
| fewer pointers), and 2) I greatly reduce the amount of work
| that GC has to do.
|
| As an aside, and not to say that Valhalla is not needed (I
| am looking forward to it very much, along with Loom), I've
| recently learned that for many use cases (not all) when you
| want gigabytes of struct arrays, a bunch of equal-sized
| primitive arrays, one per struct field, might work even
| better from memory requirement and cache locality
| perspective.
| native_samples wrote:
| It's mostly implemented in a branch. You can download a
| version of Java that can do this today. There's more work
| to do before it can be merged though, and will probably
| ship in incremental pieces.
| hyperpape wrote:
| I haven't been following it incredibly closely, but I have
| checked in from time to time. It's a hard problem, but
| there's a lot of real progress
| (https://github.com/openjdk/valhalla-
| docs/blob/main/site/desi...).
|
| I'd wager that it will ship by the next LTS, in 2024.
| vips7L wrote:
| 2023 (hopefully)! They're proposing moving LTS to 2 years
| instead of 3.
| zokier wrote:
| > This is such an important thing to add to Java, and it
| seems to be perpetually off the stove, not even on the back
| burner.
|
| Valhalla is being actively worked on, I'm not sure what you
| are implying here.
| throwaway4good wrote:
| You get null for free.
| mleo wrote:
| Can't tell if this meant to be a statement of fact, opinion
| or sarcasm. Over the course of 20 years have I have probably
| spent days of time tracking down NPEs in code being developed
| and after the fact in production releases. The amount of
| extra code and time spent to determine if variable is null
| certainly isn't free.
|
| Optional at least states the variable may not be referencing
| anything and provides helpful methods to chain mapping and
| conditionals to more easily deal with null values.
| dtech wrote:
| I really like the Kotlin approach, where they just embraced
| null being a fact of life on the JVM/JS and instead
| integrated nullability into the type-system [1]. C# and
| Typescript do something similar.
|
| So then you get the best of both world, the safety of
| Optional without the boxing overhead.
|
| [1] https://kotlinlang.org/docs/null-safety.html
| bdamm wrote:
| This really sounds like the way to go, although of course
| it is too late for Java. Optional feels awkward, and
| there's no more safety than we already have since the JVM
| null-checks anyway. if( arg.isPresent()
| ) ...
|
| vs if( arg != null ) ...
|
| How is this better?
| rovolo wrote:
| The main advantage is that Optional is inconvenient and
| forces you to consider the null case. It's easy to forget
| that values can be null and assume they're not, e.g.
| auto-unboxing Long getSomeValue();
| int max = Math.max(0, obj.getSomeValue());
|
| The Optional value forces you to type some text basically
| acknowledging that the value can be null.
| Optional<Long> getSomeValue(); ...
| obj.getSomeValue().get());
|
| I'm not saying Optional is a great solution. It's
| essentially a notification that a value is nullable.
| tathisit wrote:
| It's impossible for Option<T> to be the same size as T. Option
| is a tagged enum, where will the tag go?
| agolliver wrote:
| Looks like it's only true for pointer types which cannot be
| null (so they can reuse null as the None tag)
|
| https://doc.rust-lang.org/std/option/
| zokier wrote:
| > Kinda like Rust guarantees that Option<T> has the same size
| as T (aka free like in free beer).
|
| That is not correct. Trivial counterexample:
|
| https://play.rust-lang.org/?version=stable&mode=debug&editio...
|
| prints 4 8
|
| i.e. Option<T> is 4 bytes larger than plain T
| deepsun wrote:
| Sure, I meant:
|
| Rust guarantees to optimize the following types T such that
| Option<T> has the same size as T: Box<U>
| &U &mut U fn, extern "C" fn
| num::NonZero* ptr::NonNull<U>
| #[repr(transparent)] struct around one of the types in this
| list.
|
| UPDATE: Or, better per your example: struct T {i: i32} takes
| the same size as i32: https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
| muhammedbash wrote:
| Something I would like to see in Java is for functions to return
| multiple (named?) values. I think it will reduce boiler plate
| code considerably.
| carimura wrote:
| Part of the vision of pattern matching is aggregation and
| destructuring [1]. This is just exploratory but may be what
| you're thinking about?
|
| [1] https://github.com/openjdk/amber-
| docs/blob/master/site/desig...
| stickfigure wrote:
| Interesting but the "Isn't this just multiple return?"
| section seems to completely miss the point. I don't see any
| examples of what multiple-return would look like. And
| multiple-return is what I want.
|
| At first glance, it looks like this (sure, more powerful)
| pattern matching system is not going to satisfy my desire for
| a compact syntax that lets me do the equivalent of this
| typescript: const [foo, bar] =
| getMeTwoThings();
| titovodka wrote:
| I might not be aware of best practices.
|
| What are the benefits of having a multiple return type
| function?
|
| I just assume that one can use an object if this is needed
| throughout the whole code..
|
| Or maybe create an arraylist if possible and return that?
| sverhagen wrote:
| Using the object(/class) as you say is the probably "the
| Java way" to do this, given their historical "everything
| is an object" stance (which has been eroded a bit,
| though, with some of the functional support). But it sure
| is nice to do a multi-returns, here and there, without
| having to create another class. A class which required
| you to write boilerplate (getters/setters). Maybe records
| are some sort of compromise. Probably a non-compromise
| for people who like the multi-returns.
| BlackFly wrote:
| No, there is no tuple support yet in Java. That would
| require something like variadic generics or a special
| compile time syntax sugar for tuples as the sole use of
| variadic generics.
|
| With the pattern matching the best you are going to get is
| nasty boiler plate like var returnedTuple
| = getMeTwoThings(); if (returnedTuple instanceof
| MyTupleType(Foo foo, Bar bar)) { // Do
| something with foo and bar } else { //
| Not reachable unless refactoring, etc. So panic here.
| }
|
| That else clause is so terrible you'd probably just rather
| use the getters from the type.
| evacchi wrote:
| I think there is ongoing discussion to support
| var MyTupleType(Foo foo, Bar bar) = getMeTwoThings();
|
| which IIRC may be even simplified to
| var MyTupleType(foo, bar) = getMeTwoThings();
|
| EDIT: found it
| https://mail.openjdk.java.net/pipermail/amber-spec-
| experts/2... let Point(var x, var y) =
| aPoint
| muhammedbash wrote:
| I am thinking of something more like go language or python.
|
| In go you can do this:
|
| function (x, y int) (sum, prod int) { return x+y, x*y }
|
| It makes a big difference when one is using the same input to
| generate multiple related outputs.
| Cojen wrote:
| I think the best thing we have is the new `record` feature. You
| can declare a small public record before the method with the
| return type, and by using the `var` keyword, the caller doesn't
| need to repeat the type declaration.
| MichaelMoser123 wrote:
| you can use lombok for generating accessors, helps to reduce a
| lot of boiler plate code. See
| https://javabydeveloper.com/project-lombok-tutorial/
| muhammedbash wrote:
| I use the lombok plugin with IntelliJ, it eliminates tedious
| parts of some code.
|
| Some times one needs to create new objects return multiple
| related items from a function. Or use a collection or array.
| I think it is unnecessary. Other languages (e.g. go or
| python) have had this for a while now. I taking a wild guess
| here LISP probably had it since the 1970s.
| bgruber wrote:
| Slated to be previewed in java 18
| https://openjdk.java.net/jeps/405
| gigatexal wrote:
| The biggest hinderance to me adopting Java for anything
| meaningful was the build system. Too much XML and complexity.
| Maven for packages, ugh. Just give me a modern package manager.
| Does such a thing exist that is idiot proof?
| isbvhodnvemrwvn wrote:
| Maven is the idiot proof one. Gradle doesn't have XML, but it's
| extremely easy to make your build scripts unmaintainable.
| stuff4ben wrote:
| I haven't touched Java since 8 but I'm itching to get back in it.
| Any good overviews of Java since 8 and what was added?
| BoyRobot777 wrote:
| https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
|
| Only missing stuff from 17, but that's a short list.
| dmit wrote:
| In presentation form: https://www.infoq.com/presentations/life-
| after-java-8/
| rickette wrote:
| https://ondro.inginea.eu/index.php/new-features-in-java-vers...
| stevetodd wrote:
| Some highlights since the last LTS (JDK 11):
| Language Features 394: Pattern Matching for instanceof
| 395: Records 306: Restore Always-Strict Floating-Point
| Semantics 409: Sealed Classes 361: Switch Expressions
| 378: Text Blocks Language Features in Preview (behind
| a flag) 406: Pattern Matching for switch 412: Foreign
| Function & Memory API 414: Vector API Tooling
| 392: Packaging Tool (jpackage) JVM 386: Alpine
| Linux Port 391: macOS/AArch64 Port 340: One AArch64
| Port, Not Two 388: Windows/AArch64 Port
|
| (Source: https://openjdk.java.net/projects/jdk/17/jeps-since-
| jdk-11)
| rnikander wrote:
| I'm guessing that Loom (lightweight threads) is not in this yet.
| It looked like a nicer way to handle "async" code, but I wonder
| about the implementation difficulty.
| exabrial wrote:
| Java5 and Java8 were monumental changes to the language... this
| update probably will have the same legacy. Can't wait to see the
| benchmarks out of this bad boy once they get the compilers tuned
| in.
| BitPirate wrote:
| While i agree that Java 8 added a lot of nice things, the big
| disruption happened with Java 9.
| igouy wrote:
| Don't new programs have to be written to use the new features?
| elapsed secs binarytrees,java16,7 2.478
| binarytrees,java17,7 2.475
| binarytrees,java16,3 4.644 binarytrees,java17,3
| 4.574 binarytrees,java16,2 4.765
| binarytrees,java17,2 4.772
| binarytrees,java16,6 4.608 binarytrees,java17,6
| 4.594 binarytrees,java16,4 4.733
| binarytrees,java17,4 4.808
| fannkuchredux,java16,2 45.438
| fannkuchredux,java17,2 43.921
| fannkuchredux,java16,1 10.644
| fannkuchredux,java17,1 10.382
| fannkuchredux,java16,3 41.432
| fannkuchredux,java17,3 41.110 fasta,java16,5
| 1.302 fasta,java17,5 1.255
| fasta,java16,2 4.473 fasta,java17,2 4.325
| fasta,java16,6 1.209 fasta,java17,6 1.191
| fasta,java16,4 3.164 fasta,java17,4 3.202
| knucleotide,java16,5 18.224 knucleotide,java17,5
| 20.063 knucleotide,java16,3 7.383
| knucleotide,java17,3 7.332
| knucleotide,java16,6 7.447 knucleotide,java17,6
| 7.373 knucleotide,java16,4 36.777
| knucleotide,java17,4 36.712
| knucleotide,java16,1 4.979 knucleotide,java17,1
| 4.851 mandelbrot,java16,2 4.148
| mandelbrot,java17,2 4.119
| mandelbrot,java16,3 7.382 mandelbrot,java17,3
| 7.348 mandelbrot,java16,1 27.733
| mandelbrot,java17,1 27.793
| mandelbrot,java16,4 5.221 mandelbrot,java17,4
| 4.415 mandelbrot,java16,6 4.247
| mandelbrot,java17,6 4.300 nbody,java16,3
| 7.410 nbody,java17,3 7.454
| nbody,java16,2 7.459 nbody,java17,2 7.472
| nbody,java16,5 7.006 nbody,java17,5 7.027
| nbody,java16,1 7.823 nbody,java17,1 7.818
| nbody,java16,4 6.739 nbody,java17,4 6.768
| pidigits,java16,1 7.375 pidigits,java17,1 7.891
| pidigits,java16,2 1.336 pidigits,java17,2 1.342
| pidigits,java16,3 0.928 pidigits,java17,3 0.926
| regexredux,java16,6 5.593 regexredux,java17,6
| 5.362 regexredux,java16,3 5.582
| regexredux,java17,3 5.313
| regexredux,java16,1 9.021 regexredux,java17,1
| 8.441 revcomp,java16,5 4.364
| revcomp,java17,5 4.392 revcomp,java16,6
| 3.080 revcomp,java17,6 3.011
| revcomp,java16,3 2.310 revcomp,java17,3 2.369
| revcomp,java16,4 5.005 revcomp,java17,4 5.029
| revcomp,java16,7 21.809 revcomp,java17,7 23.196
| revcomp,java16,8 1.537 revcomp,java17,8 1.527
| spectralnorm,java16,1 6.173 spectralnorm,java17,1
| 8.016 spectralnorm,java16,3 1.631
| spectralnorm,java17,3 1.577
| spectralnorm,java16,2 1.655 spectralnorm,java17,2
| 2.334
| sideeffffect wrote:
| Can you please compare to 11 or even 8?
| dijit wrote:
| This is pretty big for me regarding IntelliJ.
|
| This is the JDK version that ships with the wayland gui toolkits.
|
| I'm psyched!
| popotamonga wrote:
| Still no property literals :( Huge pain, C# has it so much
| better.
| ducktective wrote:
| Any news on JavaFX? I know it's developed independently but is it
| an even option beside Qt, Electron, etc..?
| suyash wrote:
| Would be nice if Oracle folded it into JDK again so it will get
| more love from developers.
| pulse7 wrote:
| JavaFX was... too little, too late...
| pjmlp wrote:
| Yes, now Gluon is driving it.
|
| https://openjfx.io/
| jgneff wrote:
| I think it's a great option, mostly because it can run anywhere
| the JDK runs. I'm building and testing the JavaFX 18 early-
| access builds for Linux on six Debian architectures (amd64,
| arm64, armhf, i386, ppc64el, s390x). I should have the JavaFX
| 17 general-availability release built this week on all six,
| too. See:
|
| https://snapcraft.io/openjfx
| [deleted]
| vitro wrote:
| Give me variable interpolation in strings and I'll be happy.
| suyash wrote:
| anyone able to run Java 17 on a Pi ? wonder if there is an ARM
| release for Pi yet.
| jgneff wrote:
| I built a Snap package of OpenJDK 17 and 18 for armhf (armv7l)
| and arm64 (aarch64), along with four other Linux architectures.
| See:
|
| https://snapcraft.io/openjdk
| suyash wrote:
| super!
| cbm-vic-20 wrote:
| The download page has a aarch64 Linux archive.
| suyash wrote:
| thanks
| dzonga wrote:
| as a node dev, I see people using typescript with node. I wonder
| why don't those people just use java ? and let us clay potters
| shape plain js to our will. rather than pollute the node
| ecosystem with typescript
| isbvhodnvemrwvn wrote:
| Typescript has about as much to do with java as javascript. The
| similarities are at best superficial.
| txdv wrote:
| When you drop the pot, get a job and work with an entire team
| on a single project - you learn to appreciate the safety of
| types
| dzonga wrote:
| yeah, types in js e.g flow are useful in quickly learning the
| codebase but end of day you end up fighting the tooling.
| instead of the tooling to help you. I prefer inferred types
| such as what F# or Elm have.
| kasperni wrote:
| Some other news in relation to the release:
|
| - (Proposal) Moving JDK LTS versions to a two year cadence [1].
| Java 21 will be next LTS instead of Java 23.
|
| - Oracle JDK is now free for commercial and production use [2].
|
| - A new Java developer site [3].
|
| [1] https://mreinhold.org/blog/forward-even-faster
|
| [2] https://blogs.oracle.com/java/post/free-java-license
|
| [3] https://dev.java/
| vips7L wrote:
| 2 year LTS is exciting! Hopefully the other vendors follow
| suit.
| suyash wrote:
| JDK being free for commercial use is fantastic news, no more
| juggling open JDK repos now
| krzyk wrote:
| Why? I always downloaded openjdk which was free for few
| years.
| 0x0 wrote:
| Another license change for the official oracle jdk? What's the
| trap this time? :-O
| mschuster91 wrote:
| Probably they got too much flak and a drop in market share
| (aka companies uninstalling Java, which they probably track
| in the uninstaller)...
| orthoxerox wrote:
| Only JDK 17 is free. Earlier versions are not.
| Sindisil wrote:
| Of the Oracle branded JDK releases, only version 17 (so
| far) is free.
|
| OpenJDK (which is built from functionally the same source
| code) has been free under GPL v2.1 + Classpath Exception
| for a while now.
| gmueckl wrote:
| I am confused by the license. The way I read it, a "bundling"
| with commercially licensed Software is forbidden, that is,
| you can't ship the JRE along with a product that you are
| selling. So your users will face rxtra installation steps
| bondolo wrote:
| Or you can pay to license the JRE and include it.
| Sindisil wrote:
| They are, however, making a commitment to scripting
| friendly URLs for the JDK downloads, making it feasible to
| automate the install.
|
| Still, it is pretty lame, since they've been advocating
| bundling of the JDK since they deprecated the WebStart.
|
| OTOH, since Oracle JDK and OpenJDK are identical save for
| branding and licensing, not sure why you wouldn't just
| bundle an OpenJDK build in that case.
|
| This new license seems to be targeted to two main groups:
| those who depend upon a "system" install of Oracle Java for
| running third party apps, and those who are for some reason
| unwilling to use OpenJDK.
| native_samples wrote:
| JRE stopped existing in Java 8. The idea now is you "link"
| a JVM for your app, which customizes and optimizes it. Then
| you ship both together. It's the fully supported way and
| has no license implications.
|
| Seems like the new Oracle JDK license is a lot more
| flexible than before. In reality it's kind of cosmetic
| because lots of people were using the (100% compatible)
| Amazon or Azul spins, or just regular OpenJDKs.
| jollybean wrote:
| So the comments above seem to indicate that bundling
| 'JRE' with an app requires a license. Are you indicating
| that post-java8 model which builds a 'Custom JRE', and
| distributing that with your app does not require a
| license?
| BossingAround wrote:
| > Oracle JDK is now free for commercial and production use.
|
| Hopefully, developers have learned to avoid Oracle like a
| plague after the last absolute licensing failure with JDK that
| caused all the FUD.
| pgwhalen wrote:
| There are plenty of reasons to avoid Oracle, but I'm not sure
| what about the previous licensing change was a failure.
| OpenJDK builds have always been free (and provided by
| Oracle).
|
| The community terribly overreacted and misunderstood the
| nature of that change, and indeed caused a lot of FUD.
| carimura wrote:
| Thanks for the Dev.java mention. Our team is excited to launch
| the site. We focused on minimal design (similar to Inside.java)
| and heavy on content, mostly learning material to start. More
| to come soon. Feedback here is welcome!
| cstuder wrote:
| The RSS-feed seems to be missing: https://dev.java/feed.xml
| (Linked in the footer.)
| suyash wrote:
| Great new site Chad! more blogs, tutorials, articles and
| possibly community contibutons around the same would be
| awesome to see :)
| carimura wrote:
| Thanks Suyash! External contributions, or at least a more
| formalized system for feedback, is in the planning stages
| already.
| Zababa wrote:
| It looks nice, it's very readable and reacts well to
| zoom/unzoom. That's a great website, congrats!
| Welteam wrote:
| The responsiveness seems broken because of the "try java"
| editor. Try it on your phone and you'll see you can move the
| page horizontally and most of it is blank.
| carimura wrote:
| Thanks ya, fixing that up now.
|
| edit: fixed
| cesarb wrote:
| I understand wanting to remove the overcomplicated Security
| Manager, but we have one use case which, as far as I can see, has
| not been mentioned at https://openjdk.java.net/jeps/411 : we
| install a custom security manager to prevent the software, when
| run on a developer machine, from accidentally connecting to non-
| localhost network addresses (we actually use a whitelist). I
| wonder how we'll do that after Java 17.
| the8472 wrote:
| Run it in a container with a separate network namespace?
| Doesn't even need a container, just unshare -Un on linux.
| anonova wrote:
| No releases for 17 yet, but checking the site, I discovered that
| AdoptOpenJDK was moved to the Eclipse Foundation and renamed to
| Adoptium: https://adoptium.net/
| sverhagen wrote:
| I don't know if I'm reading this right, but it seems that the
| Adoptium packages (were AdoptOpenJDK) are slated for Sept. 30
| the latest: https://github.com/adoptium/adoptium/issues/73
| sverhagen wrote:
| > we target releases to be available starting from the 20th
| of Sept.
|
| https://github.com/adoptium/adoptium.net/issues/167
| hyperpape wrote:
| On its own, the features specifically for Java 17 aren't
| obviously that compelling, but the important thing is that Java
| 17 is an LTS, the last one of which was Java 11, 3 years ago.
| Since many organizations, including mine, stick to LTS releases,
| that means a lot of developers will get a big change in what they
| can do sometime in the next few months as they upgrade to the
| LTS.
|
| Among other things, this means that we can begin to use records,
| pattern matching for instanceof, the shenendoah GC, and more.
|
| Links to JEPs for the other releases.
|
| http://openjdk.java.net/projects/jdk/16/
| http://openjdk.java.net/projects/jdk/15/
| http://openjdk.java.net/projects/jdk/14/
| http://openjdk.java.net/projects/jdk/13/
| http://openjdk.java.net/projects/jdk/12/
| cmckn wrote:
| This also brings some big gotchas, such as the closing of
| encapsulation loopholes. Unsafe code and various hacks calling
| into the JDK will break a lot of programs; so you might be
| stuck on 11 if you use HBase, Spark, etc.
| ragnese wrote:
| I must have missed this topic. What are these encapsulation
| loopholes that are being closed?
| pgwhalen wrote:
| You won't be stuck, you just need to add some command line
| flags when running your application, as a way of
| acknowledging these packages are breaking encapsulation.
| cmckn wrote:
| "Some" as in _dozens_ (for my apps, at least). It's a
| solution, but not a great one. The projects I depend on
| will have to remove such usages eventually to avoid awful
| UX (and avoid punching holes in encapsulation).
| pgwhalen wrote:
| > The projects I depend on will have to remove such
| usages eventually to avoid awful UX
|
| This seems like exactly the intended effect to me.
| excerionsforte wrote:
| You also get better NullPointerException messages, which to me
| have been super helpful during development.
| https://openjdk.java.net/jeps/358
| mreinhold wrote:
| Comprehensive list of all JEPs integrated since JDK 11:
| https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11
| mopierotti wrote:
| Here's another similar summary, but with code examples and
| categories.
|
| https://advancedweb.hu/a-categorized-list-of-all-java-and-
| jv...
| mabbo wrote:
| > Language
|
| > Pattern Matching for instanceof (16)
|
| > Records (16)
|
| > Restore Always-Strict Floating-Point Semantics (17)
|
| > Sealed Classes (17)
|
| > Switch Expressions (14)
|
| > Text Blocks (15)
|
| This is what excites me. Records, switch expressions and
| sealed classes are all excellent and even better together.
| Along with pattern matching switch statements, Java is
| finally losing a lot of cruft people complain about.
| foolfoolz wrote:
| a lot of these were the killer feature of scala that
| separated it from other languages
| hashmash wrote:
| I'm trying to find a good use case for records, but the
| best I can come up with is using it for composite hashmap
| keys. I suppose when combined with sealed classes and
| pattern matching features at some point it might be more
| useful, but what is the main use for records right now?
| Given that they're immutable and have no convenient way to
| be copied when modified, I find them quite tedious to use.
| cygned wrote:
| We would use them as data transfer objects between
| different layers of the system - however, they cannot
| extend another class and thus are not suitable in our
| specific case.
| pulse7 wrote:
| No more Lombok @Data annotations needed...
| mabbo wrote:
| Actually, I think it would be the lombok @Value. Record
| classes are immutable, while @Data adds set methods.
| cryptos wrote:
| I find records super useful! You can not only express
| things like a Point(x, y) easily, but you can also wrap
| primitive types like integer to give values semantic,
| behavior and typesafety. Records are the perfect fit for
| value types as used for example in Domain-driven Design.
| cupofjoakim wrote:
| I work as a systems developer for a bank and records is
| an easy replacement for a very popular dependency called
| lombok. Now, records doesn't necessarily do everything
| that lombok does, but for us it replaces what we actually
| need. One less dependency and I'm a happy camper.
| renw0rp wrote:
| I think it's worth highlighting that while Lombok is a
| dependency it is only a compile time dependency (it's not
| part of the output JAR).
| kjeetgill wrote:
| You say only, but I find that to be much more fussy.
| jsight wrote:
| Exactly, I hate dealing with Lombok projects for that
| reason. I'd rather the cruft than the compiler add-on.
| oauea wrote:
| Do you not just use maven? Any of the major IDEs will
| automatically configure annotation processors for you
| when they're configured in your pom. Similar for gradle.
| jsight wrote:
| Its been a while since I have had to deal with one, but
| at the time the IDE didn't handle it well at all. I think
| it was because I was missing the Lombok plugin.
|
| TBH, it was a lot of trouble so that someone could avoid
| generating a couple of getters and setters, and could use
| a annotation to setup the logger. I realize that there
| are more features available than that, but the ones that
| I've seen often used it in such mundane and boring ways
| that the setup wasn't worth the hassle for me.
|
| But I guess we all get annoyed with minor hassles in
| different ways. I got annoyed with the hassle of setting
| up an IDE, they got annoyed with getters and setters
| more. :)
| moystard wrote:
| I no longer think there is a justification for a project
| like Lombok. FreeBuilder/AutoValue (depending on your
| needs) will provide the same feature, but with clear
| visibility at the IDE level.
| geodel wrote:
| So one thing peculiar in Java is public records have to
| be in their own files. Now I wanted to treat records as
| less ceremonial than classes to organize code. I'd have
| liked to have a dozen or so records in a file along with
| some basic operations on them but it is not possible have
| multiple records without that many files.
|
| I know the answer is always use IDE and all but it causes
| more context switches than scrolling a bit to see types I
| created.
| smarks wrote:
| If you have a bunch of related records you can make them
| public and nested within a top-level public class. You
| could also throw some static utility or factory methods
| in there too.
| mabbo wrote:
| Honestly, I expect that half the classes I write will be
| records, once I have access to this.
|
| A lot of the time, the software I'm working on has data
| objects that are really amalgamations of other fields.
| Example: "Address" is the street address, the city, the
| postal code, etc, etc. These sorts of objects _should_ be
| immutable. Records are perfect for that.
|
| If I need to add additional logic, methods, then you can
| add those to a record. But it continues to enforce that
| the state is immutable.
| bcrosby95 wrote:
| I would use records a lot more (pretty much everywhere)
| if I could easily derive new values from existing ones.
| ivan_gammel wrote:
| There are some funny ways to work with records. I can
| recommend this article:
| https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-
| recor...
| stickfigure wrote:
| Still way too much typing compared to lombok's @Value
| @With.
| BoyRobot777 wrote:
| This will be solved[1]:
|
| record Point(int x, int y) {}
|
| Point p = new Point(1, 2); Point pp = p with { x = 3; }
|
| [1] https://github.com/openjdk/amber-docs/blob/master/eg-
| drafts/...
| stickfigure wrote:
| Interesting. It's ok. It seems like they're adding this
| syntax just to avoid extra copies eg, `p with {x = 3, y =
| 4}` instead of `p.withX(3).withY(4)`. I really don't mind
| the later.
|
| My gut feel is that records break encapsulation and will
| make refactoring slightly more difficult than the
| equivalent lombok value class. But if this gets more
| people making objects immutable, I'm all for it.
| ivan_gammel wrote:
| TBH both approaches are just poor design of the object
| model. The one from my link is a clever but inefficient
| way to manipulate records (reflection), the one with
| Lombok is creating redundant interfaces without business
| meaning. A record with few business methods is lean
| enough and ensures that only valid transitions can
| happen.
| stickfigure wrote:
| Eh? This is pretty good: Colour changed
| = colour.withRed(5);
| ivan_gammel wrote:
| Every method of your API must serve some business
| purpose. "With" methods and setters generated or written
| "just in case" often do not have one or they are being
| used only in tests, which would be insufficient
| justification for having them. Does your code really need
| to change individual components of the color? If it is
| not a graphic editor, probably not and those methods will
| be redundant.
| stickfigure wrote:
| That sounds unpleasantly pedantic.
| the8472 wrote:
| I guess records will make valhalla (value types) easier
| which enables more efficient data structures and will
| probably make passing data over FFI (valhalla) easier
| too.
|
| They reduce a lot of boilerplate, e.g. when passing
| multiple return values.
| cogman10 wrote:
| Records are orthogonal to value types (now called
| primitive types).
| suyash wrote:
| if you're coming from Java 8, here is a comprehensive list of
| new features since then
| https://ondro.inginea.eu/index.php/new-features-in-java-
| vers...
| Zardoz84 wrote:
| Laughs because we just change to Java 8.
| gunnarmorling wrote:
| I've compiled a Twitter thread with some of the key features
| new since Java 11 over the last few days:
| https://twitter.com/gunnarmorling/status/1434443970411704324.
| Also includes some links to related blog posts. Perhaps
| interesting for some to get a quick overview what you'll get
| with 17 when coming from 11.
| aembleton wrote:
| Here's the Thread Reader link:
| https://threadreaderapp.com/thread/1434443970411704324.html
| macspoofing wrote:
| >the last one of which was Java 11, 3 years ago.
|
| Extended support still behind Java 8 =)
|
| I suspect Java 8 will be with us for a long long time.
| shellac wrote:
| > the important thing is that Java 17 is an LTS
|
| That's not _strictly_ true.
|
| Java 17 is a release of the reference implementation, but there
| are a number of distributions from a variety of vendors.
|
| Oracle are going to provide long term support for their
| distribution, and it sounds like many will follow their lead.
| (If you are going to provide LTS it would be a little perverse
| to be out of sync with other providers of the same software)
|
| So, for all practical purposes, it is an LTS. But check with
| your vendor.
| jlengrand wrote:
| Do you know of any vendor for which 17 isn't considered an
| LTS? Genuinely curious
| brunoborges wrote:
| Ubuntu's, Alpine's, Debian's, and any Linux distribution
| that builds and ships OpenJDK from the source (except Red
| Hat's, of course).
|
| Yes, these are "distributions" (binaries) of OpenJDK that
| do not provide any sort of support, and clearly no LTS flag
| to them.
| dtech wrote:
| This is a bit pedantic. All relevant JDK distributors follow
| Oracle's LTS versioning scheme.
| stingraycharles wrote:
| I just checked but Oracle, OpenJDK, Azul, and Amazon are all
| going to consider 17 an LTS. So it seems like a reasonable
| assumption.
| shepherdjerred wrote:
| There are so many good features from the last LTS (11) to now.
| Some of my favorite languages are Swift and TypeScript because
| of how natural the syntax feels. Java is finally getting close
| to that level of flexibility with JDK 17.
| eternalban wrote:
| Great to see there is support for M1:
| https://openjdk.java.net/jeps/391
| _old_dude_ wrote:
| The support for M1 is backported at least by Azul, so you can
| get a Java 8 version which works on a M1
|
| https://www.azul.com/downloads/?version=java-8-lts&os=macos&...
| stu2010 wrote:
| It's worth noting that you may not always want to use the ARM
| JVM on M1 even if it's available, because then anything linked
| by JNI needs to be running on ARM also.
|
| I'm on an M1 Mac and have spent more time using the x86 JVM
| because the ARM JVM is less likely to have applications Just
| Work.
| brap wrote:
| Is there a way to see top new Java features since version X? For
| example my company is stuck at version 9 I believe, and I'd like
| to see what I'm missing out of at a glance
| _old_dude_ wrote:
| I'm using java almanac [1] for that.
|
| [1] https://javaalmanac.io/jdk/
| smarks wrote:
| https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11
| [deleted]
| geodel wrote:
| Lately I have insight similar to 'what hardware improvements
| give, software bloat take it away', 'what JDK platforms give
| third party Java frameworks take it away.
|
| I have this misfortune of dealing daily with a nasty Java
| framework which converts compile time errors into runtime errors,
| single error trace with multiple stack traces , most of them
| being from framework itself.
|
| One thing that might improve situation is server side libraries
| instead of framework. However AFAIK there is nothing like that in
| Java world. Everything is bound to Servlet API at lowest level
| and app server/frameworks on top of it.
| valbaca wrote:
| Dagger 2 is a fantastic lightweight DI framework that gets out
| of your way and keeps the errors to compile-time
|
| https://github.com/google/dagger
|
| After that you can throw in whatever libraries you want, dagger
| doesn't care.
| shipp02 wrote:
| What do you think of vertx. It seems pretty lightweight set of
| server side libraries along with activej which also focuses on
| speed.
| treypitt wrote:
| what was the framework, if you don't mind sharing?
| geodel wrote:
| SpringBoot.
| vbezhenar wrote:
| There are plenty of frameworks. Check out Helidon, Quarkus,
| Micronaut as examples of modern frameworks. You might like
| them. They're not bound to servlet API.
| geodel wrote:
| I should have clarified one unfortunate part of this is
| enterprise diktat. So I stand no chance when a snake oil
| salesman from VMWare tells CIO on which framework they
| provide support for.
| anonymousDan wrote:
| Oh man, I feel old.
| throw0101a wrote:
| Seems that 17 is an LTS release:
|
| * https://www.oracle.com/java/technologies/java-se-support-roa...
| gjsman-1000 wrote:
| Reportedly, not much "big new stuff" got into this release (maybe
| next time), but it's an LTS so it's not the best time for that
| anyway.
| thinkharderdev wrote:
| The new FFM API looks really cool. Still incubating but having
| better native interop I think could really be a big win. Most
| developers will never touch that stuff but having the ability
| to manage native, off-heap memory and safely(ish) make native
| calls will be great.
| twic wrote:
| I wrote an app which used JNI to call into C++ code. I ended
| up refactoring it to spawn subprocesses written in C++, and
| communicate with them via RPC. Not because JNI was difficult,
| but because errors in the C++ can take down the whole app
| otherwise. All the performance and ergonomics improvements in
| the world wouldn't persuade me to give up that safety
| barrier.
|
| Unless i rewrite the native parts in Rust, of course :).
| carimura wrote:
| The teams working on the JDK think about their work in 6-month
| release cycles, not LTS cycles. What's ready to go in when the
| train leaves the station, goes in, what's not, waits another 6
| months. And this applies across the board for incremental
| changes coming from Amber, Loom, Valhalla, Panama, etc.
|
| The danger of thinking in LTS cycles is a feeling that a
| feature needs to be rushed to make it in, which might
| jeopardize the production-ready quality on Day 1 of GA. It's
| very important to us that the ecosystem can trust every
| release, in production, right out of the gate.
| tikkabhuna wrote:
| Can't remember where I heard it, but the thought was that "big
| stuff" was skipped in case it created bugs that then had to be
| maintained for the entire LTS support period.
| carimura wrote:
| See my parallel comment on this philosophy. Also, it's likely
| we'll never see "really big stuff" in a single release as the
| 6-month cadence has made possible incremental changes to a
| larger vision. Case in point, see Project Amber [1].
|
| [1] https://inside.java/tag/amber
| gavinray wrote:
| A ton of huge stuff was in JDK 16 though, and seems most
| companies won't upgrade until LTS releases, so folks should be
| looking at JDK 17 as JDK 12-17 if they're in a corporate
| environment.
|
| Records, multiline strings, pattern matching for instanceof,
| handling nulls in pattern matching/switch, sealed
| classes/interfaces, probably other things I'm forgetting.
|
| I had never written Java before until recently, and thank god
| for JDK16 features. Only thing that made it slightly tolerable.
| rickette wrote:
| Most products/projects I know are on Java 11 LTS and will
| probably upgrade to this release. Between 11 and 17 there's
| quite some new stuff.
| filereaper wrote:
| I've been out of the loop with the Java ecosystem, but has the
| transition from Java 8 to 11 completed where most of folks here
| work?
|
| I was also curious about large ecosystems like Hadoop and their
| moves from 8 to 11.
| stingraycharles wrote:
| I know of a number of RHEL-based deployments we're managing
| that still use Java 8. In general, if you're developing
| libraries, you still need to support Java 8, because there are
| a significant amount of enterprise deployments that use it.
| syncsynchalt wrote:
| Anecdote: We _just_ fixed our last JDK11 blocker here at $corp
| (the groovy 2.x runtime was holding us on JDK8). Our new
| quality gates are likely going to keep us closer to the latest
| and greatest, so I don't see a lot of problems with us jumping
| to JDK17 sooner than later.
| twic wrote:
| I work in finance, hedge fund kind of stuff. My team has its
| main apps on 11, with a long tail of minor services on 8. One
| other team in the company has been keeping up with each release
| (brave souls!). Most others are in a similar place to us.
|
| I've been interviewing lots of candidates recently, and i
| usually chat a bit about what versions they've used. Only one
| is using 11, the rest are on 8. One only finished migrating to
| 8 this year!
| shadycuz wrote:
| If only I could understand the difference between java 1.8, 8 and
| 18.
| jsiepkes wrote:
| Starting from 1.6 they only showed the minor version number. So
| 1.6 = Java 6, 1.8 = Java 8, etc.
|
| I always assumed this was because .net (arguably it's main
| competitor) was churning fast through version numbers and they
| "wanted to keep up".
| oaiey wrote:
| And now it is the other way around. C# burning through the
| versions to catch up the versions (and not so much the
| content).
|
| PS: had to edit, was really just a note about the numbers not
| the content of the versions!!!
| x0n wrote:
| Catch up to what? The JDK 17 JEP list reads like a list of
| things that were added to dotnet years ago.
| jsiepkes wrote:
| Thats kind of a hyperbole.
|
| .net didn't add support for macOS on ARM64 years ago.
| .net also didn't implement 2D rendering on macOS via
| Metal. etc. As a matter of fact .net didn't even support
| any other platform then Windows until recently.
| oaiey wrote:
| Just version numbers, not content :)
| DaiPlusPlus wrote:
| C# has never had to play catch-up with Java, it's always
| been the other way around.
| pulse7 wrote:
| Ohhh.... C# was invented as a response to Java... So it
| had to play catch-up with Java - at it's inception...
| jsiepkes wrote:
| Even worse: C# came as a response when Microsoft failed
| to apply their embrace, extend, extinguish tactic on Java
| like they did with Netscape[1].
|
| In the end the case was settled out of court and MS
| agreed to pay more then 1 billion dollar to Sun. MS also
| agreed to license a whole slew of patents for use with
| .net.
|
| [1] https://www.pinsentmasons.com/out-law/news/sun-sues-
| microsof...
| nobleach wrote:
| It was a very Sun-like thing to do. Sun dropped the 2. after
| their 2.6 release. Solaris 7 was the next release... then 8.
| shadycuz wrote:
| Ahh so 17, is 1.17?
|
| I swear I googled this like 2 months ago and the first 2 or 3
| links weren't helpful so I gave up. Thanks!
| shawnz wrote:
| Effectively yes, but the "1.x" format is deprecated since
| Java 9 and not used anymore, whereas versions 5 through 8
| used both notations.
|
| See https://openjdk.java.net/jeps/223#Dropping-the-
| initial-1-ele...
| deepsun wrote:
| I wish they would name it 2021, 2022 etc.
| bcrosby95 wrote:
| They have a 6 month release cadence.
| codetrotter wrote:
| 2021.0, 2021.5, 2022.0, ... :^)
| hocuspocus wrote:
| They tried for a short while (I think Java 10 was
| supposed to be 18.3) but stuck to incrementing major
| versions after all.
| rickette wrote:
| 1.8 and 8 are the same thing. Java switched to full version
| numbers like 9, 10, 11, etc now 17 some time ago.
| codetrotter wrote:
| https://en.wikipedia.org/wiki/Java_version_history
|
| > J2SE 5.0
|
| > [...]
|
| > The release on September 30, 2004 was originally numbered
| 1.5, which is still used as the internal version number. The
| number was changed to "better reflect the level of maturity,
| stability, scalability and security of the J2SE".
|
| and
|
| > This version introduced a new versioning system for the Java
| language, although the old versioning system continued to be
| used for developer libraries:
|
| >> Both version numbers "1.5.0" and "5.0" are used to identify
| this release of the Java 2 Platform Standard Edition. Version
| "5.0" is the product version, while "1.5.0" is the developer
| version. The number "5.0" is used to better reflect the level
| of maturity, stability, scalability and security of the J2SE.
|
| >> -- Version 1.5.0 or 5.0?[32]
|
| [32]:
| http://docs.oracle.com/javase/1.5.0/docs/relnotes/version-5....
| [deleted]
| fractalb wrote:
| > 414: Vector API (Second Incubator) Is it something like C++
| vector class?
| tkot wrote:
| ArrayList would be something like C++ vector. Vector API is
| supposed to support using vector (SIMD) instructions supported
| by many CPUs today.
| avodonosov wrote:
| I am skeptical about the "strong encapsulation" and in general,
| of all cases whey people tell me about something: "you don't need
| it, it's better for you to do it other way".
|
| Usually I know better what I need. There were cases when I needed
| to access the internals, e.g. fixing a prod issue.
|
| A quote from Thinking Forth comes to mind:
|
| > The newest traditional languages (such as Modula 2) bend over
| backwards to ensure that modules hide internal routines and data
| structures from other modules. The goal is to achieve module
| independence (a minimum coupling). The fear seems to be that
| modules strive to attack each other like alien antibodies. Or
| else, that evil bands of marauding modules are out to clobber the
| precious family data structures.
|
| > This is not what we're concerned about. The purpose of hiding
| information, as we mean it, is simply to minimize the effects of
| a possible design-change by localizing things that might change
| within each component.
| avodonosov wrote:
| Also, justifying it by security is not convincing.
| Encapsulation / decoupling and security are different things.
| The internals can anyways be accessed through core-dumps,
| /dev/mem, side-channels, etc.
|
| Yes, the strong encapsulation of JDK impl classes can create
| some inconveniences to an attacker. But I don't feel it's
| valuable enough to justify luck of access to the internals.
| danogentili wrote:
| Fixing a prod issue by bypassing encapsulation and other
| programming practices sounds very much like accumulating
| technical debt. Encapsulation may be a lot more verbose, but it
| remains the best way to isolate software modules, to write
| better tests, and improve the overall reliability of software.
| avodonosov wrote:
| It was a one-time script, no debt.
| exabrial wrote:
| In that case, I think a Java Agent is better suited to your
| needs. We have one we wrote that will intercept a class load
| and hot-patches the byte code.
|
| This allows us to fix bugs in 3rd party software or the JDK
| itself until fixes can be released upstream and we don't wish
| to release an internal version of an artifact. Not something we
| use exclusively for obvious reasons, but it's a handy tool to
| have in the toolbox when we're forced up against a wall.
| avodonosov wrote:
| I multiple cases that I had Java Agent would not help.
| vbezhenar wrote:
| Library developers start depending on Java internals.
|
| Developer change internals, because they want to improve
| something.
|
| Library breaks.
|
| Users don't want to update to new Java because their code does
| not work.
|
| They want to break that chain, I guess.
|
| Also I think that you still can allow access to any internal
| class using --add-opens
| ianpurton wrote:
| I'm curious if it would be possible to remove null from Java.
|
| There's already support for Optional.
|
| I mean I guess a lot of code would stop compiling, or could it be
| deprecated somehow.
| igouy wrote:
| Why would "remove null" be better than the Dart approach --
| "When you opt into null safety, types in your code are non-
| nullable by default, meaning that variables can't contain null
| _unless you say they can._ " ?
|
| https://dart.dev/null-safety
| MarkMarine wrote:
| Java tries so hard to be backwards compatible, I think null is
| here to stay. There is always Kotlin if you want better null
| safety, or compile time checks like null-away, but they are
| still null adjacent. Disappointing but that's what we're stuck
| with in service of backwards compatibility, but I'm not sure
| making these breaking changes is an improvement... look at
| Python 2->3 for an example
| suyash wrote:
| yes and most java developers have come to terms with null and
| NPE, it's just part of programming in Java so honestly I'm
| fine with it being here.
| Cojen wrote:
| ...and now that NPE has a "helpful" message, I've generally
| found it to be almost a non-issue these days. During
| development, I can usually figure out the problem
| immediately just from the message and I don't need to
| examine the stack trace.
| grishka wrote:
| Not without changing everything in significant ways. There are
| two distinct kinds of types in Java: objects, including arrays,
| and primitives. Objects are represented as pointers, and those
| can be null -- that's their default value. And multiple
| pointers can point to the same object. Primitives (int, long,
| boolean, char, byte, short, float, double) are "value types",
| they can't be null, are copied on assignment, and have
| meaningful default values (0 for numbers, false for booleans).
| Adding non-primitive value types would mean having to solve
| many new problems that C++ had and still has. That said, they
| are exploring this idea, iirc they call it "project valhalla".
| syncsynchalt wrote:
| Java could adopt swift-like `Object!` typing for non-nullable
| variables and spread that guarantee through the compiler and
| JVM runtime.
|
| I don't think it's a technical impossibility, but it's more
| likely to be solved by a JVM-based language like Kotlin than
| it is to get it adopted into the Java mothership.
| grishka wrote:
| Compile-time checks definitely can't guarantee anything.
| You could still end up with null pointers from, for
| example, a library like gson using reflection to set
| fields. If you add "non-null" to the type descriptors
| inside class files (something like Kjava/lang/Object;
| instead of the usual Ljava/lang/Object;) and have the JVM
| enforce non-null-ness at runtime, you'll still have crashes
| caused by null pointers but earlier. Oh and you'll have to
| make an exception to allow these to be null during a
| constructor or static initializer invocation so it could
| actually initialize everything. It gets messy.
|
| IIRC that proposition for value types makes them more akin
| to structs, without inheritance and dynamic methods. And I
| don't remember whether the fields are final, but given the
| current trend towards making everything as immutable as
| possible, they probably are.
| derefr wrote:
| Who said anything about non-primitive value types? Java just
| needs a second kind of reference type: non-nullable reference
| types that are always initialized, where a direct assignment
| from a nullable-reference-typed value to a non-nullable-
| reference-typed slot fails to compile (but the opposite
| succeeds.) You'd instead have to go through
| Optional.ofNullable or somesuch, where that proxy type would
| then be modified to have variants of .get et al that return a
| non-nullable-reference return type.
| thinkharderdev wrote:
| I think it is certainly possible. In Scala you enable "explicit
| nulls" and it will not compile if you try to set a value to
| null (https://dotty.epfl.ch/docs/reference/other-new-
| features/expl...) without making the type a union with Null.
| tathisit wrote:
| Kotlin does it, but it's next to useless because the ecosystem
| makes heavy use of null.
| Tainnor wrote:
| what? I don't feel it's "pointless" at all. Many popular Java
| libraries and frameworks (including Spring) use nullability
| annotations which can be interpreted correctly by Kotlin.
| It's true that I can't be 100% sure not to get NPEs, but I
| think it's close enough and I've rarely seen NPEs in Kotlin
| codebases.
| rickette wrote:
| Indeed, Kotlin's null handling is great. NPE's in Kotlin
| code aren't common.
| syncsynchalt wrote:
| Kotlin is my suggestion too.
|
| Kotlin (or any other JVM variant that does non-nullability in
| a seamless way) and coding guidelines should get you 90% of
| the way to a null-free world.
| oweiler wrote:
| Maybe if Optional becomes a value type
| echopom wrote:
| Link with respectives JEP [0]
|
| [0] https://openjdk.java.net/projects/jdk/17/
| azalemeth wrote:
| I would like to ask a question, in order to elicit the detailed
| and considerate comment that HN is known for. It's not intended
| to inflammatory in any way shape or form!
|
| I am not a Java developer. I am one of those users who has a bad
| memory of using Java desktop apps in ~2001 where they ate a ton
| of ram, seemed horrendously slow, and had example "Hello Worlds"
| that are reminiscent of Enterprise FizzBuzz [1]. At some point in
| the last 20 years, Java has gone the other way -- it has a
| reputation (I think) of being "boring", "performant" and used by
| businesses for doing server-side logic. Still, the only way I
| interact with it is with the occasional dependency install.
|
| I've noticed:
|
| -- There are a bunch of different JREs/JDKs, most famously
| Sun's/Oracle's own Java, OpenJDK, OpenJDK built by Other
| People(tm), and Random Other JDKs (Azul; Amazon Corretto).
|
| -- People rail against Sun/Oracle and what happened to Java.
|
| -- For a bloody long time I had to download the JDK separately
| and/or type in "agree" into a very un-friendly sounding license
| at the command line.
|
| Can I therefore ask the HN meta-brain to either explain, or point
| me to a reference that explains:
|
| -- What the ideological and _practical_ differences are between
| the JDKs
|
| -- _Why_ there are different JDKs -- I get that that it 's good
| to have different language implementations, but there are really
| quite a lot!
|
| -- _What Oracle did_
|
| -- And what was the beef with the whole open-source license was.
| Isn't opener-better?
|
| Thank you!
|
| [1]
| https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
| kjeetgill wrote:
| For the most part, the various JDKs not really different.
| They're builds of the same OpenJDK repo.
|
| They occasionally have a few small changes, maybe with a few
| extra bugfixes new or a backported.
|
| The one small difference between compiling it yourself is that
| Oracle does control the TCK, a test suite for the binaries that
| Azul and others might use but not open to you.
| slowmotiony wrote:
| I've got a task at work to install Oracle WebLogic and
| migrate a legacy app from an older OAS instance. The Weblogic
| installer didn't even run on OpenJDK, it specifically checked
| for it and crashed with a "OpenJDK builds are not supported"
| error. No idea why that is since I read everywhere that
| they're essentially the same thing.
| rowland66 wrote:
| I believe that when you license Weblogic from Oracle, the
| Weblogic license includes a license for the Oracle JVM it
| runs on. So there is no reason to run Weblogic on another
| JDK/JVM. I assume that Oracle requires their JDK/JVM for
| Weblogic to keep support simpler.
| 20210911 wrote:
| Java is set of specs from https://jcp.org, Implemented by
| various parties, IBM J9, Sun(Oracle) HotSpot, BEA
| Systems(Oracle) JRockit are I know of. Sun open source HotSpot
| as OpenJDK, Then Oracle merged some code from JRockit, IBM also
| joined some in to OpenJDK, after shit with
| https://harmony.apache.org , OpenJDK is GPL, Oracle provides
| compiled version, but there are issues with it's license and
| long term support, You have to pay for long term support to
| Oracle, Some product are there still running on JDK 1.4 Since
| OpenJDK is GPL Redhat provide compiled version for redhat linux
| called IcedTea, Eclipse foundation provide adoptium, and there
| are commercial support providers like Azul
| krzyk wrote:
| openjdk compik3d version is gpl eith classpath exception. so
| one can use it in production enterprise apps
| whartung wrote:
| For a while, there were some nitty, edge case, "UFO" types of
| differences between OpenJDK and the Oracle JDK. But that's
| mostly been resolved.
|
| Oracle owns "Java", that is the name, the trademark, etc. In
| that sense, OpenJDK is "not" "Java". But operationally, this is
| moot. But it has impact in other areas. What was originally
| "Java Enterprise Edition" was transferred over to the Eclipse
| Foundation, but they couldn't take the "java" name with them.
| All of the JEE packages were "javax.enterprise. _". Oracle
| wouldn 't give up the "Java" part in order to not dilute its
| trademark, so now its the "Jakarta Enterprise Edition", and all
| of the packages are being renamed to "jakarta.enterprise._". I
| mention this just as an example of the hoops the community
| going through, even today, over what's happening with java.
|
| So, Oracle and the community have to dance a fine line over
| what is the language, compilers, tools, and libraries, and what
| is "java", what is trademarked, what is owned by Oracle.
|
| Oracle was kind enough to be an invested member in the Java
| community by not forking, closing, and going off its own way,
| and leaving the OpenJDK to fend for itself. This is essentially
| what happened to Solaris and OpenSolaris.
|
| The other JDKs (Zuul, AWS, etc.) were certainly a hedge against
| this. The industry has a lot invested in "java", and can't
| really afford to let it get out of hand. Having "official"
| builds, that were supported, and patched, and eyes on vs the
| latest release from OpenJDK gives companies a secure feeling.
| That's why other companies stepped up to support their own
| JDKs. To help assure clients that the technology is stable and
| still worth building on.
|
| So, the differences are not so much different languages, or
| even different implementations (though there is certainly some
| of that). Rather much of it is simply stability in the
| community.
|
| Also, the whole licensing issue with Oracle vs the others was a
| big deal also. We'll see what impact the new free license from
| Oracle has.
| sebazzz wrote:
| > All of the JEE packages were "javax.enterprise.". Oracle
| wouldn't give up the "Java" part in order to not dilute its
| trademark, so now its the "Jakarta Enterprise Edition", and
| all of the packages are being renamed to
| "jakarta.enterprise.". I mention this just as an example of
| the hoops the community going through, even today, over
| what's happening with java.
|
| That is quite a change, and probably not very backwards
| compatible?
| whartung wrote:
| No, it's not at all. But, since that code needs to run in a
| formal container (app server) environment, the app server
| makers do classloader and renaming shenanigans to be able
| to load code from the earlier toolkits.
|
| But, yea, it was a big clod to drop in the churn.
| the8472 wrote:
| > What the ideological and practical differences are between
| the JDKs
|
| The builds may ship with different optional features enabled,
| such as various garbage collectors or I think support for the
| GraalVM stuff. Support terms differ.
|
| > Why there are different JDKs -- I get that that it's good to
| have different language implementations, but there are really
| quite a lot!
|
| Most of what you will get these days are just different builds
| of the OpenJDK class library + tools + Hotspot (JVM). Well,
| except for the android runtime, but we don't talk about that
| one. Historically there have been been more JVMs and class
| libraries but that has been consolidated a lot since oracle
| opensourced it. There still is OpenJ9 and some smaller, more
| specialized ones.
| matsemann wrote:
| > memory of using Java desktop apps in ~2001 where they ate a
| ton of ram, seemed horrendously slow,
|
| Note that the horrible end user experience of running java
| programs (or java plug-ins in the browser) back in the day,
| never was indicative at all of how it's for running on servers
| and those kind of workloads. The stuff I've written in java for
| backends have been blazingly fast (compared to python for
| instance) and with much better tooling. So devs choose java/jvm
| because it works well, despite some shortcomings in some areas.
|
| Btw, I think you'd find today's java desktop apps to be
| snappier than you'd think (especially compared to electron for
| instance). Bundling the jvm removes the hassle of having to
| install something separate and version issues. And AOT
| compilation and the new modularity of the stdlib makes the
| files smaller and quicker to load.
| [deleted]
___________________________________________________________________
(page generated 2021-09-14 23:02 UTC)