55 ms·

New language features since Java 8 to 17

• cageface 5y ago
  Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.
  • jayd16 5y ago
    Kotlin is still run by the company that makes the best Java ide, no? I don't expect kotlin to get pushed out so easily.
  • Waterluvian 5y ago
    I don’t follow why this is unfortunate?
    • tablespoon 5y ago
      > I don’t follow why this is unfortunate? I'm guessing Java hate, which is kind of fashionable. If Java evolves to stay relevant, it won't be usurped and fade away.
    • CuriousCosmic 5y ago
      A lot of people have migrated away from Java to better JVM languages. If Java actually keeps improving, there's a reasonable likelihood that people will stop migrating and those that have may come back to Java from these other langs. Long term this could lead to a loss of maintenance for tools and libraries for these languages which could kill them and leave those that migrated with a dead & decaying ecosystem. Of course this is a bit of a stretch but it's not unheard of.
      • pjmlp 5y ago
        A tiny drop, an endless collection of guest language that goes back to Beanshell, many of which now forgotten.
      • ISL 5y ago
        If people left Java for other language(s), wouldn't that leave Java with a decaying ecosystem?
        • spockz 5y ago
          Most of them stayed somewhere on the jvm though. Still in the ecosystem.
        • Sevaris 5y ago
          Maybe worry about leveling the playing field first? There's so much money and research and development going into Java that there's no possible way for Java to end up with a "decaying ecosystem" inside the next twenty years. It's like pointing out DuckDuckGo and worrying about Google.
      • tunesmith 5y ago
        Over the last short while I've seen Lightbend announce ceasing support for Play, others express that Slick is likely abandonware, and also seen my chosen Play authentication library, silhouette, get archived on github. All of this has impacted my favorite side project that I've been slowly plugging away on. Silhouette is probably just because of one guy's schedule, but Play/Slick seems like after-effects of lightbend's layoffs many months ago, and while I don't know the cause of those it seems plausible it's because of the kind of thing you describe above.
    • atomicnumber3 5y ago
      I assume OP prefers Kotlin or Scala. Personally, I think one of my favorite things about Java is that, all things considered, it's a small-ish language. So I'm glad that Java is both willing to evolve (slowly, letting other people try stuff out first) but also clearly focused on a curated feature set and resistant to letting new stuff in to bloat it. I am very happy to deal with minor things like no multiline string support if it means we get to avoid being a terrible mess of language features that ruby, scala, python, etc have accrued in a relatively quicker timescale. I was fairly sad around the java 6-7 days where we went quite a long time with no visibly major new language features (diamond inference was 7's big thing, lol). So it is nice that we're moving a bit faster than that, now.
      • pooya72 5y ago
        By multiline strings are you referring to text blocks? Those have been added to the language in Java 15: https://docs.oracle.com/en/java/javase/15/text-blocks/index.html https://docs.oracle.com/en/java/javase/15/text-blocks/index.... .
        • atomicnumber3 5y ago
          Oh, sorry, I know, I mentioned it specifically because it was "only" just added in Java 15 (which is basically "now" in Java timescales heh, and has only literally just now (with 17) made it into LTS AdoptOpenJDK releases, which also haven't quite landed on many distros package repositories, etc etc.). So for some weird value of "right now" Java still doesn't quite have multi line strings due to its newness.
        • EdwardDiego 5y ago
          Tbh I still crave Kotlins inline string interpolation.
          • kaba0 5y ago
            A “superior” implementation is in the works with templated strings. It will look something like this: STR.”text with \\{variable}”, but anything implementing the TemplatedString interface can change the behavior of interpolation. There is not even a requirement to produce strings only!
    • cageface 5y ago
      What I don't want to see happen is innovation stop in JVM languages and then Java, no longer under threat, also stops innovating.
      • kaba0 5y ago
        Java has basically no threat from Kotlin and the like. The reason it innovates now is simply Oracle’s increased pouring of money into the platform, which is especially visible now compared to the stagnation of the end of the Sun era.
  • jmfldn 5y ago
    This is great not unfortunate. If Java improves because of Scala and Kotlin then so much the better, this is how languages evolve. If it really does evolve to remove the need for a better Java then it would be nice if people switched away from Kotlin and back to it. Scala can then carry on cementing its niche as a powerful commercial FP language. No hate for Kotlin at all but it seems like in that world, there might be no need for it. Scala is better for FP and if Java 17 is the better Java then great.
    • cutler 5y ago
      Android will always be Kotlin-first. That's a pretty huge market.
      • jpgvm 5y ago
        I think people underestimate how deep this integration is going. Compose relies on extensions to the Kotlin compiler. The future of Android and Kotlin are pretty much tied together at this point.
      • jayd16 5y ago
        Android used to be always Java first. It could change again.
        • vbezhenar 5y ago
          Most likely to Flutter. When Google will be ready to ditch Android API.
          • hota_mazi 5y ago
            Android is based on the JVM, it will never switch to Flutter (and an aggravating factor is that Dart is an inferior version of Kotlin).
            • pjmlp 5y ago
              If you want some fun watching Jake Wartorn's opinion on it, https://youtu.be/VX6nAvRWQg4 https://youtu.be/VX6nAvRWQg4
  • Smaug123 5y ago
    I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's true. C# has grown into an enormous language as it tries (consciously or not) to subsume F#, and F# is always going to remain so much cleaner just because you aren't having to ignore 90% of the language features when you code in it.
    • throw868788 5y ago
      Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412 https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others. What matters more in all honesty, and what's hard to change IMO is: - The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc. - Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.
  • pjmlp 5y ago
    Except without Java they are meaningless.
  • 5e92cb50239222b 5y ago
    This happens all the time with "guest" languages. A few old salts have been prophesying this right here on HN since Kotlin first came out. I think it'll still be used on Android though, it's hard to see Google pushing Android development back to Java.
  • mavelikara 5y ago
    Java's implementation of generics was heavily influenced by a language called Pizza. Sun hired the author of the language, Martin Odersky, to write the compiler for Java. Odersky later went on to develop Scala. Java improving borrowing ideas from other JVM languages had happened in the past, and that has made the ecosystem stronger. Nothing unfortunate about it.
  • 66fm472tjy7 5y ago
    I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collections instead of having to .stream().map(..).collect(toList())
    • nikeee 5y ago
      IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java. Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms. As of now, Optional#map seems to be the way to go.
    • bestinterest 5y ago
      Is that true though? nullability is a area I've heard /u/pron mention may be tackled in the future, mutable records seem like they will be tackled with the 'withers' concept in the future. Checked exceptions + changing the sugar of .stream().map I don't see ever changing. Properties I am unsure of.
      • cogman10 5y ago
        AFAIK, the fate of nullability is tied pretty directly to Valhalla. It's constantly being brought up there.
      • laurent92 5y ago
        Why should it be in the future. The syntax of .stream() has been awfully verbose since Java 8: in the middle of “.stream()….collect(toList())”, you need to squint to find the actual function name being applied between the flood of polluting calls, which loses the appeal of functional programming. In my company we have f(list).map(…), which is a wrapper for the streams. But newcomers don’t like it because it’s not the standard.
    • 5y ago
  • hocuspocus 5y ago
    Scala is fine. People understood it's not really worth it as a "better Java". Companies that choose Scala in 2021 are using either big data frameworks (where Python bindings are the most common alternative to Scala, not Java), or functional ecosystems (Typelevel, Zio). Scala 3 has taken an interesting direction and to me it seems that Odersky wants to win Python developers over rather than Java shops using Spring. New features in Java and the JVM (records, loom, valhalla, ...) are directly going to benefit Scala and make it even better. On the contrary, Kotlin's essence has always been threatened by the fact it's nothing more than a better Java. I assume there's still a big demand for that on Android, but if you're running on a recent JVM, I would certainly consider Java over Kotlin.
    • tunesmith 5y ago
      Which is a bummer for folks that loves the cleanliness and power of "basic Scala" (pure functions, immutability) without wanting to get into deep FP theory (typelevel, zio). That has been a really nice pocket to be in for teams that have the discipline to not get clever with it. Same with teams wanting to integrate with Akka on scala.
      • Zababa 5y ago
        I think between Scala 3 and the Li Hayoi ecosystem, there is a path to simplicity. But that usually means you lose part of the appeal of the language, since you can't use some parts of the ecosystem.
      • hocuspocus 5y ago
        Zio is pretty much what you want. No need to understand category theory, no over-reliance on implicit resolution, ... That said you don't need to understand that much to use high-level libraries in the Typelevel ecosystem. And when I do need to reach for low-level constructs, I find nice that everything is built upon clean and composable abstractions. You mention Akka, it's kind of its own beast. The inner workings go definitely way beyond "better Java", yet Lightbend needs to provide a surface API that plays nice with Java interop. It's not an ecosystem easy to navigate in my opinion.
    • 5y ago
  • leroman 5y ago
    Scala still has a better design at its base, which is missing from Java and I don’t see how Java can retro-fit it into the language, Immutability is a big part of being functional and doing safe multi-threading stuff, java is doing all the good syntactic stuff (case class, switches with guards etc) but without immutability it’s a far cry from the same facility in Scala land. Having said that, this trend is welcome for every time I have to write Java and makes it feel more natural to me as an old time Scala developer.
    • kaba0 5y ago
      With records, Java does try to embrace immutability to a certain degree, but of course it will never be completely immutable.
  • pron 5y ago
    The cause and effect are quite right, though. The reason Kotlin was designed in 2009-2010 was because Java became stagnant, not by choice, but due to Sun's demise. After the acquisition and an adjustment period, Oracle gradually increased investment, and the evolution pace got back to it's "normal" course. So Java's "revival" and Kotlin's existence are, indeed, related, but one did not cause the other; rather, they both have a common cause.
  • whyenot 5y ago
    I don't see it as unfortunate. It shows that Java is a living language that continues to improve and change to match the needs of its users. Compare this to Common Lisp, which has not change in any meaningful way since 1984. A lisp-er would probably say that CL is so malleable that it hasn't needed to change, but I'm not so sure about that.
  • armchairhacker 5y ago
    Kotlin is still way ahead of Java with IMO essential features like: - Explicit null - Extension methods - Getters/setters which use property syntax - == instead of Object.equals confusion Also Kotlin's this-scoping and delegated properties, while they take a while to get used to, can be incredibly useful. They make it possible for to write typesafe DSLs like kotlin-html. Moreover, Kotlin is usually very easy to integrate with existing Java projects. Setting up Kotlin in Gradle is just adding a plugin, and Kotlin automatically imports and exports java code. And it runs on the JVM so it will support most platforms that also support Java. And one of the top Java IDEs and contributors (JetBrains) maintains and prioritizes Kotlin.
• sushsjsuauahab 5y ago
  Missing var in java 9?
  • nooorofe 5y ago
    https://advancedweb.hu/new-language-features-since-java-8-to-17/#local-variable-type-inference https://advancedweb.hu/new-language-features-since-java-8-to... > Available since: JDK 11 (Without lambda support in JDK 10) TOC is missed up, there is no java-10 at all.
  • teh_klev 5y ago
    Introduced in Java 10: https://advancedweb.hu/new-language-features-since-java-8-to-17/#local-variable-type-inference https://advancedweb.hu/new-language-features-since-java-8-to...
    • sushsjsuauahab 5y ago
      Wow, my memory failed me! I could have sworn it was 9.
      • teh_klev 5y ago
        You can't remember everything :) I've been a C# developer since v1 and I couldn't tell you specifically what version a feature appeared in. It's all a bit of a blur.
• bobbyi 5y ago
  I imagine there's a reason it's necessary, but it's weird that "sealed" is basically "final" with the ability to do "permits" instead of just adding "permits" as a keyword that can be put on "final" classes
  • Twisol 5y ago
    I suspect it has something to do with classfile format backwards compatibility. From a pure syntax standpoint, I would agree with you, but there's probably some value to making a very clear separation for classfile loading.
• popotamonga 5y ago
  Still no property literals
• dmitryminkovsky 5y ago
  I just want to add that while this is a really nice post in its own right, I found this blog because its author created this: https://github.com/dodie/vim-fibo-indent https://github.com/dodie/vim-fibo-indent
• irl_chad 5y ago
  We must have a “new features since Java 8” post every other day.
  • pjmlp 5y ago
    Because plenty of people judge Java by their pre-Java 8 frozen knowledge. At least it isn't yet another link to re-written in Rust headlines.
    • junon 5y ago
      I must be in the minority of thinking java 7 was the last great version of Java. What I see today is a nearly different language.
      • vbezhenar 5y ago
        I liked Java 1.4. Generics were a mess. And Java before generics was so wonderfully simple. Yes, you had to cast, but that wasn’t a big issue. My favourite language would be Java 1.4 with carefully redesigned standard library (because old standard library was not very nice).
        • pharmakom 5y ago
          Isn’t that almost Go? Well, before Go generics land.
          • pjmlp 5y ago
            Indeed.
            • jatone 5y ago
              thankfully go generics seem far better thought out.
              • 5y ago
• rdpintqogeogsaa 5y ago
  I've been bitten by bitwise operations on signed integers a few too many times. Are there any plans on having normal unsigned integer types yet?
  • recursive 5y ago
    Other than sign-extension on right shift, I can't think of a bitwise operator that has a different implementation between signed/unsigned. What scenarios are you thinking of?
    • xxs 5y ago
      reading and processing bytes mostly. Many people get confused due to the need of bitwise and, yet even if that would be removed I can't quite see the intrinsic benefits, given how difficult would be having another primitive type.
      • recursive 5y ago
        So, when processing bytes, can you name an operation where the existence of an unsigned type would even make a difference? I'm still not seeing it.
        • eMSF 5y ago
          Java bytes are signed. They aren't useful when working with unsigned 8-bit values (say, a scaling factor or an index in whatever binary format you are trying to parse). You need a larger integer type, and indeed that bitwise and operation to get the range of values you need.
        • xxs 5y ago
          java virtually has only 2 integer types int and long, or 4 and 8 bytes one. So all operations are converted to int (or long) 1st, even when they involve byte/short, etc. Imagine you try to combine a 4bytes (from an array) into a single int. If you just bitwise OR and shift left, e.g. something like (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3] it won't work, you need ((b[1] & 0ff) << 16), etc. The byte values greater than 127 would have the sign bit set (and all other higher bits to make the 2complimentary form) That part is somewhat alleviated by wrapping byte arrays into ByteBuffers that would the right thing, or even better using only ByteBuffers (preferably the direct version of them when reading from input/output)
• tomcam 5y ago
  Fantastic article for a language-curious person who doesn’t know Java well.
• JulianMorrison 5y ago
  It's good to see Java starting to waive a lot of the boilerplate. (And frustrating, when stuck on v8.)
  • xxs 5y ago
    A friendly advice: dont be afraid to use public final immutable fields and omit the getters (and setters since you cant have them w/ finals).
    • vips7L 5y ago
      Probably should just use records and get all that for free.
      • xxs 5y ago
        JulianMorrison uses java8, no 'record' there. Not everything fits being a record, either way. The advice is sound for pretty much any class and development, use final fields in the c-tor; make them public if you have to, and dont bother w/ getters.
    • JulianMorrison 5y ago
      I do. It bothers me this wasn't the Java Way from day one. What is with getters and setters - who subclasses and substitutes the implementation of their data carrier objects?
      • deleted 5y ago
        [deleted]
      • xxs 5y ago
        Initially java didn't favor getter and setters. They came with java 1.1 and the attempt bean model (and reflection) to catch visual language designers. The core java packages java.lang; java.util; java.io they dont feature getter/setters, either. If you look at the ancient AWT, there were not getter/setters - they were introduced with 1.1 and the bean stuff, most of the existing methods were deprecated. So in essence it was the original design, some book authors/design concept promoted it... Personally I have not written 'bean alike classes' for years.
• manishsharan 5y ago
  Whenever we read about new improvement in Java,it is always inevitably followed by concerns for viability of Kotlin or Scala. However these concerns are never applicable for Closure. I am glad I went all in on Clojure.
  • Thaxll 5y ago
    Isn't closure on its way out though, not like Perl level but going downhill? Kotlin on the other hand is raising.
  • e40 5y ago
    Can you explain that for the Java noobs here, like me?
    • nikanj 5y ago
      Scala and Kotlin tried to be a better Java (i.e. Algol-esque syntax). Clojure tries to be a better Lisp, an entirely different family of language. Though a good flamewar can be had on 1) Is Scala closer to Pascal 2) Is Pascal Algol-descendant
      • JulianMorrison 5y ago
        Clojure tries to be an immutable-data, copy-on-write, threadsafe by default dialect of Lisp, which none of the other Lisps do.
        • filoeleven 5y ago
          It’s not really copy-on-write though. That implies greater systemic performance losses than what Clojure provides, because it uses HAMTs (Hash Array Mapped Trie) internally. They enable much faster copies of immutable data than copy-on-write does. Your other points are good ones, I just don’t want people to be put off by copy-on-write performance assumptions. You take a ~50% performance hit from choosing Clojure over Java, but the gains in dev speed, maintenance, robustness, and flexibility to changing requirements are supposed to outweigh that. Especially when you include simpler parallelization, which you covered with thread safety.
• pjmlp 5y ago
  Most of which unavailable on Android Java flavour, sorry Google's J++.
  • mabbo 5y ago
    Is there a reason for that? I'd really love to get into android development, but I'm loathe to give up some of the nicer language features in Java. What version of Java is android supporting? At least 8, right?
    • hota_mazi 5y ago
      Java's supported version on Android is a moot point: all new Android development should be made in Kotlin.
      • pjmlp 5y ago
        Pity that Kotlin builds on Java ecosystem and uses that as selling point for adoption. Kotlin libraries on the JVM cannot take advantage of JVM ecosystem, and require KMM to be portable across runtimes, or be constrained to the Android Java flavour. It is like having a flavour of Typescript that only works on Edge.
        • hota_mazi 5y ago
          > Kotlin libraries on the JVM cannot take advantage of JVM ecosystem This makes literally no sense since Android apps are built using not just Gradle but actually the entire Maven Central repo that all Java apps use. Without any changes. If what you said was remotely close to accurate, Android would have its own Maven Central repo.
          • pjmlp 5y ago
            Without any changes! Ah the Google's advocate at his best. Lets not show the people that the libraries that happen to work are those that match Android Java capabilities. Please show us how to use a possible Java 14 library from Maven Central on Android, using records or Panama interop.
• bobthedino 5y ago
  I also recently found this site, which for example can show you an API diff between Java 8 and 17: https://javaalmanac.io/jdk/17/apidiff/8/ https://javaalmanac.io/jdk/17/apidiff/8/
• didip 5y ago
  To be honest, what I really need is a list of backward incompatible changes and a list of projects that can shim those incompatible changes. Just like Javascript.
  • InsaneOstrich 5y ago
    There are very, very few backward incompatible changes in Java
• r0f1 5y ago
  Is there something similar for Python? They are releasing new Python standards with a crazy fast speed. Would be really helpful for me.
  • moffkalast 5y ago
    It would sure be helpful if they took some effort to focus less on adding crazy new stuff every 2 days and instead on maintaining older versions for a change. Maintaining a python dependant system these days is an absolute nightmare, at least with C++ you know that new compilers will be backwards compatible, gah.
    • afandian 5y ago
      How does this feel with Python being dynamic? I always felt very uneasy writing Python precisely because if some random module became incompatible, especially via a transitive depndency, I might not find out until it was running in production.
      • aldanor 5y ago
        What's to be uneasy about? Lock your environments, pin your dependencies, especially in production.
        • moffkalast 5y ago
          Until your LTS OS gets to end of life and you need to switch to the next one which conveniently deprecates old python versions so you have to rewrite everything.
          • aldanor 5y ago
            Why use system Python base environment for production stuff, especially knowing that it will EOL eventually and mayhem may follow? Again, pin your environments using conda, pipenv or whatever else, in which case your base Python version wouldn't matter.
• weatherlight 5y ago
  Java sucks, and should stop being taught as the defacto language in computer science curriculums. It's extremely busy and verbose. There are better OO languages out there, if the point is to teach OO. (I'm ready for this post to get downvoted into oblivion)
  • imheretolearn 5y ago
    Could you please support your statement with reasons?
    • weatherlight 5y ago
      https://thenextweb.com/news/universities-finally-realize-java-bad-introductory-programming-language https://thenextweb.com/news/universities-finally-realize-jav... https://en.wikipedia.org/wiki/Criticism_of_Java#:~:text=The%20Java%20programming%20language%20and,vulnerabilities%20in%20the%20primary%20Java https://en.wikipedia.org/wiki/Criticism_of_Java#:~:text=The%... https://www.quora.com/Why-did-Alan-Kay-dislike-Java https://www.quora.com/Why-did-Alan-Kay-dislike-Java https://vic.nightfall.moe/2016/04/03/Some-reasons-why-I-hate-Java/ https://vic.nightfall.moe/2016/04/03/Some-reasons-why-I-hate... https://developers.slashdot.org/story/08/01/08/0348239/professors-slam-java-as-damaging-to-students https://developers.slashdot.org/story/08/01/08/0348239/profe...
    • Longhanks 5y ago
      public class Main { public static void main(String[] args) { System.out.println("Hello, world!"); } } vs print("Hello, world!") Please comment again if you still cannot see the bloat/unnecessary verbosity.
      • grishka 5y ago
        Global scope is a terrible invention. The less implicitness there is, the better.
        • weatherlight 5y ago
• pharmakom 5y ago
  Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)
  • cyberbanjo 5y ago
    What would do notation add to Java?
    • pharmakom 5y ago
      There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!
      • Skinney 5y ago
        Excessive nesting? Optional supports both .map and .flatMap.
    • emptysea 5y ago
      Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ [1]: https://zio.dev https://zio.dev
      • kaba0 5y ago
        For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency. As for others, without proper Monads, I doubt they would have much use.
• temporallobe 5y ago
  I’m stuck on 8 and 11 in my current projects, so I haven’t seen much of these in the field other than the new record feature. What I am really surprised about is the var construct. Honestly, this leaves me a little conflicted since it seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? I would perhaps argue against it being dynamically-typed since by definition type inference happens at runtime, but it certainly leaves Java in a sort of limbo. I don’t personally care, but I know at some point the topic will come up amongst my dev peers, at which point there will sure to be a (mostly friendly) debate.
  • dunefox 5y ago
    > seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.
    • abraxas 5y ago
      Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.
      • matt2000 5y ago
        Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type). Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled. It also adds more work for the compiler. I'm not sure the effect on Java compile types yet but Kotlin and Swift have both suffered from slow compile times and this seems to be a factor. I'm guessing that most of the larger codebases out there will add "no var allowed" to their style guides within the next few years.
• filoeleven 5y ago
  The “keep readability in mind” tip exposes more Java/OOP icebergs. var date = LocalDate.parse("2019-08-13"); var dayOfWeek = date.getDayOfWeek(); var dayOfMonth = date.getDayOfMonth(); > The first one is pretty intuitive, the parse method returns a LocalDate object. However, for the next two, you should be a little bit more familiar with the API: dayOfWeek returns a java.time.DayOfWeek, while dayOfMonth simply returns an int. Java.time.dayOfWeek takes a TextStyle and a Locale, both of which have a list of properties and methods I have to read all about before using. dayOfMonth returns an int, and I can see if it’s 0- or 1-indexed then do what I want with it from there. Why does DayOfWeek have a class instead of being a function that I can throw a number at like dayOfMonth? I’m also skeptical about Java.LocalDate being “pretty intuitive,” having worked on local vs server vs data-store timestamps, as most of us have. At least LocalDate doesn’t have mutable setter methods like other Java dates…
  • xxs 5y ago
    >Why does DayOfWeek have a class instead... B/c in most of the world, the 1st day of the week is Monday, unlike the US where it happens to be Sunday. Having it enum is a pretty decent choice.
    • filoeleven 5y ago
      Sure, someone’s got to make a numbering choice somewhere for the canonical value. Same thing goes for timestamps, and we settled on UTC, so all offsets can be calculated given that. Once you know that “Java says X is the first day of the week,” you can make your own calculations from it with modulo arithmetic. There is no need for a class here, or for it to build a whole subsystem of locale interpretations. That should be the responsibility of a library. Maybe even the standard library, but it should not mask the core data values in the system by default. dayOfWeek(n) should be something that you apply to a value, not something that returns a value with no args based on your locale. Or, if it does, the function itself should accept an override locale instead of assuming it from a higher level. Timestamps are hard and maybe not the best example. It was what’s in the article though, and I’m also pretty salty about them after some recent work stuff.
• alkonaut 5y ago
  Does java have a decent story on value types now e.g can I make an ArrayList<long> and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.
  • bradleyjg 5y ago
    No. You can’t make an ArrayList<long> at all. You can make an ArrayList<Long> and trust the JVM to optimize as it may or you can use c++.
    • kjeetgill 5y ago
      You can mostly trust the JVM to not optimize this the way you'd want for primitives. ValueTypes are int he works though, and using a supplementary library for primitive specialization like Trove or fastutil have become the norm for now. Not ideal, but tolerable!
      • bradleyjg 5y ago
        If your application needs that kind of control, use a more suitable, lower level language. If you just want that level of control for aesthetic reasons, get over yourself.
        • kjeetgill 5y ago
          Java is that language though! It has primitives and primitive arrays and the language is built around many comfortable ways of using them compared to something "a bit more high level" like a python, javascript, or ruby; but you get to keep your compacting GC, chunky reflection, runtime introspection, compared to a C, C++ or rust. Primitives don't play well with the generics though, for decent enough reasons, so the standard library leaves out many conveniences that you can pull in as needed. Of course we're excited about them playing well together, but the sweet spot in the design space is still being worked out. We call that effort ValueTypes, lol. (well sorta. there's more to value types than just primitive specialization but i digress) I get that teasing jabs at java are always and fashion but consider that for many, it persists because it is a bit of a sweet-sport language. I think Go succeeds when it does for precisely the same reasons.
• p2t2p 5y ago
  Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and think that they know better than me what I need.
  • deleted 5y ago
    [deleted]
  • Groxx 5y ago
    Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems. "Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languages make it extremely painful to achieve, often requiring significant code rewriting, and which sometimes make contributing back to the source-library significantly harder. And when such hacks hang around longer for a week... well, sometimes that's fine, sometimes it's not, and the library author is not the one who should be making that decision. It's my program, it should do what I tell it to do.
    • Ericson2314 5y ago
      A sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.
      • Groxx 5y ago
        I think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.
• titzer 5y ago
  I used to really love Java, it was my second "real" programming language after C/C++, and GC, type safety, and object orientation really changed the way I thought. I also learned almost all I knew about high-performance VMs (up to 2013) in the context of JVMs. But these days it seems like Java is engaged in one long apology for the "everything is an object" mindset it started out with. It both took it too far and not far enough. Erased generics were the start of the problem. Parametric types! You were the chosen one! You were supposed to unify the primitive types and the object types! And never adding syntax for function types, just single-method interfaces...just ugly and clunky IMHO. C# did generics right. Well, almost. "void" isn't a real type, so you can't be generic over it. It is really important in language design that generics can range over any type. It allows the full combinatorial space. I worked really hard to make the Virgil compiler support arbitrary combinations of tuples, arrays, function types, and all of those work together seemlessly in the polymorphic type system. Everything else is a unfortunate shortcut, IMHO.
  • deleted 5y ago
    [deleted]
  • akra 5y ago
    Its not universal to all of .NET though. F# does support this (e.g. Task<unit>) because in F# every function has only one input and one output. Therefore it needs a unit/void type at the lang level at least. This simplification surprisingly results in more power and less code compared to C#. Its part of the base design of the language, and an example of something that is hard to change afterwards in future versions. In F# overloads for different amounts of type args to a function are not common, unlike C# with different types for each Func<T1, T2, T3, ... TResult> or Java with both Supplier and Function types and needing a custom function type for more args last time I checked. A use case that has come up for me would be to dispatch on variadic template args (e.g. loggers) in a typesafe way without reflection penalty, or looking at some of the libraries using overloads that could be reduced (especially in conjunction with inline for the value type overloads I suspect such as found in LINQ). When I see libraries with overloads for parameters like 'Func<T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,TResult>' I think of this. Wherever you see multiple overloads in C#/Java just for the sake of multiple generic arguments; that can often be simplified if required/worth it.