21 ms·

Java 16

410 points by JCWasmx86 6y ago

JCWasmx86 6y ago
The JEPs/enhancements: http://openjdk.java.net/projects/jdk/16/ http://openjdk.java.net/projects/jdk/16/
- StepWeiwu 6y ago
  The page returned a 500 for me, bad omen for Java 16? :)
  - JCWasmx86 6y ago
    The site works great for me.
java-man 6y ago
Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?
- JCWasmx86 6y ago
  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"
  - Macha 6y ago
    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 6y ago
    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-reference/keywords/#contextual-keywords https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
  - hugi 6y ago
    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.
  - BoyRobot777 6y ago
    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/2019-January/000945.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
  - Jabbles 6y ago
    Surely migrating variables named "unsealed" would be fairly trivial?
- Erlangen 6y ago
  It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.
  - bartvk 6y ago
    Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.
  - m45t3r 6y ago
    I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.
    - fomine3 6y ago
      int non, sealed; ?
  - gpderetta 6y ago
    co_await is so bad that co_X has become a running joke in the C++ community.
  - kccqzy 6y ago
    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.)
- elygre 6y ago
  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).
- nikanj 6y ago
  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
mooreds 6y ago
Super interested in https://openjdk.java.net/jeps/386 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.
- JCWasmx86 6y ago
  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.
- dkersten 6y ago
  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 https://www.azul.com/downloads/zulu-community/?package=jdk
- eigenvalue 6y ago
  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.
hasa 6y ago
OMG I'm old. I thought that Java 9 would be next version.
- vmception 6y ago
  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 https://en.wikipedia.org/wiki/Java_version_history
  - Freak_NL 6y ago
    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.
    - meddlepal 6y ago
      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.
      - krzyk 6y ago
        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)
whalesalad 6y ago
I love the Java website. Strong early-2000s vibes. Still has an XHTML doctype!
- btown 6y ago
  And now a 500 database error too!
  - fulafel 6y ago
    Wonder what database they are using.
    - whalesalad 6y ago
      period correct? mysql 5.1
      - Cthulhu_ 6y ago
        Oh no it was Oracle before Oracle bought MySQL, so it's gotta be Oracle db.
        tragomaskhalos 6y ago
        It's probably Postgres on an interim basis, until an army of finance dweebs have calculated the internal licensing cost of using Oracle :)
  - throwaway4good 6y ago
    There is an nginx in front of it. What was wrong with Apache?
    - Spivak 6y ago
      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.
Thaxll 6y ago
Site is dying with 500.
- justin_oaks 6y ago
  Got the same at first. Reloaded the URL and it came up correctly.
  - flemhans 6y ago
    Same experience. A few refreshes and it works.
    - throwaway4good 6y ago
      The beauty of a load balancer ...
dadoge 6y ago
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.
- meddlepal 6y ago
  I think the reaction has been more to Kotlin than Scala.
  - jmarcher 6y ago
    Arguably, Kotlin took some of the better ideas from Scala.
    - virtualwhys 6y ago
      Arguably? I'd say it's rather obvious, but overall they're different languages with different goals.
      - Koshkin 6y ago
        To be fair, “arguably” has come to mean “no doubt.”
        jmarcher 6y ago
        You are thinking about "unarguably". ;)
        Koshkin 6y ago
        No, I was talking about the now usual in the English-speaking practice amplification of its meaning as "can be supported or shown by persuasive argument", e.g., That is arguably the best book on the subject. https://www.thefreedictionary.com/arguably https://www.thefreedictionary.com/arguably
Fiveplus 6y ago
Curious how many folks here experimented with the now depreciated Ahead-of-Time Compilation feature?
- JCWasmx86 6y ago
  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_ 6y ago
  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 6y ago
    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 6y ago
      Which is why GraalVM requires you to explicitly mention what types should be available for reflection.
      - meddlepal 6y ago
        Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.
        brabel 6y ago
        There are good frameworks that already work well with GraalVM native, including Quarkus and Micronaut. They avoid reflection altogether in most cases.
yellow_lead 6y ago
Records are a cool highlight for this version. https://openjdk.java.net/jeps/395 https://openjdk.java.net/jeps/395
- seahawks78 6y ago
  I am curious where does it leave libraries like Lombok that basically ports a non-record type Java class to make it more record type-e by adding things like @Value, @Data annotations. Are those libraries/frameworks going to become obsolete now?
  - rrrgggg 6y ago
    Hopefully lombok dies.
dangerboysteve 6y ago
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%20Podcast%20is,Panama%2C%20and%20everything%20in%20between https://inside.java/podcast/#:~:text=The%20Inside%20Java%20P...!
- myroon5 6y ago
  their blog post as well: https://inside.java/2021/03/16/the-arrival-of-java16/ https://inside.java/2021/03/16/the-arrival-of-java16/
- chronogram 6y ago
  Thanks. Was a good show, though nothing super informative.
benjiweber 6y ago
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-machines/ 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-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-matching-fun/ https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...
- exdsq 6y ago
  Love the state machine example :)
- elric 6y ago
  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 6y ago
    Removal is not likely, nor is major change. Most likely some minor changes.
- bob1029 6y ago
  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-matching 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.
  - victor106 6y ago
    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
huodon 6y ago
We use java 100, called kotlin
seattle_spring 6y ago
Wow, might be time to finally throw out my copy of Java 6 SCJP (Sun Certified Java Programmer)
JulianMorrison 6y ago
Still on Java 8 at work :-/
- bartvk 6y ago
  What’s the reason for that?
- BoyRobot777 6y ago
  Every thread about new Java version has the same comment all the time. Why share it? What kind of response do you seek?
  - matsemann 6y ago
    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 6y ago
      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 6y ago
        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?
simple_phrases 6y ago
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 6y ago
  Interesting. Readibility? Performance cost? Would be nice if you could expand.
avodonosov 6y ago
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.
- bartvk 6y ago
  What’s the use of forcing everything to be an object?
- MrBuddyCasino 6y ago
  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 6y ago
    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/~briangoetz/valhalla/sov/01-background.html https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...
    - avodonosov 6y ago
      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.
setheron 6y ago
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
deepGem 6y ago
Java adoption has now reached the release_version / 2 parity :)
skepticmoron1 6y ago
Java 16 for what? Does anybody really use > 8 in production?
- krzyk 6y ago
  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.
  - noisy_boy 6y ago
    Tons of folks in financial IT are on 8 - it is pretty stable and very common target for most of the libraries being used.
  - aogl 6y ago
    We're still on 8 at <bank>
  - _-david-_ 6y ago
    I am pretty sure Red Hat, IBM, and probably other enterprisey type companies backport security patches for Java 8.
closeparen 6y ago
Man, I hope the migration to Java 11 that my infrastructure team started 18 months ago is going okay.
- kronin 6y ago
  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 6y ago
    LTS doesn't exist within OpenJDK. LTS only exists if you're paying a specific provider for it.
    - lensopra 6y ago
      Then what does AdoptOpenJDK mean when they label 11 a LTS release? https://adoptopenjdk.net/index.html https://adoptopenjdk.net/index.html
    - suyash 6y ago
      LTS is more than support, it provides mental stability that you don't have to update every 6 months.
haberman 6y ago
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?
- meddlepal 6y ago
  I do not believe they are on the roadmap at all.
- krzyk 6y ago
  What are aliases?
  - uDontKnowMe 6y ago
    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)
- noisy_boy 6y ago
  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 6y ago
    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).
ObscureScience 6y ago
What's the state of tail call optimization on JVM nowadays?
- kag0 6y ago
  It's a compiler level thing, not runtime. ie. Scala has tail call optimization but Java doesn't, but they both run on the same JVM.
  - ObscureScience 6y ago
    That's interesting, I have been under the impression that Scala and Clojure has been limited with this optimization because of JVM.
jjjeii3 6y ago
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)
- devoutsalsa 6y ago
  Sounds like how C# got started :)
- BoyRobot777 6y ago
  I was not aware that Microsoft invented algebraic data type.
- deleted 6y ago
  [deleted]
- krzyk 6y ago
  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.
- stevetodd 6y ago
  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.
tmp7oaje 6y ago
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?
- sparsely 6y ago
  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 6y ago
  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 6y ago
    I’m assuming Amazon? Most of Amazon runs on Java.
- dehrmann 6y ago
  > 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.
JulianMorrison 6y ago
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 6y ago
  >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/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...
  - JulianMorrison 6y ago
    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.
yawaworht1978 6y ago
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
tarkin2 6y ago
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 6y ago
  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 6y ago
    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.
- tablespoon 6y ago
  > Java programs normally sit on a server, or many servers of the same arch. That's true right now, but it wasn't true in the recent past (SPARC) and it might not be true in the near future (ARM). Early in my career I was on a team that migrated our Java application from elderly Sun boxes to newer x86 hardware, and it was relatively painless. There's a good chance we'll eventually to the same from x86 to ARM. Most developers will also continue develop on x86 for the foreseeable future.
  - deleted 6y ago
    [deleted]
- 6y ago
kaladin_1 6y ago
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.
- dankwizard 6y ago
  i make lots of money doing it though
- signal11 6y ago
  A new JVM release is always cause for cheer. The demo language it comes with also keeps getting better :-)
  - ph2082 6y ago
    It's a huge win that 'demo language' it comes with pays lots of people's bill. :)
- mbrodersen 6y ago
  The idea that the tools you use is a reflection of how smart you are is just plain old silly. Most of the work you do in software is language/tools independent. A smart software developer can do great work with almost any tool.
- koheripbal 6y ago
  In the financial industry, most server software is still written in Java (unless it's built for high-speed execution).
suyash 6y ago
List of features and explanations with no BS on what's new in Java 16 : https://metebalci.com/blog/what-is-new-in-java-16/ https://metebalci.com/blog/what-is-new-in-java-16/
seahawks78 6y ago
Hopefully, there will be a day/release in the Java world when we will be able to write 10x - 20x shorter programs (in terms of LOC) with most mundane stuffs disappearing under the hood. Sighs!! It will be interesting to see the reaction of project managers some of whom still measure productivity in terms of lines of code/# of commits! (yeah, they do and still exist).
pkphilip 6y ago
I wish Java had something similar to Properties in Delphi. http://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi) http://docwiki.embarcadero.com/RADStudio/Sydney/en/Propertie... You can have Get and Set methods for properties or even allow direct access to the variable itself. type TCompass = class(TControl) private FHeading: THeading; procedure SetHeading(Value: THeading); published property Heading: THeading read FHeading write SetHeading; ... end; Also, properties can be indexed. type TRectangle = class private FCoordinates: array[0..3] of Longint; function GetCoordinate(Index: Integer): Longint; procedure SetCoordinate(Index: Integer; Value: Longint); public property Left: Longint index 0 read GetCoordinate write SetCoordinate; property Top: Longint index 1 read GetCoordinate write SetCoordinate; property Right: Longint index 2 read GetCoordinate write SetCoordinate; property Bottom: Longint index 3 read GetCoordinate write SetCoordinate; property Coordinates[Index: Integer]: Longint read GetCoordinate write SetCoordinate; ... end; Properties can also have "property pages" which can show specific user interfaces for viewing/setting these properties. https://www.delphipower.xyz/guide_8/adding_a_property_page.html https://www.delphipower.xyz/guide_8/adding_a_property_page.h... I have yet to see anything of this sophistication in Java or for that matter in any other component framework.

Java 16

410 points by JCWasmx86 6y ago

JCWasmx86 6y ago

The JEPs/enhancements: http://openjdk.java.net/projects/jdk/16/ http://openjdk.java.net/projects/jdk/16/

StepWeiwu 6y ago
The page returned a 500 for me, bad omen for Java 16? :)
- JCWasmx86 6y ago
  The site works great for me.

java-man 6y ago

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

JCWasmx86 6y ago
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"
- Macha 6y ago
  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 6y ago
  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-reference/keywords/#contextual-keywords https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- hugi 6y ago
  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.
- BoyRobot777 6y ago
  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/2019-January/000945.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
- Jabbles 6y ago
  Surely migrating variables named "unsealed" would be fairly trivial?
Erlangen 6y ago
It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.
- bartvk 6y ago
  Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.
- m45t3r 6y ago
  I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.
  - fomine3 6y ago
    int non, sealed; ?
- gpderetta 6y ago
  co_await is so bad that co_X has become a running joke in the C++ community.
- kccqzy 6y ago
  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.)
elygre 6y ago
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).
nikanj 6y ago
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

mooreds 6y ago

Super interested in https://openjdk.java.net/jeps/386 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.

JCWasmx86 6y ago
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.
dkersten 6y ago
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 https://www.azul.com/downloads/zulu-community/?package=jdk
eigenvalue 6y ago
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.

hasa 6y ago

OMG I'm old. I thought that Java 9 would be next version.

vmception 6y ago
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 https://en.wikipedia.org/wiki/Java_version_history
- Freak_NL 6y ago
  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.
  - meddlepal 6y ago
    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.
    - krzyk 6y ago
      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)

whalesalad 6y ago

I love the Java website. Strong early-2000s vibes. Still has an XHTML doctype!

btown 6y ago
And now a 500 database error too!
- fulafel 6y ago
  Wonder what database they are using.
  - whalesalad 6y ago
    period correct? mysql 5.1
    - Cthulhu_ 6y ago
      Oh no it was Oracle before Oracle bought MySQL, so it's gotta be Oracle db.
      - tragomaskhalos 6y ago
        It's probably Postgres on an interim basis, until an army of finance dweebs have calculated the internal licensing cost of using Oracle :)
- throwaway4good 6y ago
  There is an nginx in front of it. What was wrong with Apache?
  - Spivak 6y ago
    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.

Thaxll 6y ago

Site is dying with 500.

justin_oaks 6y ago
Got the same at first. Reloaded the URL and it came up correctly.
- flemhans 6y ago
  Same experience. A few refreshes and it works.
  - throwaway4good 6y ago
    The beauty of a load balancer ...

dadoge 6y ago

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.

meddlepal 6y ago
I think the reaction has been more to Kotlin than Scala.
- jmarcher 6y ago
  Arguably, Kotlin took some of the better ideas from Scala.
  - virtualwhys 6y ago
    Arguably? I'd say it's rather obvious, but overall they're different languages with different goals.
    - Koshkin 6y ago
      To be fair, “arguably” has come to mean “no doubt.”
      - jmarcher 6y ago
        You are thinking about "unarguably". ;)
        Koshkin 6y ago
        No, I was talking about the now usual in the English-speaking practice amplification of its meaning as "can be supported or shown by persuasive argument", e.g., That is arguably the best book on the subject. https://www.thefreedictionary.com/arguably https://www.thefreedictionary.com/arguably

Fiveplus 6y ago

Curious how many folks here experimented with the now depreciated Ahead-of-Time Compilation feature?

JCWasmx86 6y ago
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_ 6y ago
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 6y ago
  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 6y ago
    Which is why GraalVM requires you to explicitly mention what types should be available for reflection.
    - meddlepal 6y ago
      Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.
      - brabel 6y ago
        There are good frameworks that already work well with GraalVM native, including Quarkus and Micronaut. They avoid reflection altogether in most cases.

yellow_lead 6y ago

Records are a cool highlight for this version. https://openjdk.java.net/jeps/395 https://openjdk.java.net/jeps/395

seahawks78 6y ago
I am curious where does it leave libraries like Lombok that basically ports a non-record type Java class to make it more record type-e by adding things like @Value, @Data annotations. Are those libraries/frameworks going to become obsolete now?
- rrrgggg 6y ago
  Hopefully lombok dies.

dangerboysteve 6y ago

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%20Podcast%20is,Panama%2C%20and%20everything%20in%20between https://inside.java/podcast/#:~:text=The%20Inside%20Java%20P...!

myroon5 6y ago
their blog post as well: https://inside.java/2021/03/16/the-arrival-of-java16/ https://inside.java/2021/03/16/the-arrival-of-java16/
chronogram 6y ago
Thanks. Was a good show, though nothing super informative.

benjiweber 6y ago

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-machines/ 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-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-matching-fun/ https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...

exdsq 6y ago
Love the state machine example :)
elric 6y ago
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 6y ago
  Removal is not likely, nor is major change. Most likely some minor changes.
bob1029 6y ago
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-matching 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.
- victor106 6y ago
  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

huodon 6y ago

We use java 100, called kotlin

seattle_spring 6y ago

Wow, might be time to finally throw out my copy of Java 6 SCJP (Sun Certified Java Programmer)

JulianMorrison 6y ago

Still on Java 8 at work :-/

bartvk 6y ago
What’s the reason for that?
BoyRobot777 6y ago
Every thread about new Java version has the same comment all the time. Why share it? What kind of response do you seek?
- matsemann 6y ago
  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 6y ago
    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 6y ago
      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?

simple_phrases 6y ago

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 6y ago
Interesting. Readibility? Performance cost? Would be nice if you could expand.

avodonosov 6y ago

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.

bartvk 6y ago
What’s the use of forcing everything to be an object?
MrBuddyCasino 6y ago
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 6y ago
  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/~briangoetz/valhalla/sov/01-background.html https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...
  - avodonosov 6y ago
    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.

setheron 6y ago

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

deepGem 6y ago

Java adoption has now reached the release_version / 2 parity :)

skepticmoron1 6y ago

Java 16 for what? Does anybody really use > 8 in production?

krzyk 6y ago
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.
- noisy_boy 6y ago
  Tons of folks in financial IT are on 8 - it is pretty stable and very common target for most of the libraries being used.
- aogl 6y ago
  We're still on 8 at <bank>
- _-david-_ 6y ago
  I am pretty sure Red Hat, IBM, and probably other enterprisey type companies backport security patches for Java 8.

closeparen 6y ago

Man, I hope the migration to Java 11 that my infrastructure team started 18 months ago is going okay.

kronin 6y ago
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 6y ago
  LTS doesn't exist within OpenJDK. LTS only exists if you're paying a specific provider for it.
  - lensopra 6y ago
    Then what does AdoptOpenJDK mean when they label 11 a LTS release? https://adoptopenjdk.net/index.html https://adoptopenjdk.net/index.html
  - suyash 6y ago
    LTS is more than support, it provides mental stability that you don't have to update every 6 months.

haberman 6y ago

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?

meddlepal 6y ago
I do not believe they are on the roadmap at all.
krzyk 6y ago
What are aliases?
- uDontKnowMe 6y ago
  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)
noisy_boy 6y ago
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 6y ago
  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).

ObscureScience 6y ago

What's the state of tail call optimization on JVM nowadays?

kag0 6y ago
It's a compiler level thing, not runtime. ie. Scala has tail call optimization but Java doesn't, but they both run on the same JVM.
- ObscureScience 6y ago
  That's interesting, I have been under the impression that Scala and Clojure has been limited with this optimization because of JVM.

jjjeii3 6y ago

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)

devoutsalsa 6y ago
Sounds like how C# got started :)
BoyRobot777 6y ago
I was not aware that Microsoft invented algebraic data type.
deleted 6y ago
[deleted]
krzyk 6y ago
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.
stevetodd 6y ago
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.

tmp7oaje 6y ago

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?

sparsely 6y ago
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 6y ago
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 6y ago
  I’m assuming Amazon? Most of Amazon runs on Java.
dehrmann 6y ago
> 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.

JulianMorrison 6y ago

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 6y ago
>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/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...
- JulianMorrison 6y ago
  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.

yawaworht1978 6y ago

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

tarkin2 6y ago

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 6y ago
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 6y ago
  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.
tablespoon 6y ago
> Java programs normally sit on a server, or many servers of the same arch. That's true right now, but it wasn't true in the recent past (SPARC) and it might not be true in the near future (ARM). Early in my career I was on a team that migrated our Java application from elderly Sun boxes to newer x86 hardware, and it was relatively painless. There's a good chance we'll eventually to the same from x86 to ARM. Most developers will also continue develop on x86 for the foreseeable future.
- deleted 6y ago
  [deleted]
6y ago

kaladin_1 6y ago

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.

dankwizard 6y ago
i make lots of money doing it though
signal11 6y ago
A new JVM release is always cause for cheer. The demo language it comes with also keeps getting better :-)
- ph2082 6y ago
  It's a huge win that 'demo language' it comes with pays lots of people's bill. :)
mbrodersen 6y ago
The idea that the tools you use is a reflection of how smart you are is just plain old silly. Most of the work you do in software is language/tools independent. A smart software developer can do great work with almost any tool.
koheripbal 6y ago
In the financial industry, most server software is still written in Java (unless it's built for high-speed execution).

suyash 6y ago

List of features and explanations with no BS on what's new in Java 16 : https://metebalci.com/blog/what-is-new-in-java-16/ https://metebalci.com/blog/what-is-new-in-java-16/

seahawks78 6y ago

Hopefully, there will be a day/release in the Java world when we will be able to write 10x - 20x shorter programs (in terms of LOC) with most mundane stuffs disappearing under the hood. Sighs!! It will be interesting to see the reaction of project managers some of whom still measure productivity in terms of lines of code/# of commits! (yeah, they do and still exist).

pkphilip 6y ago

I wish Java had something similar to Properties in Delphi. http://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi) http://docwiki.embarcadero.com/RADStudio/Sydney/en/Propertie... You can have Get and Set methods for properties or even allow direct access to the variable itself. type TCompass = class(TControl) private FHeading: THeading; procedure SetHeading(Value: THeading); published property Heading: THeading read FHeading write SetHeading; ... end; Also, properties can be indexed. type TRectangle = class private FCoordinates: array[0..3] of Longint; function GetCoordinate(Index: Integer): Longint; procedure SetCoordinate(Index: Integer; Value: Longint); public property Left: Longint index 0 read GetCoordinate write SetCoordinate; property Top: Longint index 1 read GetCoordinate write SetCoordinate; property Right: Longint index 2 read GetCoordinate write SetCoordinate; property Bottom: Longint index 3 read GetCoordinate write SetCoordinate; property Coordinates[Index: Integer]: Longint read GetCoordinate write SetCoordinate; ... end; Properties can also have "property pages" which can show specific user interfaces for viewing/setting these properties. https://www.delphipower.xyz/guide_8/adding_a_property_page.html https://www.delphipower.xyz/guide_8/adding_a_property_page.h... I have yet to see anything of this sophistication in Java or for that matter in any other component framework.