[HN Gopher] Java 16
___________________________________________________________________
Java 16
Author : JCWasmx86
Score : 347 points
Date : 2021-03-16 14:30 UTC (8 hours ago)
(HTM) web link (jdk.java.net)
(TXT) w3m dump (jdk.java.net)
| benjiweber wrote:
| Lots of shiny new toys to play with :) I like playing with new
| features and pushing to silly limits. Here's some fun things you
| can do now:
|
| Compiletime checked state machines with Sealed Classes [preview
| feature] https://benjiweber.co.uk/blog/2020/10/03/sealed-java-
| state-m...
|
| Autobuilders, Mixins, Conversions & more with Records
| https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...
|
| Pattern Matching fun
| https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...
| bob1029 wrote:
| If you enjoy pattern matching in Java, I would recommend
| checking out the latest & greatest that C# has to offer as a
| comparison:
|
| https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match...
|
| Being able to combine pattern matching with switch expressions
| has allowed us to construct extraordinarily concise state
| machines for our UIs.
| [deleted]
| bestouff wrote:
| Nice, but I still prefer Rust's match syntax. It feels
| natural and ergonomic.
| victor106 wrote:
| I used Java a lot and like some aspects. But I think C# is
| way ahead in some important ways and Java is playing catch-up
| pjmlp wrote:
| They keep playing catch up with each other, in different
| ways across the eco-system and language features, since
| they exist.
| kaba0 wrote:
| Java is really conservative language-wise while C# is
| pretty much add everything you see, reminiscent of C++.
|
| Also, a significant part of Java development happens at the
| runtime level, where I would wager the catch-up is in the
| opposite direction, in some areas by quite large margins.
| cmckn wrote:
| Not considering async/await (because I'm not really a fan),
| they're neck-and-neck in my opinion. I don't think C# has
| been as careful with its abstractions and the general
| aesthetic of the language to the degree that Java has; but
| in many cases you can almost compile a block of Java as C#
| and vice versa. I think the primary differentiator is what
| toolchain/ecosystem you prefer, and I'm solidly on the Java
| side of that line.
|
| That being said, I'm currently getting paid to write C#, so
| if you've got any resources for converts, I'd love them! :)
| LordDragonfang wrote:
| >I don't think C# has been as careful with its
| abstractions and the general aesthetic of the language to
| the degree that Java has
|
| You say "careful", others would say "stubborn". The
| refusal to add things like operator overloading lead to a
| much less aesthetically pleasing language to read and
| write.
| aardvark179 wrote:
| I can understand the resistance to traditional operator
| overloading, but something like implementing a Monoid
| interface which specifies operator methods might work. I
| think the sort of value types that people are likely to
| implement with Valhalla will make the case for this much
| stronger.
| ernst_klim wrote:
| Or just use Scala and stay on JVM. You can even easily mix
| Scala and Java classes within the project.
| exdsq wrote:
| Love the state machine example :)
| elric wrote:
| Nice to see that Records are finally out of preview. But note
| that Sealed Classes are still in Preview mode and are subject
| to change (or removal) in newer versions.
| krzyk wrote:
| Removal is not likely, nor is major change. Most likely some
| minor changes.
| yawaworht1978 wrote:
| Someone asked where is Java still used. Well, elasticsearch,
| signal for android, mockito, j-unit.
|
| Closed source projects include Airbnb, Uber, eBay, Pinterest,
| Groupon, Spotify, Intel, Symantec
| Thaxll wrote:
| Site is dying with 500.
| justin_oaks wrote:
| Got the same at first. Reloaded the URL and it came up
| correctly.
| flemhans wrote:
| Same experience. A few refreshes and it works.
| throwaway4good wrote:
| The beauty of a load balancer ...
| JulianMorrison wrote:
| Looks like they added sensible no-boilerplate immutable data
| objects, and are trying to unbox their boxed primitives, yay for
| common sense at long last.
|
| While they're about it, they should also add immutable/copying
| data structures.
| BoyRobot777 wrote:
| >While they're about it, they should also add immutable/copying
| data structures.
|
| They will start with records[1], but I think all value classes
| (Valhalla) should have this functionality eventually.
|
| You will be able to write: record Point(int x,
| int y){} Point pp = p with { x = 3; }
|
| [1]https://github.com/openjdk/amber-docs/blob/master/eg-
| drafts/...
| JulianMorrison wrote:
| This is definitely good, but I'm also meaning Clojure style
| lists, maps, etc where you can treat any given copy of the
| entire data structure as one big immutable value.
| closeparen wrote:
| Man, I hope the migration to Java 11 that my infrastructure team
| started 18 months ago is going okay.
| kronin wrote:
| Can't read whether this is sarcastic or tongue in cheek ;-)
|
| Java 11 is the newest LTS release. The next LTS release will be
| Java 17. Many companies won't touch anything that isn't LTS.
| There are still a large number of companies staying on Java 8
| :shrug:
| vips7L wrote:
| LTS doesn't exist within OpenJDK. LTS only exists if you're
| paying a specific provider for it.
| dadoge wrote:
| Very cool to see that Scala continues to have a huge impact on
| Java's roadmap.
|
| Records and Sealed Classes are borrowed from Scala.
|
| Could be not the best news for new Scala adoption, but good news
| for developers having better abstractions in Java
|
| Edit: Kotlin, and other languages should also mentioned since
| they also include similar features. I still think Scala has had
| the most influence over the years.
| bishop_mandible wrote:
| > Records (...) are borrowed from Scala.
|
| I think records already existed in FORTRAN and other languages
| like ALGOL-60. C has structs, too.
| [deleted]
| todd8 wrote:
| Yes you are right, records have been around for a long time.
|
| COBOL was a popular, very early language supporting
| hierarchical data of different types. This dates back to
| approximately 1960.
|
| FORTRAN didn't have records other than I/O "records" (at
| least for the first 20 years). ALGOL-60 didn't have records.
| Algol-68 did have records, however Algol-68 wasn't in very
| widespread use. I never had an opportunity to use it;
| compiler technology at that time wasn't really ready for such
| a challenging language. Algol-68 may not have had widespread
| use, but a number of it's features made their way into
| influential languages like C, Pascal, and Simula. These
| languages did have records.
|
| As I recall, IBM's PL/1 did have records, I seem to recall
| using them in the 70's in a PL/1 program. PL/1 was kind of an
| amalgamation of FORTRAN and COBOL's features.
| cmrdporcupine wrote:
| In the end... Pascal was/is hugely influential, and, yeah,
| it called these kinds of things "Records." But the funny
| thing is it's been so long since I wrote Pascal or Modula-2
| that when I first heard the term "Record" in the context of
| Java I never made the connection.
| ragnese wrote:
| I think it's fair, though, to say that it's likely that the
| implementation and/or semantics _may_ be more based on other
| JVM languages, who have to work on Java 's terms.
|
| In particular, I'm talking about the fact that Java doesn't
| really have "copy types" or "pass by copy" or whatever. So,
| sure, C has struct, Swift has struct, etc, but Java can't
| really model its version off of the way those work.
| sireat wrote:
| Besides Scala, I feel both Kotlin and Rust have been heavily
| influenced by Scala.
| BoyRobot777 wrote:
| Why not Kotlin, C#, F#, ML and so many other languages?
| u678u wrote:
| I spent a few years moving to Scala but have come back as Java
| really does everything I want now. Just Akka is a bit clunky.
| eweise wrote:
| I think Kotlin is more at risk than Scala on the server at
| least. Scala still has a lot of advanced features that sets
| itself apart. Kotlin is a better Java but Java is catching up
| fast.
| ragnese wrote:
| Agreed. But Kotlin 1.5 will have enough interesting stuff
| with the new inline class and const methods that I think
| it'll keep its appeal for quite some time.
| kaba0 wrote:
| But I fear kotlin will fall in-between all the platforms
| they try to support, and will end up comparatively bad on
| all. Like, you can't really target both your coroutines on
| each platform as well as project loom properly, same with
| project Valhalla and the like.
| ragnese wrote:
| Why can't coroutines take full advantage of Loom's green
| threads on JVM and do other stuff on Native/JS/whatever?
|
| I generally agree that being multiplatform is a lofty
| goal. And as much as I like Kotlin, it clearly inherits
| some of Java's (IMO) deficiencies. I'm not sure why I'd
| _want_ those deficiencies exported to my native code when
| I could use lots of other nice languages.
| BoyRobot777 wrote:
| I think Loom can be abstracted away by Kotlin quite
| easily. Valhalla on the other hand won't work at all. You
| won't be able to have inline classes in android/older
| Java versions. Even more - specialized generics.
| jicea wrote:
| Developing now 80% in Kotlin and 20% in Java (on backend),
| I really think the main advantage of Kotlin over Java is
| nullability. You can use @Nullable/@NotNull annotations in
| Java, but nullability being a part of the type system in
| Kotlin is better. I also love being able to create simple
| functions and add extension methods to existing classes.
| But still, nullability is the strongest advantage of Kotlin
| and I don't see how Java will address it.
| ragnese wrote:
| Agreed about nullability. And Java will never fix it
| fully or I'll eat my hat.
|
| ... but, you have to be pretty damn good to win out over
| the native language of a platform. And if it were just
| Kotlin today vs. Java 16, I think Kotlin is a much nicer
| language, but it doesn't _really_ differentiate itself
| that much. Sure, it 's syntax is _much_ nicer, but you
| still basically have the same semantics as Java. You have
| classes; everything is a reference; no const /immutable
| data; no (good) general way to clone things; you have the
| same-ish type system with inheritance and interfaces, but
| no type classes; still have weird shit like sized numeric
| types with over/underflow; exceptions for error handling;
| etc.
|
| At least Scala has monads and type classes, so you can
| say it actually has some expressability that Java truly
| doesn't. I'm not sure that Kotlin has that. Clojure is a
| totally different beast that really doesn't directly
| compete over Java devs, IMO. It just happens to use the
| JVM as a platform.
| meddlepal wrote:
| I think the reaction has been more to Kotlin than Scala.
| jmarcher wrote:
| Arguably, Kotlin took some of the better ideas from Scala.
| virtualwhys wrote:
| Arguably? I'd say it's rather obvious, but overall they're
| different languages with different goals.
| Koshkin wrote:
| To be fair, "arguably" has come to mean "no doubt."
| dadoge wrote:
| I'm more a Scala dev than Kotlin
|
| Think it's safe to say both influenced Java's Record, shoulda
| mentioned Kotlin too.
| Number157 wrote:
| Kotlins data class is functionally basically the same as a
| lombok @Data class used in Java. Why Java didn't keep the
| name "Data class" I don't know.
| ragnese wrote:
| "Data" is such an overloaded and vague term, anyway.
| Almost all classes have "data", so what the heck is a
| "data class"? Is it one that _only_ has data (not
| behavior)? Nope- these can have arbitrary methods.
|
| So, I'm kind of glad they didn't use it. (But, to
| clarify, I really don't care what color the bike shed is)
|
| I'm more wondering why they didn't go with "struct" or
| "value class", especially because the latter is exactly
| what we've been calling "class whose equals() is defined
| by content rather than identity" for many years.
| kaba0 wrote:
| Because while in the end project valhalla will not call
| them value classes, it is a sort of an overloaded term.
|
| Structs/value types can be mutable, records are not. They
| are basically tuples with names. And as far as I know,
| while records have a sane default equals defined, they
| are still identity objects in that they are passed by
| reference.
| ragnese wrote:
| > Structs/value types can be mutable, records are not.
|
| Fair point about record fields not being reassignable
| (not the same as immutable for others reading this).
|
| > And as far as I know, while records have a sane default
| equals defined, they are still identity objects in that
| they are passed by reference.
|
| Well, sure. All non-primitives are passed by reference.
| That doesn't stop them from being referred to as value
| types.
|
| But in light of your first point, I agree that choosing a
| totally new term probably makes sense.
| wpietri wrote:
| I hope they're subsidizing the Scala project, and Kotlin too.
| Nothing better for a dominant player than having other people
| scout the territory for you.
| geodel wrote:
| I think millions of man hours went in JVM development will
| count for lot of subsidy.
| Decabytes wrote:
| This is why it's so important to have different programming
| languages! Sometimes it's hard to do things differently when
| you are just looking at your own programming language, and the
| tools it has available to it. Not everyone programming language
| needs to be a behemoth to be useful to other people. I say keep
| making new an interesting programming languages! It will only
| lead to better programming languages over all
| JohnKacz wrote:
| I saw someone recently post the idea that Java/Scala/F# almost
| functioned as LTS/Stable/Dev in reference to how these
| languages were sharing impact.
| ragnese wrote:
| I think the person actually said Java/C#/F#.
|
| But in any case, I'm thinking that the real timeline is more
| that Java is prioritizing features that are most attractive
| from Kotlin, which borrowed the ideas from Scala. But Scala
| never got super popular, so there was not much pressure or
| "proof" that these were good ideas until everyone fell in
| love with Kotlin.
| mdm12 wrote:
| We see similar developments with C# borrowing features from F#,
| with records in v9, pattern matching, etc.
|
| While it's good for C#/Java, it does make it harder to push for
| adoption for a language such as Scala and F#. Why bother
| investing in the languages with a much smaller market share
| when the big boys adopt good bits and pieces from them
| constantly?
| dweekly wrote:
| Really sorry to ask the dumb question here, but what is V9? A
| cursory Google search didn't show me anything about e.g. a
| major update to the V8 JavaScript engine?
|
| UPDATE: Ah, C# v9.0 thank you all.
| mdm12 wrote:
| I meant 'v' as in 'version' of C#, here's a good reference
| on it: https://docs.microsoft.com/en-
| us/dotnet/csharp/whats-new/csh...
| yashap wrote:
| They meant version 9 of C#, the language.
| T-zex wrote:
| it is a C# language version. https://docs.microsoft.com/en-
| us/dotnet/csharp/whats-new/csh...
| [deleted]
| BuckRogers wrote:
| "We see similar developments with C# borrowing features
| from F#, with records in v9, pattern matching, etc."
|
| Parsing that sentence the subject is C# and F# is
| referenced, but the subject of the sentence didn't change,
| it remained C# thus logically v9 applies to it.
| url00 wrote:
| C# 9.0: https://docs.microsoft.com/en-
| us/dotnet/csharp/whats-new/csh...
| gugagore wrote:
| > Why bother investing in the languages with a much smaller
| market share when the big boys adopt good bits and pieces
| from them constantly?
|
| This won't always apply, but sometimes (many times?) there's
| a software endeavor that permanently feels on the margins of
| a programming language's capabilities, whatever that means.
| You may forego market share in order to be 5 or 10 years
| ahead of current practice. In other words, the mainstream
| isn't converging to a stable F# / Scala / whatever. It's
| lagging behind. It's not the last time that a mainstream
| language adopts a feature that has been available for years
| in a more fringe ecosystem.
|
| In practice, I'm sure the most important thing is humans and
| their skill, so mainstreamness matters. But if you can
| somehow be less sensitive to that, you may reap a lot of
| benefit from using Foo before it was cool.
| geodel wrote:
| Another thing to note that cutting edge languages do not
| always deliver great features , they also deliver with
| great frequency half baked features to be discarded or
| deprecated in few years. Also since most effort spent on
| language , tooling remain primitive and slow for long time.
|
| So I do not see them a sure win for projects I work on.
| gugagore wrote:
| Great point about half-baked features. The investment
| boils down to risk-reward. Can we say that the features
| that are introduced into Java at this point are features
| that have stood the test of time in other languages?
| geodel wrote:
| I have already used `records` in some project I work on.
| To me it does not look too clever / funky. It still looks
| like very obvious Java code but little more concise.
| mumblemumble wrote:
| FWIW, I feel that way about Scala, but not F#.
|
| The only big F# feature I know of that's fallen out of
| favor is type providers, and, IMO, that's not because the
| feature was half-baked so much as because it was one of
| the many casualties of .NET's transition to being a truly
| cross-platform toolkit.
| riyadparvez wrote:
| Because Scala is a truly innovative and experimental
| language that came out of a programming language research
| group. That's why there's a lot of features that didn't
| play out well in real-world. F# started out as .NET
| rendition of OCaml. Most languages initiated by large
| crops don't try to be innovative, rather they take
| approaches introduced by different niche languages (many
| of them are only for research purpose) and incorporate to
| their language. Languages that try cater to a large
| audience should be adopting features from experimental
| languages.
| mumblemumble wrote:
| F#'s relationship has been vastly overblown. The truth is
| that they're about as closely related as C# and
| Objective-C. In the same way that the overlap between C#
| and ObjC is basically just the C bit, the overlap between
| F# and and OCaml is basically just the ML bit. (Actually,
| even less than that.) You could say that it was inspired
| by OCaml, but it includes almost none of what makes OCaml
| OCaml, and adds a _lot_ of its own new ideas.
| ragnese wrote:
| To someone who has a passing familiarity with OCaml, but
| none with F#, can you elaborate? Because I do hear the
| comparison frequently.
|
| Do people just draw the comparison because they don't
| actually know of any other ML languages besides OCaml?
| mumblemumble wrote:
| I haven't touched OCaml in a while, but the things it has
| and F# doesn't that I can remember include: Functors (in
| the ML sense), camlp4, polymorphic variant types,
| multiple inheritance, class interfaces.
|
| Things F# has that OCaml lacks: Extension methods, units
| of measure, type providers, quotations, computation
| expressions, active patterns, overloading.
|
| Probably most of the F# things could be (and perhaps have
| been) added to OCaml with camlp4, which is more powerful
| than F#'s quotations. Versus, F# may never be able to
| have all of OCaml's ad-hoc polymorphism features. So
| there's that. But I'm mainly meaning to compare what's
| actually built into the language.
| xwolfi wrote:
| But it's fine, we don't really care about language adoption
| if the best most supported most tested most hiring languages
| swallow their features, right ?
|
| What matters is what we do with the language, more than the
| name of it no?
| mdm12 wrote:
| The problem (as I see it, anyways) is that the 'big boys'
| that I referred to in my initial comment have been around a
| long time (2000 for C#, 1995 for Java) and over that long
| history, have had a slew of language changes. They are
| starting to suffer from the same problem that C++ suffers
| from, where every shop defines their own subset of the
| language with which they use. Meanwhile, the languages that
| they graft features from (e.g., F#) tend to be smaller and
| more coherent with respect to the feature set.
| kaba0 wrote:
| But that's the great thing about java, it is still a
| pretty lean language even with its age.
| [deleted]
| agumonkey wrote:
| Semi sad state of the universe
| dfgdghdf wrote:
| I can only comment on C# / F#.
|
| The C# versions of F# features tend to be pretty clunky
| compared to the F# versions. This is because F# was designed
| for them from the beginning, rather than having them tacked
| on. Functional programming is getting easier in C#, no
| question about that, but honestly, it still kind of sucks.
| And the OOP-minded C# devs on your team still won't be able
| to make sense of your code that leverages all these fancy new
| features anyway.
| adamdusty wrote:
| What fancy features won't we understand?
|
| I think some things about functional programming make code
| feel cleaner, but I don't like it enough to use F# or
| Haskell.
| pjmlp wrote:
| No bother, beyond learning new concepts.
|
| In the end platform languages always take the most relevant
| pieces from the guest languages, which eventually fade away.
| Barrin92 wrote:
| >Why bother investing in the languages with a much smaller
| market share when the big boys adopt good bits and pieces
| from them constantly?
|
| because if you know exactly what you want to do there's no
| reason to settle for the second best thing. If you want F#,
| no harm with going exactly with F#.
|
| I talked to a bunch of Jane Street engineers once and the
| consensus seemed to be that Ocaml, despite its very small
| footprint, actually helped them attract the kind of people
| who were super enthusiastic about building really good stuff
| with a good technology, so it actually made recruiting for
| them easier.
| hota_mazi wrote:
| > actually helped them attract the kind of people who were
| super enthusiastic about building really good stuff with a
| good technology, so it actually made recruiting for them
| easier.
|
| Sounds like a strong case of selection bias.
|
| There is no shortage of people who are super enthusiastic
| about building really good stuff with good technology, and
| it's hard to believe that it's easier to hire Ocaml
| engineers than other languages.
| jjav wrote:
| Agreed. I worked with a team who was heavily into scala
| and one of their beliefs was that all the smartest people
| want to work on scala, thus having the company use scala
| will filter only the smartest people to want to work for
| us.
| Fiveplus wrote:
| Curious how many folks here experimented with the now depreciated
| Ahead-of-Time Compilation feature?
| JCWasmx86 wrote:
| I did experiment with it to improve the startup times of one of
| my applications (Java Swing). The gain was quite small, nearly
| not noticeable.
| _old_dude_ wrote:
| I did, the main issue is that jaotc doesn't do any pruning of
| the unused methods, so it generates too much assembly code. If
| i remember correctly, compiling just guava was to close to 1
| gig.
|
| GraalVM native image is far better, it "compiles" more slowly
| but the resulting executable is not too big.
| meddlepal wrote:
| I think that is by design due to reflection needs. Hard to
| prune unused code when it might be called reflectively at any
| time.
| brabel wrote:
| Which is why GraalVM requires you to explicitly mention
| what types should be available for reflection.
| meddlepal wrote:
| Yea, but that's impractical in a lot of cases where
| frameworks or large libraries are involved.
| brabel wrote:
| There are good frameworks that already work well with
| GraalVM native, including Quarkus and Micronaut. They
| avoid reflection altogether in most cases.
| tannhaeuser wrote:
| Only briefly tested it. I thought RH's Quarkus project made use
| of it, didn't it? What's the post-16 way of Java AOT
| compilation?
| kaba0 wrote:
| Graal is a separate project and jaotc did use that. I believe
| the reason for the "separation" is that the two projects have
| different priorities and didn't develop at the same pace. I
| believe graal is still only at version 11.
|
| But since Java, the language is highly backward compatible,
| one can trivially use Graal as is (without the preview
| features though)
| huodon wrote:
| We use java 100, called kotlin
| haberman wrote:
| Looks like no type aliases still? Does anyone know if type
| aliases are anywhere on the road map for Java? Is there some
| philosophical objection to them?
| noisy_boy wrote:
| Considering how heavily they have borrowed from Scala lately, I
| would have expected them to pick this up. I found them quite
| useful in Scala (and in Golang as well).
| brabel wrote:
| Java is not borrowing from just Scala, it's borrowing from
| all languages and adding its all twists to things, just like
| Scala itself has always done (it's cleary inspired by Java
| itself, ML and Haskell, probably more).
| meddlepal wrote:
| I do not believe they are on the roadmap at all.
| krzyk wrote:
| What are aliases?
| uDontKnowMe wrote:
| As in Scala: // define a type alias
| type UserId = Long // can be used as a regular
| type val userId: UserId = 123L val userIds:
| List[UserId] = List(1L, 2L, 3L)
| avodonosov wrote:
| The language is getting fragmented: value-based classes, records.
| I wish the features were introduced still keeping one kind of
| objects, instead of splitting the universe into 3 kinds of
| objects (usual objects, value-based objects, records).
|
| The feature I am awaiting most is the Project Loom.
| MrBuddyCasino wrote:
| Yeah, same feeling here. The special-casing feels off. They
| must have had very good reasons to do that, I just haven't seen
| them outlined yet.
| papercrane wrote:
| The new object type being promoted from preview feature is
| just the record type. Records are still Objects, they just
| provide a low ceremony way to create an immutable object
| holding some data.
|
| I see these record classes in the same category as enum
| objects, an evolution of the language to improve developer
| ergonomics.
|
| Upcoming is inline-classes (previous called value types.)
| When this happens we'll have a true "special" kind of Object,
| one that does not have any identity. The motivation here is
| mostly performance. The details are available in Brian Goetz
| "State of Valhalla" update https://cr.openjdk.java.net/~brian
| goetz/valhalla/sov/01-back...
| avodonosov wrote:
| Even if `record` is a syntactic sugar, I'd better see a
| canonical constructor added to all usual classes. The
| constructor parameters are of types of all the fields, in
| the declaration order. In this case we could say
| class Point { public final int x, y; }
|
| instead of record Point(int x, int y) { }
|
| Usual non-record classes would benefit greatly from such a
| feature too.
|
| Actually, if class fields have different visibility,
| several canonical constructors are needed. If public fields
| exist, a constructor that sets all public fields. If
| protected fields exist, a constructor that sets all public
| and protected fields. If package-private fields exist -
| setting all public, protected, and package-private fields.
| If private fields exist - setting all public, protected,
| package-private, and private fields.
|
| What remains, is value-oriented versions of equals(),
| hashCode() and toString() to be defined. Probably better to
| express as a base class than the new keyword `record`;
| class Point extends Record { public final int x, y; }
|
| A polyfill for such a base class for older Java:
| import org.apache.commons.lang3.builder.EqualsBuilder;
| import org.apache.commons.lang3.builder.HashCodeBuilder;
| import org.apache.commons.lang3.builder.ToStringBuilder;
| class Record { @Override public int
| hashCode() { return
| HashCodeBuilder.reflectionHashCode(this, true);
| } @Override public boolean
| equals(Object obj) { return
| EqualsBuilder.reflectionEquals(this, obj, true);
| } @Override public String
| toString() { return
| ToStringBuilder.reflectionToString(this); }
| }
|
| I practice such classes in my code, for constructors, I
| just don't bother for final (Java does not support it well
| anyways), and have factory methods in a separate class, so
| they are out of the readers view.
| papercrane wrote:
| Adding a new canonical constructor to all classes would
| very likely have backwards compatibility issues, so we'd
| likely need some sort of opt-in mechanism. In the end the
| language designers decided that they wanted to give
| developers a way to create a very focused kind of object.
|
| This goes into the design motivations:
| https://cr.openjdk.java.net/~briangoetz/amber/datum.html
|
| Additionally, one less talked about benefit of records is
| they have a simplified serialization scheme that is safer
| by default. Records when being deserialized have each of
| their members read and then the canonical constructor is
| called, if the values are not valid then the constructor
| can reject the fields instead of allowing an "impossible"
| object from being created.
| avodonosov wrote:
| The opt-in (or rather opt-out) could be a presence of
| user-defined constructor.
|
| The same way as with default no-arg constructor.
|
| Interesting note about serialization. That could also be
| part of the base class.
| bartvk wrote:
| What's the use of forcing everything to be an object?
| seattle_spring wrote:
| Wow, might be time to finally throw out my copy of Java 6 SCJP
| (Sun Certified Java Programmer)
| tarkin2 wrote:
| Do you think the "Run anywhere" marketing behind Java is rarely
| important?
|
| Java programs normally sit on a server, or many servers of the
| same arch.
|
| The decent thing is that someone can build a JVM for a new
| architecture and lots of /other/ languages that target the JVM
| work.
|
| But this seems different from "my program can runs on lots of
| architectures".
| jacques_chester wrote:
| In the 1990s it looked very much as if desktop and server
| heterogeneity would be the norm. That you'd pick between
| alternatives like Solaris on SPARC, HP-UX on PA-RISC, Irix on
| MIPS, Windows on Alpha / MIPS / x86 / PowerPC, MacOS on
| PowerPC, OS/2 on PowerPC / x86 etc etc.
|
| The designers of Java, as well as software community at large,
| had dealt with the pain of moving large codebases across
| platforms and so the WORA promise was very appealing.
| ObscureScience wrote:
| It would have been cool if Limbo/Dis would had gotten more
| attention at the time. To me it looks like a more promising
| base, and was released the same year as Java. I can't at the
| moment find under what terms it was released back then, but
| it's free software now.
| ObscureScience wrote:
| What's the state of tail call optimization on JVM nowadays?
| yellow_lead wrote:
| Records are a cool highlight for this version.
| https://openjdk.java.net/jeps/395
| setheron wrote:
| I'm actually stoked for jpackage, muslc and the vector API.
|
| Just finished my CPU architecture and enjoying to see the new
| trend to adopt vectors again in the USA
| JCWasmx86 wrote:
| The JEPs/enhancements: http://openjdk.java.net/projects/jdk/16/
| StepWeiwu wrote:
| The page returned a 500 for me, bad omen for Java 16? :)
| JCWasmx86 wrote:
| The site works great for me.
| mooreds wrote:
| Super interested in https://openjdk.java.net/jeps/386 as alpine
| linux is at the heart of a lot of docker images. We use ubuntu
| currently as our base image, but tried to use alpine recently and
| ran into some issues with musl.
|
| Hopefully this version will work better.
| eigenvalue wrote:
| Cool. I love Alpine, it's incredibly fast and lean. It's
| annoying how much software is incompatible with it, so this
| should help with that.
| dkersten wrote:
| I switched to Azul's Zulu[1] build of OpenJDK some time ago
| specifically for Alpine Linux support and its worked great for
| me.
|
| [1] https://www.azul.com/downloads/zulu-community/?package=jdk
| JCWasmx86 wrote:
| I wonder, whether this could be used to compile it for termux.
| (Android)
|
| You can link musl statically. So, the problems with Glibc
| wouldn't be there. Maybe you would have to patch musl to make
| it work on android.
| jjjeii3 wrote:
| Java devs are like: Why bother to develop anything new if we can
| just copycat every single feature from C# without even changing
| their spec a bit...
|
| C# records released last year: record
| Book(string Title, int Id);
|
| New java records: record Book(String title, int
| id)
| [deleted]
| krzyk wrote:
| C# started adding records when Java was already working on
| them.
|
| So if you insist on someone borrowing, it is this time the
| other way around.
| devoutsalsa wrote:
| Sounds like how C# got started :)
| BoyRobot777 wrote:
| I was not aware that Microsoft invented algebraic data type.
| stevetodd wrote:
| By being slightly behind, you get to learn from those languages
| that live on the bleeding edge. The laggards get to benefit
| from all the corner cases found and mistakes committed.
| hasa wrote:
| OMG I'm old. I thought that Java 9 would be next version.
| vmception wrote:
| yeah I'm confused too, so its because Java 9 officially came
| out September 2017 and they've been releasing very fast but
| have completely ditched semantic versioning
|
| chart here https://en.wikipedia.org/wiki/Java_version_history
| Freak_NL wrote:
| Java 8 - Java 11 - Java 17. Those are the LTS releases. If
| you want to follow a release cadence similar to Java 5 - Java
| 6 - Java 7 - Java 8, that's what you'll track.
|
| The intermediate releases can be used to test against, but
| adopting them too soon often means tackling lots of issues in
| your dependencies. And updating your application servers to a
| new major Java version every six months is not something you
| can do easily coming from older Java versions. It's not
| impossible, but it may require a different deployment
| strategy and may not benefit you much over going from LTS to
| LTS.
|
| I think that there is also an unspoken feeling that the LTS
| releases are more stable, which again may be due to the
| libraries you depend on not always being as well tested on
| the intermediate releases. I think a lot of Java developers
| burned their fingers on Java 9 and 10 and are now sticking to
| the LTS releases, but that is just my gut-feeling.
| KptMarchewa wrote:
| If you're using "application servers" and not containers
| then definitely do not touch intermediate releases.
| krzyk wrote:
| Why?
|
| I would say, try it out and see.
| signal11 wrote:
| Note that blindly following LTS is not a great idea for
| many teams that deploy applications (as opposed to
| libraries), including teams working in large companies, if
| you have access to modern CI/CD tooling. Personally, I'd
| let production stay a little behind the latest release but
| always run a task on my build server to build and test my
| code on the latest JRE.
|
| If you read Ron Pressler's comment on Reddit[1], the
| recommendation is
|
| > In any event, the default position should be to keep up
| with the current JDK as much as possible (it's OK to skip a
| version or two), and consider LTS only if there is some
| specific difficulty preventing you from doing so. As I said
| before, the "current JDK" upgrade path is designed to be
| the one that is overall the cheapest and easiest for the
| vast majority of users -- easier and cheaper than the old
| model.
|
| For users who are happy with the current JDK language
| level, newer releases also have JRE improvements:
|
| > ...those users should [also] prefer the current JDK, too,
| as that is the easiest, cheapest update path. Also, new
| feature releases contain performance and monitoring
| improvements (e.g. JFR, ZGC, AppCDS in the last few
| releases) that may be of interest even when users are not
| interested in new language/library features.
|
| > The problem with LTS is that it's costly (costlier than
| the old model): on the one hand, the risk of a breaking
| change in an LTS patch is no lower than in a feature
| release, and on the other hand, the patches no longer
| contain many gradual implementation features (that you use
| without knowing). In addition, the OpenJDK development
| process revolves around feature releases without regard for
| LTS, so features can be removed without notice in an LTS
| release. This makes an LTS->LTS upgrade more costly than in
| the old model.
|
| > LTS is designed and is advisable for companies that
| prefer a costly, but well-planned, three-yearly upgrade
| process.
|
| > Even if you've carefully considered the options and
| decided that LTS is the right approach for you, you are
| strongly advised to test your app against the current JDK
| release to reduce the cost of an LTS->LTS upgrade.
|
| > It's true that upgrading from 8 to post-9 can be non-
| trivial (9 was the last ever major release), but once you
| do that, you have an update path that ensures you'll not
| have a major upgrade ever again.
|
| Java upgrades inside enterprises cost time and money, no
| sense in taking that cost if you can help it, and many
| engineering teams with good DevOps can easily dodge this
| cost.
|
| [1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopen
| jdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/ad
| optopenjdk_i...
| krzyk wrote:
| Not quite.
|
| LTS doesn't mean anything if you mention just the Java
| versions.
|
| This is not e.g. Ubuntu LTS.
|
| In java you have different vendors that provide LTS and you
| need to pay for it.
|
| Oracle, Redhat, etc. provide LTS versions (and those happen
| to be 8, 11, but don't have to be).
|
| And there is one more sortof LTS: latest java version,
| because it always gets all the security and other bugfixes.
| Right now it is Java 16.
| namibj wrote:
| OpenJDK's supported/not-supported classification seems to
| match and would appear far more reasonable.
| yjftsjthsd-h wrote:
| I struggle to imagine any meaningful definition for LTS
| that includes "tracking latest" except by coincidence
| (during the window of time when the most recent release
| is an LTS release).
| meddlepal wrote:
| If you're doing green field JVM developer and NOT using big
| frameworks like Spring or an app server it is pretty safe
| to use the intermediate releases.
| paulirwin wrote:
| ... if you're willing and able to update your entire app
| to a new JDK the month it comes out.
|
| This is where I hope Java adopts the .NET support
| lifecycle. .NET also has (relatively) fast-paced releases
| now, once per year with LTS every other year, but the
| prior non-LTS is supported for 3 months after the next
| one comes out. That's still pretty aggressive, but it's
| very doable with a modern app to upgrade within 3 months.
|
| With Java, JDK 15 support ends _this month_ , the same
| month that JDK 16 comes out. Not just that, but we're
| halfway through the month already. So if you're on JDK
| 15, you now have only two weeks to upgrade and still be
| supported, according to their official schedule.
|
| https://www.oracle.com/java/technologies/java-se-support-
| roa...
|
| Edit: I may have been too generous in my reading of their
| support roadmap. It seems like the previous non-LTS
| version is immediately out of support as soon as the new
| one "supersedes" it.
| croo wrote:
| Uh, probably just my narrow corporate world view but...
| is there any serious development in java NOT using
| Spring?
|
| Time for me to learn so let me rephrase this question!
| Those who use java without EE or Spring framework, what
| are your go-to libraries? What are you using for DI /
| REST / ORM / Auth etc?
| signal11 wrote:
| > is there any serious development in java NOT using
| Spring?
|
| Yes. And I don't just mean people doing Android
| development.
|
| 1) DI: Don't always need DI. For things like injecting
| values from config, it's really unnecessary given that we
| have very good control over production, down to building
| our boxes from a playbook. For things like mocks, plain
| old Java suffices -- you can roll your own (actually,
| someone in your team just needs to do it once and it
| keeps getting improved/forked). Guice exists as a
| fallback.
|
| 2) REST: Jersey + own libraries on top, Retrofit. Using
| Spring for REST is probably the poorest use for Spring,
| for me.
|
| 3) ORM: you can use "just" JPA. Don't always need an ORM
| either -- the strategy varies depending on the
| requirement. Although for some projects I have used
| Spring Data JPA because it seemed like the easiest path.
| At least Spring was localized to that artifact.
|
| 4) Lots of good OAuth2 libraries as well as things like
| pac4j. If you're wondering about Spring Security, it's
| definitely one to consider if you're doing lots of
| webapps in Java. But in a polyglot environment, a lot of
| Java code just handles APIs while node handles the UI.
|
| Anyhow, this isn't to hate on Spring or anything -- I use
| it if it adds value. This is more about not taking the
| the complexity hit if you can help it. It also makes the
| code a bit more straightforward and readable.
| [deleted]
| krzyk wrote:
| Spring supported each and every java release between 9
| and 16. With one release being supported a month later
| (don't remember which).
|
| I know because I use Spring (and hibernate) and
| everything just works.
|
| (If you are on the most recent Spring version)
| meddlepal wrote:
| Basically there's six month feature releases but every five
| or six releases there's going to be an LTS release. Most
| companies use the LTS releases. Next big LTS release is later
| this year.
| krzyk wrote:
| If you mention LTS you have to mention also vendor that
| provides it.
|
| Without it the only LTS is current java version: 16 right
| now and 17 in 6 months.
| meddlepal wrote:
| Huh? There's like several LTS vendors: Oracle, Amazon,
| and Azul to name a few.
| looperhacks wrote:
| LTS stands for long term support. Nobody provides that
| for java 16
| deepGem wrote:
| Java adoption has now reached the release_version / 2 parity :)
| JulianMorrison wrote:
| Still on Java 8 at work :-/
| dehrmann wrote:
| For those who have upgraded, I assume Jigsaw is the main
| concern?
| stonemetal12 wrote:
| Amazon's version or the for a while now EOL Oracle version?
| Maybe push to upgrade to something supported :)
| JulianMorrison wrote:
| A mad scramble to switch to OpenJDK before the Oracle license
| becomes inconvenient.
| bartvk wrote:
| What's the reason for that?
| EdwardDiego wrote:
| I've been using Maven and Gradle's toolchains functionality to
| move individual apps to Java >8 without breaking the legacy
| apps, works pretty well.
| BoyRobot777 wrote:
| Every thread about new Java version has the same comment all
| the time. Why share it? What kind of response do you seek?
| matsemann wrote:
| I think it's interesting to discuss how many are stuck on
| java8. It was a long time many of us were stuck on java6 or
| 7, and finally got up to java8. But then when 9, 10 and 11
| came no one made an effort to upgrade. Why? And now we're at
| 15 and people are starting to feel the heat.
|
| We only migrated our main service from 8 to 15 a month ago
| (AWS deprecation), but still have lots of 8 code laying
| around (luckily some of the container-features were
| backported)
| JulianMorrison wrote:
| Speaking from personal experience, the creators of most of
| the recent JDK versions have made very poor efforts to
| explain the changes, it's mostly just a list of RFC type
| documents, and who has time?
|
| An example of something that compares favourably would be
| Go, where they always blog about the changes, and there's
| easy to find official language documentation (and not just
| autogenerated API docs).
| kaba0 wrote:
| Have you tried for example the linked article with all
| the JEPs listed with lengthy descriptions? And with links
| to relevant mailing lists if it didn't satisfy your
| curiosity?
| cesarb wrote:
| > I think it's interesting to discuss how many are stuck on
| java8. [...] But then when 9, 10 and 11 came no one made an
| effort to upgrade. Why?
|
| A lot of things broke in Java 9, which was short-lived
| (both it and Java 10 lasted only six months each), and then
| Java 11 broke many other things (for instance, it removed
| all of J2EE). As late as last year, I was _still_ seeing
| changes in libraries to fix issues with Java 9 or later. It
| 's not that no one made an effort to upgrade, it's that it
| was a lot of effort, and often required upgrading to later
| versions of libraries, which have their own breaking
| changes.
| vips7L wrote:
| In my experience mst of these changes are simple to add
| to your projects pom or build.gradle. For instance the
| removal of the jaxb xml runtime is a simple 1 liner to
| your project: runtimeOnly
| 'org.glassfish.jaxb:jaxb-runtime:2.3.2'
| cferr wrote:
| Eight's JVM still ships with Minecraft, so that's not
| necessarily a bad thing. It's battle-proven.
| randomopining wrote:
| 8 is still "modern" Java right? 11 didn't add a ton ton for
| most developers.
| brabel wrote:
| I'd say that now with 15 adding records and instanceof
| pattern, Java 8 is finally looking pretty dated!
|
| You're also missing out on var and switch expressions, which
| are very visible features (as are records and instanceof
| patterns), so the difference should be obvious between a Java
| 8 codebase and a Java 15 one.
| randomopining wrote:
| Var and switch were the biggest from Java 11, along with
| modules and the new GCs?
| BoyRobot777 wrote:
| I very much like text blocks as well. SQL/JSON can be
| finally understandable without all the "\n" +
| aogl wrote:
| At a bank, and yes, us too!
| dangerboysteve wrote:
| I recommend the "inside Java" podcast. Its from the java
| developer team at Oracle and worth a listen.
|
| https://inside.java/podcast/#:~:text=The%20Inside%20Java%20P...!
| myroon5 wrote:
| their blog post as well: https://inside.java/2021/03/16/the-
| arrival-of-java16/
| chronogram wrote:
| Thanks. Was a good show, though nothing super informative.
| skepticmoron1 wrote:
| Java 16 for what? Does anybody really use > 8 in production?
| krzyk wrote:
| Who still uses Java 8 in production? That is a serious risk. I
| thought everyone moved to 11 already.
|
| I use Java 15 in production in 3 projects.
| _-david-_ wrote:
| I am pretty sure Red Hat, IBM, and probably other enterprisey
| type companies backport security patches for Java 8.
| aogl wrote:
| We're still on 8 at <bank>
| noisy_boy wrote:
| Tons of folks in financial IT are on 8 - it is pretty stable
| and very common target for most of the libraries being used.
| simple_phrases wrote:
| It's been a while since I've worked with Java, but I'm surprised
| and kind of disappointed at the level of callbacks in the example
| code from the OP.
| abnercoimbre wrote:
| Interesting. Readibility? Performance cost? Would be nice if
| you could expand.
| whalesalad wrote:
| I love the Java website. Strong early-2000s vibes. Still has an
| XHTML doctype!
| btown wrote:
| And now a 500 database error too!
| fulafel wrote:
| Wonder what database they are using.
| whalesalad wrote:
| period correct? mysql 5.1
| Cthulhu_ wrote:
| Oh no it was Oracle before Oracle bought MySQL, so it's
| gotta be Oracle db.
| tragomaskhalos wrote:
| It's probably Postgres on an interim basis, until an army
| of finance dweebs have calculated the internal licensing
| cost of using Oracle :)
| throwaway4good wrote:
| There is an nginx in front of it. What was wrong with Apache?
| Spivak wrote:
| Apache feels like a forgotten gem in the ops world.
| Everyone moved onto Nginx and at some point will run into
| some use-case that needs a feature that's only in Nginx+.
| And since Nginx+ is so expensive people end up just
| patching the OSS Nginx with the modules they need. But that
| whole time Apache was there with every conceivable battery
| and feature already included.
| [deleted]
| [deleted]
| winrid wrote:
| The "event loop" model in Nginx beat Apache performance
| wise.
| ptx wrote:
| Apache has since added support for the event-based model:
| https://httpd.apache.org/docs/2.4/mod/event.html
| krzyk wrote:
| And is readable without javascript. Love such pages.
| java-man wrote:
| Why they decided to change the keyword rules to use "non-sealed"
| is beyond me. Surely, there might be other choices?
| Closed/unclosed? Unsealed?
| Erlangen wrote:
| It's the same story in C++, co_await, co_yield. The sole
| purpose is not to break other people's code.
| bartvk wrote:
| Whenever Swift adds a new keyword, they just add it and break
| everyone's code. They do provide migration tools in Xcode
| though.
| gpderetta wrote:
| co_await is so bad that co_ _X_ has become a running joke in
| the C++ community.
| kccqzy wrote:
| C++ has had two-word keywords since the beginning,
| static_cast, dynamic_cast, etc.
|
| What I truly don't like is C's propensity to add new keywords
| that begin with an underscore and an uppercase letter. Like
| _Bool, or _Atomic. (I know the rationale, these can't be used
| as identifiers due to UB, but it still looks weird to me.)
| m45t3r wrote:
| I think non_sealed would be better than non-sealed though,
| because AFAIK there used to be no identifiers with hifen
| before.
| nikanj wrote:
| Oracle had no qualms about breaking a metric boatload of code
| by shutting down the old sun.* APIs. Their justification was
| "You were not supposed to use these internal tools", but the
| reality of the matter is that migrating to a new Java version
| took lots of code rework.
|
| I'm surprised they were so shy to break code by introducing new
| keywords, after they wreaked havoc on people's codebases with
| removing sun.misc.BASE64Decoder etc
| JCWasmx86 wrote:
| Yes. It feels out-of-place. All other keywords are like one
| word: enum, class, public, protected, native, sealed, ...
|
| But looks entirely different: Two words, connected by a hyphen.
|
| But I think, it was done because of backwards compatibility. If
| they would have called it "closed", it would maybe break
| hundreds of programs that have methods/variables called
| "closed"
| Jabbles wrote:
| Surely migrating variables named "unsealed" would be fairly
| trivial?
| hugi wrote:
| There was a lot of discussion about this and they eventually
| settled on the hyphen. Consider this our introduction to
| hyphenated keywords and expect to see a lot more of them in
| the future.
| Macha wrote:
| I made this argument before, but was informed that they have
| support for contextually distinguishing between names and
| keywords some time between Java 8 and 10. So while e.g. the
| introduction of enum did cause all these issues for variables
| named enum, "var" did not and a hypothetical "closed" would
| not.
| mdaniel wrote:
| There are plenty of languages which have contextually
| sensitive keywords for that exact reason. C# (a closer peer
| to Java syntactically) has contextual keywords including
| "var" and "notnull": https://docs.microsoft.com/en-
| us/dotnet/csharp/language-refe...
| BoyRobot777 wrote:
| There was a lengthy discussion some time ago[0]. Quote:
|
| #### Why not "just" make contextual keywords?
|
| At first glance, contextual keywords (and their friends, such
| as reserved type identifiers) may appear to be a magic wand;
| they let us create the illusion of adding new keywords
| without breaking existing programs. But the positive track
| record of contextual keywords hides a great deal of
| complexity and distortion.
|
| Each grammar position is its own story; contextual keywords
| that might be used as modifiers (e.g., `readonly`) have
| different ambiguity considerations than those that might be
| use in code (e.g., a `matches` expression). The process of
| selecting a contextual keyword is not a simple matter of
| adding it to the grammar; each one requires an analysis of
| potential current and future interactions. Similarly, each
| token we try to repurpose may have its own special
| considerations; for example, we could justify the use of
| `var` as a reserved type name because because the naming
| conventions are so broadly adhered to. Finally, the use of
| contextual keywords in certain syntactic positions can create
| additional considerations for extending the syntax later.
|
| Contextual keywords create complexity for specifications,
| compilers, and IDEs. With one or two special cases, we can
| often deal well enough, but if special cases were to become
| more pervasive, this would likely result in more significant
| maintenance costs or bug tail. While it is easy to dismiss
| this as "not my problem", in reality, this is everybody's
| problem. IDEs often have to guess whether a use of a
| contextual keyword is a keyword or identifier, and it may not
| have enough information to make a good guess until it's seen
| more input. This results in worse user highlighting, auto-
| completion, and refactoring abilities -- or worse. These
| problems quickly become everyone's problems.
|
| So, while contextual keywords are one of the tools in our
| toolbox, they should also be used sparingly.
|
| [0]. https://mail.openjdk.java.net/pipermail/amber-spec-
| experts/2...
| elygre wrote:
| Following the various openjdk mailing lists is an awesome way
| of learning about all the considerations that go into making
| language choices for java. And indeed this was not random, but
| the result of a lot thinking (as shown in a another sibling
| post).
| tmp7oaje wrote:
| As a student most of the way through a Java course, I'm wondering
| what Java is still used for. Java applets are dead, Android is
| moving on to Kotlin (apparently Google got in legal trouble with
| Oracle even though Java is "open source?"), and I can't think of
| any desktop applications that use Java anymore. Java is supposed
| to be able to "run anywhere," yet C++ is more portable because it
| doesn't require the JVM to run.
|
| Yet clearly I'm mistaken, since Java is still one of the most
| popular languages.
|
| Edit: also please help me understand - do I have to pay for a
| license even though Java is open source? Is this normal for other
| languages too?
| MeinBlutIstBlau wrote:
| Literally every business that adopted it back in the 90s. Like
| all of insurance.
| drdrey wrote:
| Look into Spring Boot for cloud applications, it's a big
| ecosystem
| cesarb wrote:
| > and I can't think of any desktop applications that use Java
| anymore.
|
| The desktop application everyone has to use to report the
| income tax in my country is written in Java. Which is nice
| since it runs anywhere that has a recent enough JRE; in a
| distant past, before it was rewritten in Java, it was first a
| DOS-only and then a Windows-only desktop application.
| stevehiehn wrote:
| All jetbrains IDEs are JAVA. Webstorm, Intellij etc
| ksec wrote:
| Vast majority ( if not _All_ ) of Fortune Global 2000 use Java
| as their Main Programming Language for their BackEnd.
|
| And this isn't changing anytime soon. Their initial investment,
| continue investment and Java Ecosystem itself are still
| marching forward. I dont see _any_ language ecosystem that
| could match or challenge Java any time soon. Remember you only
| see Java Haters on HN and Reddit. In the Real World it is all
| about Business Values Delivered and Get Shit _Done_.
|
| JVM in itself is a monster with State of the Art GC and JIT.
|
| All of the above means there is a positive feedback loop into
| making Java better. And there are things that were in the work
| for 10 years ( Like GraalVM ) before hitting mainstream. And
| many more to come.
| krzyk wrote:
| E. g. Backend services for webapps or HFT.
| fma wrote:
| I'll give you a bit of advice I give to engineers I mentor. Go
| to a tech jobs site like dice.com, and put in a technology
| you're curious about. So, put in java for your zip code. See
| what jobs are available. Are they back end? desktop? Then
| you'll find out where java (and any other tech) is used, and
| how popular it is. For example, how many jobs are there for PHP
| compared to Java?
|
| I'm not saying you should adapt a technology based solely on
| the number of jobs...but we all gotta eat. And on the flip side
| if you see Java jobs decline over the years...time to learn the
| one that's increasing :)
| lilactown wrote:
| Other languages have started to eat into Java's market share,
| but coincidentally a lot of them run on the same host VM as
| Java. For instance, Kotlin, Scala and Clojure are more and more
| frequently seen in backend, web and mobile development.
|
| These languages are definitely much more "portable" depending
| on what your definition of portability is; the JRE runs on A
| LOT of systems and abstracts much of the underlying system away
| for you, meaning that IME you have to write a lot less
| platform-specific code if you're targeting e.g. Windows, macOS
| and Linux.
|
| As for your edit, the licensing is a bit complex for Java but
| TL;DR if you install OpenJDK releases you do not need to worry
| yourself about licensing.
| shp0ngle wrote:
| Java is used a LOT on the back-end still.
|
| Yes, golang is shiny new thing, but there is TONS of boring
| back-end done in Java.
|
| Whole Alibaba runs on Java, for example. I know of some
| companies (won't share names but fill in the blanks) that used
| to be Go shops, that were eaten by Alibaba and they migrated
| from Go to Java.
| Maphistow wrote:
| Wouldn't agree on the GO statement, yes GO is great in terms
| of performance but it still lacks some important language
| features AFAIK no generics, no proper exception handling. I
| honestly don't know how the GO ecosystem is, but I can't
| imagine it's as mature as java. Perhaps I'm wrong tho
| shp0ngle wrote:
| I've removed that part of the post as I don't want to make
| this about go :)
| geodel wrote:
| > no proper exception handling.
|
| That's just like saying Go does not have application
| servers, DI, IOC, ORM frameworks, runtime reflection and so
| on. Different languages have different ways of achieving
| user requirements. It is not one-to-one matching.
|
| > ... I can't imagine it's as mature as java.
|
| Yes, depending on perspective, not as mature or not as
| fossilized as Java.
| sparsely wrote:
| Java is used all over the place for various backend
| applications, e.g. data processing, web backends. It's fast,
| well documented and has a great standard library and ecosystem.
| In many of these applications you control the deployment
| environment, so making sure that your container has the JVM
| isn't an issue.
| azatris wrote:
| We use it on servicing the backend of an e-commerce website.
| The code is now 2 decades old and wonderfully refactorable to
| modern code.
| enw wrote:
| I'm assuming Amazon? Most of Amazon runs on Java.
| therealdrag0 wrote:
| To give you some more details of how Java can be used in the
| backend, while there's obviously unknown "generic business
| logic" there's also big name infrastructure pieces you can look
| up:
|
| - https://en.wikipedia.org/wiki/Apache_Hadoop
|
| - https://en.wikipedia.org/wiki/Apache_Kafka
|
| - https://en.wikipedia.org/wiki/Apache_Cassandra
|
| - https://en.wikipedia.org/wiki/Apache_Lucene
|
| - https://en.wikipedia.org/wiki/Elasticsearch
|
| - https://en.wikipedia.org/wiki/Apache_ZooKeeper
|
| - https://en.wikipedia.org/wiki/Apache_ActiveMQ
| [deleted]
| dehrmann wrote:
| > still
|
| It's a very popular backend language. Ironically, "run
| anywhere" isn't much of a requirement for backend development.
|
| > C++ is more portable because it doesn't require the JVM to
| run.
|
| For backend development, this isn't much of an issue either
| way. These days, the main advantages C++ has to Java is startup
| time and no GC pauses.
|
| It's also not as portable as you'd think. Take a look at cross-
| platform C/C++ projects and you'll see a lot of special cases
| for particular platforms.
|
| Java's popularity mostly boils down to it's mature, has a large
| ecosystem, and is adequate for a lot of things. Unless you're
| writing an iPhone app or system-level code, it's unlikely to be
| a bad choice.
| watwut wrote:
| There are no GC pauses issues practically now and for years.
| Language startup is also not all that much issue.
| vbezhenar wrote:
| > Ironically, "run anywhere" isn't much of a requirement for
| backend development.
|
| If you're using Java, you can develop on macOS, deploy on
| Windows Server, then switch to Linux on AWS Graviton and M1
| Macbook. Without a singe recompilation.
| ssijak wrote:
| With graal vm java apps compiled to native have amost 0
| startup time
| hota_mazi wrote:
| Except for "Java applets are dead", everything else you wrote
| is wrong :-)
|
| Android is not moving to Kotlin: Kotlin is simply supported as
| a first class language in Android. Most of Android itself is
| written in Java and while it's clear that an increasing number
| of Android developers are switching to Kotlin, Java will never
| stop being supported on Android.
|
| The legal battle between Google and Oracle has nothing to with
| Google using Java.
|
| You can use Java for free and without any licensing concerns
| (use Open JDK).
|
| C++ is _less_ portable than Java precisely because Java runs on
| a JVM.
| vbezhenar wrote:
| > do I have to pay for a license even though Java is open
| source?
|
| Most people use free OpenJDK builds (Adopt OpenJDK, Zulu
| OpenJDK, Oracle OpenJDK to name a few). There are some builds
| which require license, like Oracle Java. If you need some kind
| of advanced support, you have that option.
| dpatriarche wrote:
| Java is not commonly used for _consumer_ desktop applications,
| where it often is necessary /desirable to invest in fully
| native apps for Windows and MacOS. But desktop Java is quite
| common in business desktop applications, for example, medical
| devices (like radiology image viewers).
| xwolfi wrote:
| I work on the trading floor of an investment bank in Hong Kong.
| Our OMS is made entirely in low latency Java (no GC, lots of
| perf test, few C++ binding when really we must).
|
| Java allows us, contrary to our poor colleagues in algo still
| on C++ to work in team, manage dependency, use really good
| tooling, unit test easily, have libraries that work
| consistently all across the universe (that's a beef I have with
| Python: every library seems to work differently with different
| casing and principles so I have to read enormous doc all the
| time bleh). It compiles fast enough, every monkey joining has
| done enough Java at university to get started, and it prunes
| all the autists who love complex one-liners and attract people
| more into team work and well-organized simple stuff. As for
| profiling, I still have to meet a C++ colleague with a good
| efficient profiler in my company, while us monkeys in Java (C#
| is great too tbh) can just run a graphical profiler, click on 3
| buttons, and find what's not optimal.
|
| Java isn't a language for the elite. And while the elite
| crashes the system and lose millions in 30 minutes, us
| dumbasses in Java can build and release with good tools without
| using bin patches that remove critical features :)
|
| You'll see when you start working. Every company is a shitshow,
| better be in a Java shitshow with slow idiots than in a C++
| shitshow with autist geniuses :D
|
| You don't have to pay a license, but it's starting to get
| blurry. My giant company is phasing out Oracle's JVM and moving
| to OpenJDK, so there's that...
| eganist wrote:
| > better be in a Java shitshow with slow idiots than in a C++
| shitshow with autist geniuses :D
|
| Please don't use Autism as an insult. It's exceptionally
| degrading to conversation here and presents no value; it does
| nothing other than cast you in a negative light.
|
| I'll ~delete~ edit my comment if you edit the remark out,
| provided you do so before my ~delete~ edit threshold expires.
|
| Edit: delete threshold expired. Can only edit, and won't be
| able to edit once the edit threshold expires.
| anaganisk wrote:
| Op is probably here from wallstreetbets
| victor106 wrote:
| > Our OMS is made entirely in low latency Java (no GC, lots
| of perf test, few C++ binding when really we must)
|
| Any resources on how to do this?
| wealthyyy wrote:
| Zero-GC Java looks lot of like Ancient C++ and in that case
| Modern C++ is far better because of RAII.
|
| Most of perf profilers are horrible in HFT scene. You need to
| measure from processor level with Intel VTune.
|
| #include <iostream> #include <string>
|
| int main() { std::cout << "C++ is not for elites << "\n"; }
| wealthyyy wrote:
| A lot of Universities teaches Ancient C++ and developers
| start to hate it. The rant of Linus also caused huge disaster
| newcomers coming into C++ and that shifted people into Rust.
| majjgepolja wrote:
| > and that shifted people into Rust
|
| Millennials be like
| majjgepolja wrote:
| > better be in a Java shitshow with slow idiots than in a C++
| shitshow with autist geniuses :D
|
| It's autist geniuses that built the world when slow idiots
| were manually doing everything.
| Bumkatio wrote:
| I have worked with Java EE (Enterprise Edition) for a few
| years. Java in the backend is probably the most common one when
| doing enterprise software.
|
| Lets define it differently: Everything what is not an SAP
| System and is backend and is not Cobolt, is Java at least for
| automotive and banking. Automotive -> managing cars, service
| contracts, financing offers, accessories and for banking ->
| money management, insurance, contract management etc. You go to
| a shop and you wanna finance something? Might be a Java backend
| or Cobolt :D)
|
| Spring/Spring Boot as a Framework got a lot of traction because
| Java specification process was just way slower and more
| boilerplate
|
| And yes Oracle got fed up of doing Java for free for too long
| and if you wanna use an older version of java and still need
| patches, you will need to pay.
|
| Luckily there is were java actually shows it strength which i
| have not seen in other languages: You define a specification,
| you get a reference implementation from someone and then
| everyone around it starts to build on those specifications.
|
| This allows for different jpa (database access with java)
| implementations, different application server etc. It also
| allows for different companies to do their own JVM
| implementation/maintenance track/version.
|
| From an ecosystem pserpective, the JVM itself (without java)
| also did a great job and shows how versatile it is. Close to
| what .net is doing but in a more free version. And you could
| throw .net/c# into the same similiar category as Java. Language
| feels similiar and if you are a MS company, you just use C#
| perhaps. But switching between c# and java is much easier than
| to other languages.
|
| From all languages i know and worked with, i do like JVM based
| languages the most. golang is interesting but nothing i would
| wanna use for a big code base at all. C/C++ i would use if i
| need to because of tooling features, how you write it and how
| hard it is to write it good;
|
| Java is fast, java has great tools for a long long time: Great
| Debugging features, great memory and performance analysis and
| tools, lots and lots of frameworks and architecture catalog.
|
| PHP is written and used in business context like java but
| without the benefits of running on the JVM. I don't recommend
| it. Its not bad, its less boiler plate but its just not a nice
| well defined well designed language. Most shocking to me was
| the performance optimizations which were done a few years ago
| which shows how little interest in that language exists that
| you can just optimize it that much. What facebook did with PHP
| was just shitty and weird.
| nomercy400 wrote:
| Most OpenJDK implementations do not require a license.
|
| There are multiple implementations of the Java VM. Java is
| designed by a collaboration of companies and OpenJDK is the
| reference implementation. Based on the license of the company,
| its implementation is free or not.
|
| Now, Oracle was the biggest and most well known contributor of
| OpenJDK for a long time (and probably still is). And Oracle did
| something unusual, which is that they made their own version no
| longer free. Which is why you are confused. You can still get
| Java from Oracle, with Long Term Support, but now it is paid
| support.
|
| The OpenJDK reference implementation is still free, and many
| companies have made their own tweaks and provide Long Term
| Support for these versions, mostly because they use tons of
| Java and/or want others to keep using Java because of its
| massive ecosystem, for which they can provide consulting/paid
| support. Note, you can still run these versions commercially,
| but if you want support you likely have to pay.
|
| The Google issue was that before all this OpenJDK stuff, all
| designing of Java was done by a single company, Sun, which was
| bought by Oracle. So a single company designed, developed,
| implemented, maintained, and built up the ecosystem of Java.
| This includes years of R&D in what keywords to use, and how
| classes work, basically the rules of the language. Tons of
| developers got into Java. And they attracted big customers like
| banks and governments to pay them for this R&D with support and
| development. Then came Google and they said, we like this
| language design and ecosystem and developer skills, but we
| don't want to pay for that support, so thanks for all the hard
| designing of your language, but we will create our own
| implementation and pay you nothing. Basically Google didn't
| want to pay it's share of the Java R&D. Now things get a bit
| blurry because of Oracle, which bought Sun, and tried to make a
| lot more money off Java while reducing R&D spending. So Oracle
| isn't too popular either.
|
| Things have improved since Oracle decided that Java isn't
| something to make a lot of money off, and the whole Google
| debacle. Now Oracle is mostly stewarding the language and other
| companies are now also contributing features. The past few
| years there have been some good and strong updates to Java,
| making it feel more like a leading language than a trailing
| language.
|
| Basically, get AdoptOpenJDK, latest version if possible, and
| don't use preview features.
| noisy_boy wrote:
| Java is _very_ prevalent in Financial IT - almost everywhere.
| C++ is probably the only language in the same league in terms
| of usage. I have also seen C# lately in bunch of places but
| mostly middle-office/back-office.
| hdctambien wrote:
| > C++ is more portable because it doesn't require the JVM to
| run
|
| Java is portable BECAUSE of the JVM. If a new computer
| architecture hits the scene, once someone writes a JVM for it
| your .class files will run on it (probably).
|
| Your C++ program, however, will definitely not run and you'll
| need to recompile it with a compiler that targets that new
| architecture.
|
| The same compiled Java code will(should) run on a Mac or a PC
| or any Linux box, but you need a different executable for each
| target with a C++ program.
|
| The JVM isn't portable. That needs to be recompiled for each
| new target, but your Java .class files are portable.
| AlotOfReading wrote:
| For a couple decades, x86 was absolutely dominant and there
| were no new architectures of any importance outside specific
| niches. Once you dealt with the OS specific oddities (which
| java also helped with), C++ was highly portable.
| jacques_chester wrote:
| > _For a couple decades, x86 was absolutely dominant_
|
| On the desktop and servers, maybe. But there is more in
| heaven and embedded than is dreamt of in your philosophy.
| kllrnohj wrote:
| > but your Java .class files are portable.
|
| No, they aren't, they regularly have non-portable
| dependencies or assumptions about the environment.
|
| For example, it's more or less impossible to write a Java
| program that runs on Windows, Android, and iOS - the 3 most
| popular OS's. You have completely different UI support
| between Windows & Android, and there's not really any JVM for
| iOS (there's AOT, but now you're not even pretending to run a
| .class file)
|
| So to make a "portable Java" program you're already stuck
| compiling it 3 times for the 3 major OS platforms, but
| without anything helping you to actually specialize for a
| platform like exists with C++. Making Java less portable in
| practice than C++.
|
| Toss in that other popular platform, web, and the
| "portability" of Java gets even worse compared to others like
| C++.
| hota_mazi wrote:
| > For example, it's more or less impossible to write a Java
| program that runs on Windows, Android, and iOS
|
| Not only is it possible, it happens all the time.
|
| The entire Maven Central repository, which contains tens of
| thousands of JVM libraries, is usable on all the platforms
| you just listed.
|
| If that's not portability, I don't know what is.
| kllrnohj wrote:
| Maven runs on 1 out of the 4 mentioned platforms. There
| are no Android, iOS, or web builds of Maven.
|
| Maven is used to ship dependences for the other
| platforms, but it is not run itself on those other
| platforms. Shipping an Android-specific library on Maven
| isn't magically portable (which is what's common here -
| OS-specific libraries on Maven). It's still Android-
| specific.
| hota_mazi wrote:
| All Android builds use Gradle and download their
| dependencies from Maven Central.
|
| I have no idea what you're talking about.
|
| Let me repeat this: all Windows, macOS, Linux, and
| Android apps that use Maven or Gradle to build ALL
| download their dependencies from Maven Central. These are
| the very same libraries, same bytecode.
|
| For example, do you use Mockito? You will download that
| exact same library from Maven Central regardless of the
| platform you are building on.
| kllrnohj wrote:
| When you build Android you're not building it _on_
| Android, you 're building it on Windows, MacOS, or Linux.
| Maven itself is not being run on Android or iOS.
|
| The Java code that powers Maven isn't portable. The
| AndroidX code hosted on Maven that everyone is pulling
| down for Android isn't portable, either.
|
| Your claim would be like saying that PHP is portable
| because every platform has a web browser that can talk to
| the server running modphp. That's not what portability
| means.
|
| > For example, do you use Mockito? You will download that
| exact same library from Maven Central regardless of the
| platform you are building on.
|
| Mockito only runs on 2 of the 4 platforms (doesn't run on
| iOS or web).
| hota_mazi wrote:
| Who cares about Maven-the-app, we are talking about the
| portability of the JVM bytecode.
|
| There are gigs of JVM bytecodes stored on Maven Central
| and these bytecodes are being downloaded and run on
| macOS, Windows, Linux, and Android on a daily basis
| without a single change. The very same libraries.
| Unchanged.
|
| That's the very definition of portability.
|
| I don't understand why you keep shifting topics by
| bringing up irrelevant observations.
| ptx wrote:
| Any libraries in the Maven repos that rely on JNI have to
| include platform-specific native libraries for each
| platform. For example, anything that uses Unix-domain
| sockets, which weren't supported in Java until this very
| release.
| kllrnohj wrote:
| There's no portability requirement to being on Maven
| Central. Maven Central regularly hosts non-portable
| bytecode - like every AndroidX library.
|
| And, again, none of those libraries run on Windows,
| Android, iOS, and web - the 4 major platforms by market
| share. At best you get half of those, but typically you
| don't even get that, and that's still only _libraries_.
| None of them are portable _applications._
|
| It's trivial to write semi-portable C++ snippets, too,
| that's not a major achievement.
| hota_mazi wrote:
| Now you're being intentionally obtuse and moving the goal
| posts from your original claims just to score points.
|
| You're not arguing in good faith.
|
| Feel free to stick with your invalid views on
| portability, the rest of us JVM developers will keep
| enjoying the portability that this wonderful technology
| provides us.
| jsight wrote:
| When people call .class files portable, they mean between
| platforms that have a JVM available and can pass the TCK.
|
| Platforms that do not aim to do that are not really
| relevant.
| kllrnohj wrote:
| That's like saying C++ exe's are portable if you just
| ignore all platforms that don't have an NT kernel.
|
| Market share determines a platform's relevance to
| portability claims, not its intention towards the JVM.
| jacques_chester wrote:
| I see that your goalposts in this discussion are also
| highly portable.
| coldtea wrote:
| > _As a student most of the way through a Java course, I 'm
| wondering what Java is still used for._
|
| A huge majority of all code behind services, websites, and
| businesses you interact with every day. From Google, Facebook,
| Apple, and Twitter to your bank, and from Android to you
| favorite new unicorn. Of the top 25 unicorns "20 use Python; 19
| use Java; eight use Kotlin. Coinbase was the only top-ten
| unicorn found to use Swift." [1]
|
| And that's just startups and FAANG. On top of that, every
| enterprise, government organization, and financial organization
| also uses tons of Java with the exception of Microsoft shops,
| which use C# in its place (or also use C# on top of Java).
|
| Think of it this way: you know how C# is a big industry? It's
| #5 in the TIOBE index. Java is #2, and has been between
| bouncing between #1, #2, and #3 spots for decades.
|
| And on top of Java there's the JVM, which also powers Kotlin,
| Clojure, Scala, Groovy, and other languages...
|
| > _Java applets are dead_
|
| Java applets have been dead on arrival. It was just a fan
| around 1997-1999 and not that succesful even then (I was
| there). They were never a big part of Java's allure.
|
| > _Java is supposed to be able to "run anywhere," yet C++ is
| more portable because it doesn't require the JVM to run._
|
| That's a non-sequitur.
|
| [1] https://insights.dice.com/2019/07/12/python-java-kotlin-
| skil...
| Aardwolf wrote:
| > Java applets have been dead on arrival
|
| The only successful Java applet I know was Runescape (if that
| was an applet? it ran in browser), an RPG game that ran in
| Java in the browser, for 15 years or so roughly afaik, today
| they switched to a non browser based client instead.
|
| Other Java applets almost never worked for some reason. Like,
| sometimes I'd visit a website about some mathematical topic,
| and the whole browser would hang while some java applet
| demonstrating the math was supposedly loading, and then most
| of the time it didn't actually work.
| sixstringtheory wrote:
| Don't know about "successful" or "useful", but the Java
| Applets on Complexification were some of the most beautiful
| software I've ever seen:
| http://www.complexification.net/gallery/
| foobarian wrote:
| The only applet I know of outside the early few years of
| hype that still works and does something useful is
| Falstad's circuit simulator.
| https://www.falstad.com/circuit/
| Aardwolf wrote:
| Actually that one has been rewritten in JS! The fast
| loading and no gray screen gives that away :D
|
| There's a link to the original Java version below, that
| one doesn't work for me anymore, I no longer have a java-
| enabled browser
| coldtea wrote:
| >* The fast loading and no gray screen gives that away
| :D*
|
| Well, plus the fact that no modern browser runs Java
| applets...
| g051051 wrote:
| The first "real" Java program I wrote back in 1997 was a
| huge applet. It was the replacement for an existing X
| Windows application, with 42 screens. The applet itself
| worked great, but the networking technology at the time was
| such that when all the users on a network segment started
| their browser and launched the applet, it bogged things
| down to a crawl. Still, when it was loaded it was amazing
| (for 1997). It looked almost exactly like the original
| application, and updates were as easy as putting a new jar
| file onto the web server.
| radiospiel wrote:
| Roughly 20 years ago we embedded Java applets inside a
| HTML-based online help. This turned the help from a reading
| resource (which tells you where to find certain
| preferences) into an actually interactive resource,
| composed from the same applets that also formed the
| Application itself.
|
| Worked like a charm. I have yet to see anything similar to
| that.
| fh973 wrote:
| Here at Quobyte, we're developing a distributed file system
| that is partially written in Java. The JVM is rock-stable,
| fast, and developers are very productive in Java.
| tarkin2 wrote:
| Java is rarely used for sexy stuff like front-ends or
| (increasingly) apps.
|
| Java is, however, used for services. Bank logins, search
| engines (Google originally used it), insurance systems.
|
| C#, C++ and Rust are in the same area. But Java, for the most
| case, has been around longer.
|
| A LOT of companies used it and can't easily switch their
| codebase to something newer and shinier. And now Java improves
| with every release they have fewer reasons to move.
| thesimon wrote:
| > A LOT of companies used it and can't easily switch their
| codebase to something newer and shinier
|
| I don't agree with that. Spring Boot makes it so easy to
| write nice backends and a type system is often useful
|
| > they have fewer reasons to move
|
| Move to what btw? NodeJS?
| kaladin_1 wrote:
| Happy with the number of comments on this release.
|
| HN is a funny place.One day you are convinced no smart person on
| HN is still writing Java and the next day you see droves
| discussing about a java release.
| signal11 wrote:
| A new JVM release is always cause for cheer. The demo language
| it comes with also keeps getting better :-)
| dankwizard wrote:
| i make lots of money doing it though
___________________________________________________________________
(page generated 2021-03-16 23:02 UTC)