251–260 of 327 posts
Earlier quoted context omitted.
Which is why GraalVM requires you to explicitly mention what types should be available for reflection.
Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.
Earlier quoted context omitted.
I'd say that now with 15 adding records and instanceof pattern, Java 8 is finally looking pretty dated! You're also missing out on var and switch expressions, which are very visible features (as are records and instanceof patterns), so the difference should be obvious between a Java 8 codebase and a Java 15 one.
Var and switch were the biggest from Java 11, along with modules and the new GCs?
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…
> 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++ pro…
Earlier quoted context omitted.
Not considering async/await (because I'm not really a fan), they're neck-and-neck in my opinion. I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has; but in many cases you can almost compile a block of Java as C# and vice versa. I think the primary differentiator is what toolchain/ecosystem you prefer, and I'm solidly on the Java side of tha…
>I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has You say "careful", others would say "stubborn". The refusal to add things like operator overloading lead to a much less aesthetically pleasing language to read and write.
I recommend the "inside Java" podcast. Its from the java developer team at Oracle and worth a listen. https://inside.java/podcast/#:~:text=The%20Inside%20Java%20P... !
Earlier quoted context omitted.
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.
Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring? Time for me to learn so let me rephrase this question! Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?
Yes. And I don't just mean people doing Android development.
1) DI: Don't always need DI. For things like injecting values from config, it's really unnecessary given that we have very good control over production, down to building our boxes from a playbook. For things like mocks, plain old Java suffices -- you can roll your own (actually, someone in your team just needs to do it once and it keeps getting improved/forked). Guice exists as a fallback.
2) REST: Jersey + own libraries on top, Retrofit. Using Spring for REST is probably the poorest use for Spring, for me.
3) ORM: you can use "just" JPA. Don't always need an ORM either -- the strategy varies depending on the requirement. Although for some projects I have used Spring Data JPA because it seemed like the easiest path. At least Spring was localized to that artifact.
4) Lots of good OAuth2 libraries as well as things like pac4j. If you're wondering about Spring Security, it's definitely one to consider if you're doing lots of webapps in Java. But in a polyglot environment, a lot of Java code just handles APIs while node handles the UI.
Anyhow, this isn't to hate on Spring or anything -- I use it if it adds value. This is more about not taking the the complexity hit if you can help it. It also makes the code a bit more straightforward and readable.
Earlier quoted context omitted.
>Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly? because if you know exactly what you want to do there's no reason to settle for the second best thing. If you want F#, no harm with going exactly with F#. I talked to a bunch of Jane Street engineers once and the consensus seemed to be that Ocaml, despite its very small footprint,…
> actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier. Sounds like a strong case of selection bias. There is no shortage of people who are super enthusiastic about building really good stuff with good technology, and it's hard to believe that it's easier to hire Ocaml engineers than other la…
Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?
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
Still on Java 8 at work :-/
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.