[HN Gopher] Java 21 makes me like Java again
___________________________________________________________________
Java 21 makes me like Java again
Author : wscp-dev
Score : 123 points
Date : 2023-09-16 20:20 UTC (2 hours ago)
(HTM) web link (wscp.dev)
(TXT) w3m dump (wscp.dev)
| bedobi wrote:
| yawn, ok, only what ten years late?
|
| the sane members of the Java community have long since moved on
| from Java, and they're not coming back
|
| I say that as a Java dev with 12+ years experience (who now codes
| backends mostly in Kotlin with Ktor and Arrow)
|
| and in case anyone thinks this is just my personal opinion, well,
| it's not, Java is strictly objectively speaking a worse language
| for any given use case than its alternatives, the lack of null
| safety alone is game over
|
| this doesn't mean I love Kotlin and think it's the end of history
| of programming languages - I don't - I kind of hate Kotlins error
| handling and all the footguns in their coroutines library, but
| with Arrow, 99% of those problems go away and you have a damn
| near perfect general purpose language (that Java will never, ever
| catch up to or match)
| 1n3nt0r wrote:
| Let's not forget that the JVM still does not have reasonable
| generics & value types. The .NET CLR introduced this in 2005,
| bettering the JVM. Java was in a sleepy slow release mode back
| then. We've been waiting 18 years for value types and proper
| generics - Valhalla has been just about ready for a very long
| time. Some of us moved on a long time ago.
|
| Agree that Kotlin is a bright spot in terms JVM languages. For
| my taste has adopted some of the best concept of Scala, but
| without the burgeoning complexity.
| wayfinder wrote:
| Well when Sun imploded and Oracle stepped in, Java stopped
| getting regular releases for 10 years. Java versions literally
| came out every 2 years before Oracle happened.
|
| So that's why they're 10 years behind. But now they come out
| like 2+ times a year so they're on track making major progress.
|
| Also the null thing hasn't been an issue for over 10 years.
| Just use null annotations and both your static checker and your
| IDE will catch every NPE.
| bberrry wrote:
| As a Kotlin dev you should still be excited by virtual threads
| in Java 21. You'll never have to use coroutines again.
| jjtheblunt wrote:
| Is there an Ocaml vatiant for the JVM (similar to F# for dotnet)?
| satvikpendem wrote:
| I know of Scala for an FP variant but nothing that's ML-like
| specifically.
| iddan wrote:
| You could say Kotlin to some extent..
| gabereiser wrote:
| Outside of the enterprise there is no reason to recommend Java to
| anyone starting a project in 2023. I'm sorry. You can use it at
| work, with your gradle and maven builds, and your
| nexus/Artifactory repos of interfaces and impls. I don't care
| that you cut your hair to try to be cool. That you dyed your
| grays to say "Hey me too". You're old. You're not a fun
| experience. You focus on switch matching for 10 years and still
| force us to use Lombok. You introduce virtual threads but you
| still have threadpools and os threads. You are the current C++.
| No one wants to learn you, they are forced to. No one wants to
| program with you, they must to get paid. No one really enjoys
| debugging your call stacks and having to jmx into the vm host to
| determine if your catheter is leaking.
| cmrdporcupine wrote:
| This ... is how you make engineering choices?
| gabereiser wrote:
| At work, I have a different context. What is the common
| denominator of what people know. Personally, the "write once,
| run everywhere" notion of Java has been replicated with much
| more productive languages.
| cmrdporcupine wrote:
| Sounds like you're talking about a pop band, not a tool.
| kaba0 wrote:
| So which is the real programming language one should use in the
| God's year, 2023? (Will it change in 4 months also?)
|
| > virtual threads but you still have threadpools and os threads
|
| As opposed to what, quantum entanglement threads?
|
| > No one really enjoys debugging your call stacks
|
| Frankly, debugging has probably the very best tooling around
| the JVM -- so, what exactly is your chosen favorite that would
| be supposedly better? Or is objective reality not hyped
| anymore?
| riku_iki wrote:
| so, which lang would you use personally?
|
| > you still have threadpools and os threads.
|
| why this is a bad thing exactly?
| gabereiser wrote:
| Golang or Rust. If it's a web service or microservice: Golang
| hands down. If it's a desktop software or game engine, rust.
| If you just want to typescript your way to success, deno and
| vite. If you're too introverted for Rust, Zig.
|
| Java, whether it be spring, micronauts, jee, whatever, is
| wasting CPU and Memory in the cloud costing you and/or your
| enterprise money.
| riku_iki wrote:
| > Golang
|
| golang is probably a good contender for business logic code
| where Java is widely used, but I feel ecosystem (libs,
| integrations) is not comparable to Java, so you take some
| risks while choosing golang.
| kaba0 wrote:
| And it is much more verbose, it is not even comparable in
| observability and on real world big applications
| (especially enterprise) you can't get away with value
| types and slowing down the threads to let the GC keep up
| with them -- Java definitely shines in these kind of
| conditions (GC-wise the only competition Java has is
| different Java GCs, really).
| mongol wrote:
| I have not used Go generics, but it's viability as a
| business logic language would depend on that.
| riku_iki wrote:
| they have generics now, but there are other conceptual
| shifts:
|
| - no inheritance
|
| - error codes with explicit handling everywhere
| mongol wrote:
| Yes those are also drawbacks
| lukev wrote:
| Having worked extensively in Java, Node, and Python, I'll take
| the JVM ecosystem absolutely any day of the week.
|
| Me and my catheter will be over here delivering actual software
| while you figure out how React 32 broke your transcompiler.
| gabereiser wrote:
| Except I'm over here serving 10x the traffic with 10x less
| cloud spend on CPU and Memory for hosts.
| belter wrote:
| In what language would that marvel be? I give you the less
| memory....
| c048 wrote:
| Maybe you should upgrade from Java 1.4...
| mongol wrote:
| Exactly what is enterprise? I think Java has a role to play in
| most professional settings, even if the company is quite small.
| It is not a sports car but I see it more as a truck or a cargo
| ship. Vehicles that underpin the world economy, but that only
| few think of as fun or exciting. Not pretty or nice to look at,
| but reliable work horses.
| gabereiser wrote:
| It is for sure the wagoneer when it comes to getting things
| done in the enterprise, if it was 2005.
|
| It's not a sports car, it's not a dune buggy, it's not even
| pretty in its wood paneling and drab paint scheme. But it got
| your family to Wisconsin for the holidays.
|
| In 2023, we have better options.
| kaba0 wrote:
| Yeah, sure the thing that runs the whole of Apple, Alibaba
| infrastructure, many part of Google, most of that "cloud"
| infra is a wagoneer..
| mongol wrote:
| Such as...?
| pcl wrote:
| _> No one really enjoys debugging your call stacks_
|
| Of all the things to criticize about Java, this IMO is not one!
| A Java call stack is a joy compared to just about anything but
| Python.
| Tao3300 wrote:
| It's not so bad. I might be an old masochist with Stockholm
| syndrome, but every language has its own special flavor of
| barely tolerable bullshit.
| bb88 wrote:
| There is some truth to this. Every language I used had severe
| drawbacks. At this point, it's choosing the lesser of the
| evils.
| insanitybit wrote:
| The problems with Java can't be fixed by adding new things, you
| can't undo decades of ecosystem development, training, and
| ideology built on top of the idea that inheritance is really good
| idea and belongs everywhere.
|
| edit: I will say that as a Java developer I am grateful every day
| for the improvements to the language. Java is a very impressive
| language and I have a lot of respect for the people working on
| it.
| matsemann wrote:
| I rarely see inheritance used in practice in java code bases.
| Except where I would use a union type or sealed class in other
| languages anyways. I don't feel what youre describing is a real
| issue.
| xxs wrote:
| Inheritance used to be extremely common, look at AWT/Swing -
| however more or less it finished there, e.g. more than 20y
| back.
|
| There are still lots of folks who love 'protected' and deep
| hierarchies, of course. There is stuff like spring that uses
| way too many interfaces with a single implementation, doing
| something a bit off the regular road ends up implementing
| tons of the said interfaces anew.
|
| However the 'hate' part is mostly the internet (well esp.
| Hacker news)warrior topic
| sisve wrote:
| Great to hear. I used to program java in 2010 and
| inheritance was still beeing heavily used back then. But
| things change, if both the lang and the main community has
| change to focus more on simplicity its def worth looking at
| again. Coroutines and pattern matching is really good
| features
| insanitybit wrote:
| Contrast that, I've seen numerous Java codebases, young
| and old, and inheritance is very much one of the core
| ways that people program.
|
| I strongly suspect that in a few cases some Java devs
| using net new systems and avoiding common frameworks will
| perhaps be able to avoid lots of inheritance but I find
| it insane to say that that's common or even easy.
| sisve wrote:
| Sorry, what? Is not java toghether with Ruby maybe the most
| hardcore OOP enthusiasts that uses inheritance for "most
| stuff".
|
| Has the java culture move so far the last decade ?
| EdwardDiego wrote:
| Effective Java, written by Joshua Bloch, and first
| published in 2001, had a very influential section called
| Favor composition over inheritance:
|
| https://books.google.co.nz/books?id=Ra9QAAAAMAAJ&q=inherita
| n...
|
| Why do you think DI is so prevalent in Java codebases? It's
| a great way of simplifying composition.
| fuzztester wrote:
| >had a very influential section called Favor composition
| over inheritance
|
| The GoF book (Design Patterns) had the same, somewhere
| early, like in the Introduction, in 1994:
|
| https://en.m.wikipedia.org/wiki/Design_Patterns
| fiddlerwoaroof wrote:
| I've been writing OOP code and reading about it for a
| decade or two, and inheritance was identified as
| problematic pretty quickly. The problem today, imo, is more
| underuse now.
| kaba0 wrote:
| Funnily enough, it actually started from C++. And, Java is
| so large that it is simply meaningless to talk about a
| unified style -- sure, some Java EE behemoth will continue
| to run on a complicated Application Server for decades
| still, churning on its workload, but so will someone write
| a Micronaut microservice, or something for robotics, and
| these will all have distinct styles.
|
| With that said, even the Java EE/Spring complicated word
| has been moving towards a less inheritance-based future.
| dragonwriter wrote:
| Even in Ruby, IME, _deep_ inheritance is fairly uncommon.
|
| _Wide_ inheritance through mixins is common, though.
| insanitybit wrote:
| > I rarely see inheritance used in practice in java code
| bases.
|
| That seems absurd to me and I have a hard time understanding
| it, honestly.
| wayfinder wrote:
| If you type everything with interfaces in your codebase,
| you are much less tied to inheritance. In fact, everyone
| could be written to be composed.
|
| However Java doesn't support type union so you can get into
| some ugly and verbose situations but the JVM doesn't really
| check type so this is more a compile-time issue and could
| be fixed in a future Java language revision.
| logicchains wrote:
| >However Java doesn't support type union so you can get
| into some ugly and verbose situations
|
| Isn't the "sealed interface" described in the OP blog
| post a type union? Or you mean anonymous unions?
| wayfinder wrote:
| Definitely referring to anonymous unions too. Without
| them, there's still friction sometimes which makes union
| types unnatural.
|
| I haven't written Java in a while and I can't remember if
| you could sometimes fake a type union using a generic
| type on a method, but if you can, it's definitely super
| ugly and would raise eyebrows during any code review.
| Supermancho wrote:
| > I rarely see inheritance used in practice in java code
| bases.
|
| Without some specific call-out, it can be assumed that this
| is a very niche viewpoint that has no bearing on modern
| development.
|
| The vast majority of projects use inheritance, today.
|
| Does it use Spring? extends SpringBootServletInitializer
|
| Meaningful responses using values from a request? extends
| OncePerRequestFilter
|
| Formatting exception handling responses on web requests?
| extends ResponseEntityExceptionHandler
|
| Then there's all the interfaces you have to satisfy,
| because it's all tied into the standard library and popular
| libraries.
| richardw wrote:
| You need to inherit to create anything that is a class.
| But the focus is on composition. You inherit from useful
| classes so you can build the solution using composition.
|
| I don't like modern Java because there's too much non-
| Java magic code. Layers of stuff that "helps" but removes
| me from the language. Entire programs written in config
| and special text wrapping classes and methods. How it
| works requires understanding multiple intersecting
| languages that happens to be strung together in .java
| files.
| tail_exchange wrote:
| You must be really lucky then. In my previous job,
| inheritance and abstract classes were everywhere. Coupled
| with dependency injection frameworks that "worked like
| magic", it was really hard to follow the code inside that
| big, monolithic app. It made me never want to work with Java
| ever again.
| bb88 wrote:
| I've never been a big fan of dependency injection. It
| solves a problem with unit testing in Java, sure, but the
| reality is that Java could have done some nifty things to
| help alleviate that as well.
| hutzlibu wrote:
| There is nothing wrong with inheritance. But sure, there is
| usually something wrong with deep inheritance or using it,
| where better solutions exist.
| insanitybit wrote:
| No, there's a lot wrong with inheritance. It leads to all
| sorts of issues and while theoretically one can keep the tree
| 1 level deep, in practice it's too tempting to expand the
| hierarchy.
|
| This is one of Java's big issues. The other is reference
| equality as a default, pretty horrible. Records help but
| records are also limited in when they can be used.
| hutzlibu wrote:
| "in practice it's too tempting to expand the hierarchy."
|
| Not anymore, if you got stuck, by doing that once too
| often. But 2-3 levels can be allright as well. It depends,
| what you are doing amd with whom.
| belter wrote:
| You don't like code reuse?
| insanitybit wrote:
| That question seems blatantly disingenuous.
| akavi wrote:
| Love it, and love using plain ol' functions for it
| lelanthran wrote:
| > ideology built on top of the idea that inheritance is really
| good idea and belongs everywhere.
|
| Those are two different ideas.
| insanitybit wrote:
| I used the word "and" to indicate that, yes.
| wslh wrote:
| Please ELI5 what is wrong with inheritance and/or how Java have
| it wrong. Do we need to go back to a new object oriented
| undegraduate course? Genuinely asking.
| sirk390 wrote:
| With compositions A uses B but B can never use A. With
| inheritance Child can use the Parent, but Parent will also
| call the Child (virtual methods) which in turn can call the
| Parent again etc.., so the code can become difficult to
| follow. It can become very complicated with multiple
| inheritance and multiple levels.
| NickNameNick wrote:
| I've certainly done that in the past, but not since I
| changed jobs ... 7 years ago. Probably not for several
| years before then.
| insanitybit wrote:
| Inheritance provides "is a" relationships between classes. At
| a time when people would spend months designing their
| software upfront, building big diagrams of classes, etc, this
| was not so bad. You'd have a very clean system design that
| maps directly to your class design.
|
| The problem is when things change. A simple example - you
| build a classification of all life and it is built upon the
| idea that everything "is a" plant or animal. And then one day
| it turns out there are fungi. This is not a fun situation to
| deal with and inheritance makes it a lot harder because the
| "is a" relationship is driving a ton of your logic.
|
| IDK I don't want to get to into it beyond that, many people
| have written quite a lot on the topic.
| bb88 wrote:
| > This is not a fun situation to deal with and inheritance
| makes it a lot harder because the "is a" relationship is
| driving a ton of your logic.
|
| Judicious OOP design allows others to change behavior based
| upon needs that perhaps the original coder never thought
| of.
|
| I would not call most Java OOP design judicious. The
| control in Java is owned by the library writers and the
| language devs -- not the people using it.
| inglor_cz wrote:
| In cases of refactoring, inheritance seriously sucks.
|
| But it is quite advantageous when, as you say, your model
| is well thought out and stable.
| wayfinder wrote:
| This problem is partly a type system limitation however.
|
| In a more flexible type system with union types and other
| magical features, your example problem would be less of an
| issue.
|
| However Java has an extremely limited type system so there
| is no middle ground between composition and inheritance.
| Once you choose one way, there is no "middle step" to
| migrate over.
| kaba0 wrote:
| Union types are very rare (scala, typescript are the
| notable ones I can think of that implement it), most
| other languages only have sum types (which includes java
| as well, see sealed interface/classes), where you have to
| create each unique set of types you want to use
| separately, wrapping each option into a marker type
| basically.
| kaba0 wrote:
| > you build a classification of all life and it is built
| upon the idea that everything "is a" plant or animal
|
| With all due respect, this and similar examples are just
| plain wrong, and I really can't take anyone seriously when
| that example is used. The point of programming, and its
| abstractions is to help you _complete a task_ , and make
| the implementation maintainable and easy to reason about. I
| think grabbing the "is a" part is fundamentally bad --
| there is no point in creating a taxonomy in and of itself,
| this is no database for that data. Inheritance sometimes
| _is_ the correct abstraction and while it is definitely
| overused, when it 's correctly applied there isn't really
| another abstraction that would fit better. E.g. see a
| graphics library's Node class as the stereotypical correct
| application.
| insanitybit wrote:
| I think your post can be broken down into two main
| points.
|
| 1. That my point is bad for some reason
|
| 2. That inheritance is sometimes a great tool
|
| We agree on (2). Inheritance is pretty amazing, even if I
| think that it's ultimately a terrible feature to build so
| ingrained into a language and to expand in power to such
| a degree.
|
| As for (1), I don't really get your point. Abstractions
| help you complete a task - ok. Abstractions are to help
| you reason about stuff - ok. Something about "is a" being
| bad? None of that really explains why my example
| demonstrates the problems you run into when you try to
| build a classification of values using inheritance. But I
| also said that I wasn't going to really try to explain
| much, it's been written about plenty.
| kaba0 wrote:
| Prefer composition over inheritance has been a common mantra
| for at least a decade, if not more. Maybe you should undergo
| the last decade of development and training.
|
| There will always be shitty devs, and since java is one of the
| biggest languages, it definitely has more than some ultra niche
| academic language no one uses. I don't think it is the fault of
| the language though, or if that somehow were a reason to choose
| a different language. Should a decent BMW driver sell their
| car, because plenty assholes buy that car also?
| insanitybit wrote:
| Just because everyone has been saying "composition over
| inheritance" doesn't mean that that's how things get done.
| Jump into any Java codebase and you're 99% likely to see
| inheritance used as one of the primary abstraction
| mechanisms.
|
| > Should a decent BMW driver sell their car, because plenty
| assholes buy that car also?
|
| A better analogy would be "Should you drive on the street
| where all of the shitty drivers do donuts and street races?"
| KillenBoek wrote:
| The problem with Java is not Java. It is Oracle and no amount of
| new features is going to fix that.
| ant6n wrote:
| But, you know, Java too.
| riku_iki wrote:
| I am wondering if Oracle is really playing significant role in
| Java evolution, they have some open process with many other
| companies contributing.
| logicchains wrote:
| I can't wait 'til Project Valhalla is complete and Java finally
| gets value types. Then with sum types, value types and goroutines
| it'll be one of the nicest languages out there.
| kaashif wrote:
| Nice article as someone familiar with sum types but not sum types
| in Java.
|
| I don't know if sum types alone are enough to get me to like
| Java, pervasive nullability is still around and even rears its
| head multiple times in this article.
| leapis wrote:
| Nullable is a huge issue in Java, but annotation-based
| nullability frameworks are both effective and pervasive in the
| ecosystem (and almost mandatory, IMO).
|
| I'm really excited about https://jspecify.dev/, which is an
| effort by Google, Meta, Microsoft, etc to standardize
| annotations, starting with @Nullable.
| wayfinder wrote:
| I hope they succeed. So many people have tried.
| kaashif wrote:
| This can never be as effective as changing the default
| reference type to be not nullable, which would break
| backwards compatibility, so you can never really relax.
|
| I know Kotlin is basically supposed to be that, it has a lot
| of other stuff though, and I haven't used it much.
| pharmakom wrote:
| It's also not expression orientated yet.
| northern-lights wrote:
| The biggest feature in Java 21 is the release of Virtual Threads:
| https://openjdk.org/jeps/444
|
| For some reason, this is missing from the article. If there was
| any feature that would sway existing Golang developers to switch
| to Java, it would be this. It would perhaps also convince the
| haters of the reactive-style concurrency patterns.
| mongol wrote:
| I wonder what will happen with these patterns now. They seem to
| have been invented to work around the problems with regular
| threads. Will new patterns emerge, or will the reactive
| patterns be ported to run on virtual threads?
| bberrry wrote:
| The reactive patterns are now obsolete and will die. And good
| riddens I say.
| insanitybit wrote:
| `Executor.newVirtualThreadPerTaskExecutor` versus `go` really
| gets to the heart of why I think that Go developers aren't
| going to be switching.
|
| edit: Sorry, it's actually: try (var executor
| = Executors.newVirtualThreadPerTaskExecutor()) {
| executor.submit(...) )
|
| instead of `go`
| kaba0 wrote:
| So basically executor.submit(). And you still have a language
| that is significantly _less_ verbose than go, objectively.
| insanitybit wrote:
| Yes, if you ignore more than half of the code it's quite
| concise.
| ivan_gammel wrote:
| Wrap it in class Go { static void go(...) } and it will look
| better with "import static"
| insanitybit wrote:
| I assume `Go` would have to be Closeable and you'd still
| need the try-with-resources, right?
| [deleted]
| erik_seaberg wrote:
| You're likely to need a lot of boilerplate that "go"
| statement won't generate: pass and wait for completed
| results, report errors, timeouts, cancellation, bounded
| parallelism, pushback, service monitoring.
| insanitybit wrote:
| My comment is perhaps too glib. I'm not trying to say that
| Go is better, I frankly like Java more. I only mean that if
| I'm in a Go mindset and I read the linked document on
| virtual threads, and I see that code example, I'm going to
| close the tab.
| jayd16 wrote:
| I don't think Golang devs are waiting to switch to Java if only
| making a lot of threads was easier.
|
| Honestly, its way too early. Virtual Threads will need a a
| "killer app" (in this case a killer framework) to pull in devs.
| acheron wrote:
| In other news, we have an upgrade path at work to go from Java 8
| to Java 11 pretty soon.
| taf2 wrote:
| do/i/still/need/to/create/sub/directories/for/the/things/i/want
| /namespace?
| mdaniel wrote:
| Only if you're using vim like someone from the 70s, otherwise
| any sane IDE handles those things for you
|
| But, yes, namespaces are still mapped to paths, it's not like
| they rewrote the JVM to use blockchain or something
| ttyyzz wrote:
| Yeah I really like my IDE doing stuff in the background
| without me knowing shit about it.
| piva00 wrote:
| Yeah, I do like my IDE doing the tedious work for me.
| It's also really nice to unzip any JAR I need to
| troubleshoot and know exactly where to navigate to find
| exactly the file with the code I need.
|
| I like Golang a lot but the standardisation and verbosity
| in Java-land has some benefits after you get used to it
| enough to learn to ignore the boilerplate, it's pretty
| good to have some kind of consistency enforced by the VM
| when working in large codebases.
| [deleted]
| kyawzazaw wrote:
| 8 to 17 for us
| MBCook wrote:
| We ( _finally_ ) upgraded last year from 8 to 17. Lots of nice
| things, I'm so glad we were finally able to. But it was a big
| project due to some dependencies and how some things were done
| internally.
|
| I can't wait for 21, but I'm not sure when we'll switch. At
| least it will be trivial compared to leaving 8.
| hmottestad wrote:
| Going from 11 to 21 is a lot easier.
| leapis wrote:
| Depends- one of the hardest parts of the 11-20 upgrade for us
| was that cms gc was removed.
|
| If you run a bunch of different microservices with distinct
| allocation profiles, all with high allocation pressure and
| performance constraints, and you've accomplished this w/ the
| help of a very fine-tuned CMS setup, migrating that over to
| G1/ZGC is non-trivial
| bberrry wrote:
| I can't help but think if you're teetering on a knife's
| edge, only holding on thanks to hyper tuned GC params, then
| you should take a step back and consider getting our of
| that predicament.
| hmottestad wrote:
| Is that what happened at your company?
| leapis wrote:
| Yup. We've clearly benefitted- G1 and generational ZGC
| have large advantages over CMS- but it's a lot of
| experimentation and trial-and-error to get there, whereas
| other deprecations/removals are usually easier to
| resolve.
| kaba0 wrote:
| Isn't the default config correct for pretty much all
| workloads, unless you have _very_ special requirements?
| Like, at most one should just change the target max pause
| time in case of G1, depending on whether they prefer
| better throughput at the price of worse latency, or the
| reverse.
| xxs wrote:
| Java sort of suck for microservices (microservices suck on
| their own) as it has relatively high bootstrap cost.
|
| High allocation rate feels weird with micro services - I
| suppose that depends a lot on the coding style. G1GC is
| meant for generally large setups, with several cores at
| least. E.g. the default setup of 2048 areas on 2GB heap
| means, allocations over 1MB require special care.
| Horffupolde wrote:
| Can you convince me to use Java? I've never used it (only C++,
| Python, CL) but it feels bloated and dirty.
| whartung wrote:
| I'm a fan, long time fan, but I can honestly say that I feel
| Java is one of the most pragmatic development systems on the
| planet.
|
| It can do most anything. It can do it most anywhere. And you
| can code in it using several different paradigms.
|
| It's easy to install, it's easy to be instal several versions,
| the footprint, by today's standards, is not enormous.
|
| It's easy to deploy, especially server side. While you can
| certainly do all of that modern stuff with containers and what
| not, it's not really necessary for Java. Drag and drop a JDK
| install, anywhere. Plonk your Java server code, anywhere, and
| point it at your JDK, and. . .that's it! Fire it up. The JDK is
| remarkably light on dependencies.
|
| And since most Java apps are "pure Java", the apps rarely have
| a dependency outside of the JDK. And since Java apps routinely
| bundle their Java dependencies, the apps don't stomp on each
| other either. Even SQLite bundles it's binaries in the Java Jar
| file. So wherever that jar goes (again, and typically bundled
| with your app), SQLite goes. No floating dependencies.
|
| Desktop bundling requires a bit of search engine research, but
| it's doable. And the runtimes can dwarf something like Electron
| installs.
|
| As a language is Java ELEGANT? Not particularly. It has its own
| elegance in some areas but that can break down or get overrun
| in others.
|
| But, boy howdy, it sure is practical. The ecosystem is so huge.
| It compiles really fast. I marvel at the stories folks tell
| about their dev cycles in other languages. How do they get
| anything done, besides sword fighting?
|
| I love Java, but I'm very comfortable in it. But the Maven
| based dependency system works, it's huge, it makes use and
| reuse simple. The IDEs are powerful and mature.
|
| And, finally, Java's not dead. Hardly. Oracle has been a
| surprisingly good steward (with warts, as always). The language
| has been on a rocket of development and shows no sign of
| slowing down. Server side is still very hot with all the
| frameworks and all the different approaches. Things like
| GraalVM taking the JVM in a whole new direction.
|
| And, yea, that. I've only been talking Java the language, not
| the JVM itself per se. That's a whole other thread.
| belter wrote:
| None of the memory problems of C++, the speed of C++ most of
| the time. Thousands of high quality libraries, a JVM that is a
| marvel of engineering after 20 years, tooling for development,
| monitoring and introspection of exceptional quality. Many of
| the internal tools at the largest Cloud developed in Java. Most
| enterprise level software. NASA extensive use of Java. A team
| behind the development who has stunning common sense in
| resisting the latest fads. Support for IEEE 754 that took
| years. AOT compilation...The infra behind most internet banking
| sites out there. Use in high speed trading.
|
| What else do you want from the ecosystem?
| loxias wrote:
| > None of the memory problems of C++
|
| Every time I see something like this I roll my eyes... C++
| doesn't have any "memory problems".
|
| There are sometimes _human_ problems, such as thinking one is
| capable of coding without understanding the (basic
| programming) concept of a pointer. But that 's because the
| human's dumb, not a language problem. (This argument also
| sometimes comes from those who _do_ understand basic
| programming, but are only familiar with C++98.)
|
| > Thousands of high quality libraries a JVM that is a marvel
| of engineering after 20 years
|
| I reluctantly have to agree. :)
| inglor_cz wrote:
| "But that's because the human's dumb, not a language
| problem."
|
| If everything is the programmer's fault for being dumb,
| then Brainfuck is an excellent system language.
| hutzlibu wrote:
| What would be a modern IDE for Java?
|
| I remember programming Java in Eclipse. And it was powerful
| for the time, but everytime I read bloated, I automatically
| think Eclipse since then..
| jayd16 wrote:
| IntelliJ is very good.
| belter wrote:
| https://www.jetbrains.com/idea/
| mdaniel wrote:
| and also FOSS (Apache 2):
| https://github.com/JetBrains/intellij-community (as well
| as PyCharm found in the "python" subdirectory)
| gabereiser wrote:
| >" None of the memory problems of C++"
|
| I'm sorry, I'm calling BS here. You can still leak memory in
| Java.
| ndr wrote:
| Isn't that true in any language that lets you allocate
| memory?
| c048 wrote:
| Shitty code is shit in any language. What's your point?
| vlovich123 wrote:
| You can leak memory in any language. That's an impossible
| bar. The problems op is referring to is obviously about
| memory safety.
|
| Java obviously isn't thread safe like Rust is, but it's
| typically safer than C++ on that front too.
| gabereiser wrote:
| Rust isn't thread safe either. It's borrow checker will
| attempt to correct you but you can still run Rust
| unsafely.
| matsemann wrote:
| What's dirty is trying to get a python project reliably running
| on all dev computers. Pyenv, venv, wheels, suddenly you need a
| complete rust or c toolchain etc. With java I haven't had those
| kind of issues the last decade, it just works. With python it's
| still a big hassle and everything breaks every update.
| jessekv wrote:
| To be fair, getting all those scientific library binaries
| compiled and installed was a huge pain even before python
| came around. Python's toolchain made it better, but only
| marginally in some cases.
| cbarrick wrote:
| Throughput in Java can be quite high, and latency can be quite
| low. You still occasionally get latency spikes from the GC, but
| these days that's not so bad. (If you are _extremely_ latency
| sensitive, stick to C++).
|
| Dependency injection frameworks are your bread-and-butter in
| server-side Java, and some can take a while to grok, but Java
| can be very productive after the chosen framework "clicks" for
| you. Typically, this means you'll be writing constructors or
| factory classes that construct your dependencies per request.
| The way you wire your factories into the system differs by
| framework, but it often involves using Java's annotation
| syntax.
|
| Not having to worry about memory management is a huge win for
| productivity over C++. Likewise, constructors in Java are much
| more sane than in C++.
|
| Classical object-oriented programming is intuitive, and Java
| tends towards the "one obvious way to do something" paradigm. I
| find it pretty easy to hop into legacy code bases, if I already
| know the framework being used. The collections API in the
| standard library is one of the best classical OO APIs out
| there.
|
| The JVM provides great visibility into the performance of your
| system. A lot of instrumentation comes "for free".
|
| I'm not sure where you get the "dirty" and "bloated" feeling
| from. By any definition I can think of for those words, Python
| would be in the same bucket.
| riku_iki wrote:
| > Java can be very productive after the chosen framework
| "clicks" for you.
|
| you can chose to not use DI frameworks at all..
| Horffupolde wrote:
| Yes, I agree that Python can feel "dirty", although not
| necessarily "bloated."
| zapnuk wrote:
| What feels bloated and dirty?
|
| Because there is plenty of bloated and dirty stuff in C++ and
| Python too.
| hmottestad wrote:
| You don't have to use Java. All the languages you've mentioned
| are fine. If you think that using Java to solve a particular
| problem is a good idea, then you should definitely use Java.
| justrealist wrote:
| How could you possibly like C++ but feel that _Java_ is
| bloated?
|
| Like I academically understand disliking Java but this just
| makes no sense.
| deaddodo wrote:
| I mean...Java is run through a VM while C++ is compiled to
| native code.
|
| I can see that being used as a reasonable argument for bloat.
| Jensson wrote:
| C++ allows for much more terse code than java when you do
| small projects. It is popular in competitive programming for
| that reason, not just because it runs fast but also because
| it is really fast to write algorithms in it.
| jjnoakes wrote:
| I think of Java as more bloated than C++ at runtime - with
| C++ I can make smaller executables that start up faster, use
| less memory, etc.
|
| But if you are talking about the source code itself, then
| things are quite different.
| loxias wrote:
| ???
|
| I'll answer your question with a question: Have you seen http
| s://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... ?
| :)
|
| I'm guess that to those of us who remember when Java came
| out, "FizzBuzz: EE" is what we think of when we think of
| Java. :P
|
| In Java I have to type a bazillion characters to get anything
| done! And make all these useless directories and files and
| InterfaceClassFactoryProtocolStreamingSerializer BS. And
| worry about how that executes.
|
| C++? No bloat*, just speed
|
| *Yes, there's some _optional_ bloat. But compared to Java? no
| contest.
| bcrosby95 wrote:
| When java came out? So mid 90s c++ vs mid 90s java?
| [deleted]
| OJFord wrote:
| I think people are understanding 'bloated' differently.
|
| I agree C++ is bloated in a 'just make it a setting' / 'add
| this feature' / 'kitchen sink' sort of way.
|
| I agree Java is bloated in a boilerplate, empty directories,
| maybe except for another directory, 'oh god the boilerplate'
| sort of way.
| loxias wrote:
| > I agree C++ is bloated in a 'just make it a setting' /
| 'add this feature' / 'kitchen sink' sort of way.
|
| Interesting. Can you expand on this, explain more? I
| honestly don't know what you mean or are referring to --
| and I'm a heavy modern c++ advocate -- but suspect if I did
| it might expand my mindset/viewpoint a bit. :)
| OJFord wrote:
| Honestly I haven't actually used it since C++14 was new,
| but it's a common complaint IME that each 'edition' (as
| Rust would call it, I don't know remember the term,
| standard?) adds too much, there's too many ways of doing
| things, variations of pointers, boost, and so on.
|
| I think a lot of people wish it had stayed at say C++7, a
| mature C superset, but that's enough now. I probably
| should have said 'I understand' rather than 'I agree' - I
| don't feel strongly, I don't use either of them.
| loxias wrote:
| Ohhh, I get what you mean now, thank you! I understand
| (and mildly disagree). :)
|
| Yeah, C++ is a living language, I can respectfully see
| that bothering some people. I viewed c++98->c++11 as
| essentially a new language with c++14 and c++17 being
| "bug fixes" for the "new language" that is c++11. But
| certainly, it can require more learning about every
| decade now.
| Blackthorn wrote:
| Bloat is a meaningless word. One person's bloat is another's
| essential.
| xyst wrote:
| Big firms I have worked at still using Java 8.
|
| Dead.
| Phelinofist wrote:
| We have an app that also needs to be able to run on Android, so
| we are held back by the shitty Java Google implements for
| Android.
| tleilaxu wrote:
| I agree that many companies are "stuck" (through their own
| choice really)... but at least Java is moving now.
|
| In many ways Java's boringness is a feature that keeps it
| easily maintainable, at a low - easily recruitable - skill
| level.
| avbanks wrote:
| A lot of Apache projects still use Java 8 :(
| bombcar wrote:
| At least you can now run Minecraft 1.7.10 on Java 17 -
| https://github.com/GTNewHorizons/lwjgl3ify
| mathisfun123 wrote:
| any advice on a book/tut to learn "modern" java?
| aranchelk wrote:
| > Why do we call them product types anyway?
|
| Answer in the piece is not wrong, but put more intuitively and
| succinctly: the total number of possible value (inhabitants) in a
| product type is the product of the quantity of inhabitants of the
| constituent types.
|
| Replace the "product"s with "sum"s and it works too.
|
| Interestingly, the total number of unique functions (judged only
| in terms of input and output) from a -> b can be found by
| exponentiation, (inhabitants of b) ^ (inhabitants of a).
___________________________________________________________________
(page generated 2023-09-16 23:00 UTC)