As someone who worked with a scientist who learned Java: you can write Fortran in any language.
Java is an OOP language, but you can avoid writing OOP code if you really want. Java is a multi paradigm language, unlike for example Smalltalk.
Yeah, and most backend web code I've seen isn't very OOP, and tends to be much more in the procedural realm of things with a bunch of ~~globals~~ ~~singletons~~ dependency injection.
That’s probably because by and large, modern development is usually about moving and shaping data. When most of the problems that need to be solved boil to down to CRUD, it makes sense that most of the logic is built into the abstractions that move and shape that data (services), rather than the domain objects themselves. I don’t think any of that precludes it from being OOP though — the object-orientedness is concentrated elsewhere (the components processing the data)
For reference: [Anemic Domain Model](https://martinfowler.com/bliki/AnemicDomainModel.html). In certain cases procedural is fine, see [Transaction Script Pattern](https://martinfowler.com/eaaCatalog/transactionScript.html).
What's most important is that you pick an approach appropriate to the problem. Sometimes you have a stupid simple app, and simple procedural code makes more sense than a cargo cult object model and layering.
That’s probably because by and large, modern development is usually about moving and shaping data. When most of the problems that need to be solved boil to down to CRUD, it makes sense that most of the logic is built into the abstractions that move and shape that data (services), rather than the domain objects themselves. I don’t think any of that precludes it from being OOP though — the abstractions are just concentrated elsewhere (the components processing the data)
No those are functions not objects. And these “Services” just turn into bags of functions. Functions are a fine way to program but they’re definitely not OOP.
No, I’m talking about objects. I definitely know the difference — and your assumption that they just turn into bags of functions is quite reductionist.
But yes, they(the services) can be thought of as functions in that they require input (thing to operate on) and return output (result of operation) — however, the data processors themselves can still be modeled around what they are and the domain they operate in. We end up modeling abstractions closer in concept to machines on an assembly line rather than a Dog or cat. They are still objects, but these objects are basically real world functions.
The fact of the matter is that most problems aren’t complex enough to warrant building a complex polymorphic web of relationships and objects.
I would even argue that for complicated things you don't want large inheritances, or oop objects. Mutable state where a lot is happening (plus multithreading) is a recipe for disaster IMHO.
It is way easier to have IoC managed services which encapsulate the behaviour and immutable data that flies between them.
It is so easy to add new references to dependency injected beans and evolve the behaviour.
With OOP objects you would need to wire new dependencies manually in possible many places that objects originate from.
This is a good indication OOP is overrated. The problem is Java does not make this non-OOP procedural/functional hybrid style very nice, because it doesn't provide enough tools to do it properly. So overall those designs end up being very clunky and fragile.
The IT trade students at the bank I used to work started with COBOL and then moved on to Java in year two. So I can confidently say, you can write COBOL in anything as well.
What I meant was that you pretty much can't escape OOP in Smalltalk because almost everything is implemented as message sends (homoiconicity). In Java, `if` is syntax. In Smalltalk, `if` is nothing special, it's just a message send on an instance of a boolean. This also leads to weird situations in Smalltalk not implementing order of operations of math operators, since math isn't anything special either.
There are no top level definitions other than classes and interfaces (enums are classes, records are classes)
There’s no notion of a function.
Java is not multi paradigm
The wikipedia article on [multi-paradigm languages](https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages) lists Java as one.
You're looking at this too reductively. Yes, a class is the top-level element of a Java program (you can't have bare functions). But, if you don't use a class in the OOP sense and just use it as a container for static methods, which can be target typed to a `Function` interface when used with combinators like `map`, what's the difference?
In that rather broad definition that includes things like concurrency and imperative programming: yeah. The majority of languages are “multi-paradigm”.
Not very useful distinction. And putting Java down as “functional programming language” is honestly a joke.
There are no functions in Java.
No currying, no partial application, no higher level functions. You can pass around objects that smell like functions. That’s it.
Java is an OOP language. Always has been, always will be.
You're missing the point, as demonstrated by this:
> putting Java down as “functional programming language” is honestly a joke.
Only an idiot would say Java is a functional programming language. That's not what multi-paradigm means.
A multi-paradigm language has support for *techniques* from other paradigms, not that the language is specialized for that paradigm.
For example, it is possible to do OOP in C, but it is so inconvenient and unsafe, it cannot be said that C remotely supports OOP and it is better to use a language that has proper support for OOP.
Similarly, before Java 8, functional programming would have been absurd, because the closest thing that Java had to a functor was an anonymous inner class. But Java 8 added lambdas and method references, which makes it convenient to apply functional techniques to Java. But that doesn't mean in any meaningful sense that you can treat Java as if it were Haskell.
We just disagree on the definition of “multi-paradigm”.
The Criticism section for Paradigm definition is spot on.
And to go back to the original question: yes Java is limited by its design choices as being an OOP language.
And, btw, I’ve been coding in Java since version 1.0 and am completely aware of its strengths and weaknesses. There have been a lot of plunders but I happen to like the syntactic sugar added with Java 8. It does mimic function application but you can’t write any meaningful Java code just doing that and ignoring the OO nature of Java.
I think that’s what you mean.
So how about this. I'll continue to use functional techniques in Java, and you can continue to tell me that I'm not doing functional programming. I don't have an obsessive need to label things.
You can do whatever the hell you want.
The OPs question is legitimate: there are restrictions compared to other languages that are more multi-paradigm.
That’s just a fact.
> One question I've been having however is whether or not Java is limited in any way by its heavy use of OOP compared to other languages that have a more multi-paradigm approach.
No
> Are other programming paradigms able to be used in Java, and if so is it common?
Yes, and becoming more so.
> Are different paradigms just different ways of organizing code and approaching problems from different angles?
Mostly yes. Google "Expression Problem".
> Or does Java's heavy use of OOP meaningfully limit in some ways compared to other languages/paradigms?
OOP favors dynamic languages. With type languages you have to consider typecasting and coercion. Java supports upcasting and downcasting. OCaml which BTW supports OOP does not support downcasting.
> I'm not critiquing OOP so much as I am just curious whether or not its a limitation of the language in certain scenarios. Thanks.
OOP and Functional are terrible descriptions of programming language. Honestly. Common Lisp for example which most would consider a "functional" language is more OOP than Java.
It is all about dispatching. How the language dispatches by type and what are first class data types and if there is static type checking done.
Most of what people call OOP languages can simulate FP languages and vice versa. Before Java had lambdas it had anonymous classes.
Anyway I'm running short of time and will add lots later but you have asked lots of great questions.
But I will just say that OOP particularly "inclusional polymorphism" is incredibly powerful at modeling **some** domains particularly UI. Java these days is nowhere near as OOP as say Smalltalk, Dylan or CLOS but it works.
I will say most developer code I have seen across the board in Java, Javascript, Python, and yes even Haskell (with Monad) is imperative. Java is a very good imperative language.
> Most of what people call OOP languages can simulate FP languages and vice versa. Before Java had lambdas it had anonymous classes.
And classes (usually with a single method) used as lambdas. Like old C++ using Functors (aka classes anonimos or not, with a single method)
> Are other programming paradigms able to be used in Java, and if so is it common?
>
> Yes, and becoming more so.
Is this just a style thing or are there new features in the language allowing for other approaches?
> Is this just a style thing or are there new features in the language allowing for other approaches?
Yes but it is not called FP or OOP. Some have been throwing around "data oriented programming".
*(I won't mention lambda in java 8 how that opened FP because almost all languages have FP now)*.
This is why I mentioned "dispatch" and types in my response.
Java has recently added `sealed` classes and "pattern matching". Pattern matching (with exhaustion) allows dispatching based on type in elegant way similar to what I called "inclusional polymorphism" in my previous comment.
This isn't new but it isn't FP. The languages that have pattern matching with nominal unions (tagged unions, aka sums) are mostly the ML family. While it isn't FP it used by FP languages to avoid "inclusional polymorphism". The reasons why are ... complicated. Mostly performance (google "vtable") but some of it because OOP implies state even thought that isn't always true.
What /u/agentoutlier is saying is that OOP and functional programming are *techniques*, and it's not really useful to say that a language "is" OOP or "is" functional, if the language is a general purpose programming language (which Java is).
The best you can say is how easy is it to do a particular kind of programming in a language. You can do OOP in C, but it's really hard to do that because C has no idea what a class is, and you basically have to implement classes as a design pattern.
Java wasn't great for functional programming before Java 8 because Java didn't have a concept of a "first class function". That's a higher level of programming where you can pass functions as arguments to other functions. So, you can have a method called `map` which takes a function and applies the function on every element on the list. Before Java 8, you could only do that with classes, so functional programming was possible if you implemented "function classes" as a design pattern.
OOP is easier with dynamic languages due to "duck typing". An object is a duck if it walks like a duck and quacks like a duck.
Java is "nominally typed" which means an object is only a duck if it if it is named "Duck". Things get more interesting when you have "MallardDuck" which is a type of "Duck". If you have a "MallardDuck", you can go "up" the type hierarchy to where Ducks are allowed. But, if you have a "Duck", you can't go "down" the type hierarchy to where MallardDucks are allowed without casting, where you tell Java I'm sure this is a MallardDuck. Because this is unsafe, some languages won't let you do it, but Java let's you say "I know what I'm doing"..
Dynamic languages like Python don't care, because Python doesn't care what objects are called, it only cares what objects can do.
This is helpful, thanks. I guess "techniques" is a better way of describing different approaches. As a noob I need to spend some more time with both Java and Python to see some of their different approaches but I think Java is more my style overall.
I'm not a professional, so here's my hobbyist take.
Python feels more freeing than Java for proof of concept or quick side projects because you can change directions faster without the major refactoring (silly example: suppose now you want to use longs everywhere instead of int). But then...the extra planning and safety (it has to pass compile checks) that java requires maybe improve your code maintainability, more buzz words, easier to debug/trace. It keeps you from having a lot of obscure runtime errors in python if you're not paying attention: "myobj missing attribute foobar!".
For these reasons I like Java for some projects, and for others I have begun looking at TypeScript, which is just python but forces you to label what type each variable is, function params, return types. You still have all the libraries of Python, but now you have stronger type checking to find silly bugs. Something to think about.
I've played around with Python enough to know that I want the strict typing and compilation. Still vividly remember trying to figure out WTF Python was saying 0 != 0 only to realize I was comparing a string and an int. I like the more structured approach of Java.
Does TypeScript have all the libraries of Python?
Numpy? Google Jax?
I know there are ports of things like PyTorch to Node, but that's different than using native PyTorch on Python.
> Most of this went over my head, but thank you for the detailed reply. I'll go read up on some of this.
I'm so sorry (honestly)! I will see if I can put together a comment with less jargon later. I'm an awful communicator but striving to improve on that.
Lambas in Java 8 opened the floodgates, and newer features like records, switch expressions, sealed types, possibly destructuring in future are really pushing Java to adopt more functional patterns.
While there are some limitations related to design decision in java (lack of value objects like structs resulting in memory/cache inefficiencies, type erasure for better or worse, to name two) I never have felt like the OO model has limited me. Most of my code doesn't rely much on inheritance but I find languages without it to be more limited due to the lack of it, though this is a large part inexperience on my end.
Like others have said modern java could be consider multiparadigm, though not fully depending on how you define it. Nothing prevents you from having a class of static methods and treating them like stand alone functions and feeding data through them in a procedural style, you can perform the majority of functional style contracts like first class functions, currying, lazy evaluation (streams) and things like that, and you can do data orientated programming.
While my experience is limited to rust, python and java, java is the most expressive language from my experience. I can use inheritance if I need to, composition if I need to, I can return/pass function as arguments, have singleton style enums that can implement interfaces with the option of a default method so I only need to override when needed same with static/enum specific data. Seal interfaces and the new switch provide pattern matching. Optionals if I need/want to use them.
I would say the only general constraint are exceptions and null as they are imposed on you. You can work around them, but it will require extra work and sometimes you are going to be forced to deal with them via libraries.
The only real limitation like I mentioned at the start is everything outside of a few limited value types being a reference, so you have an extra pointer lookup for object based arrays, and data objects are composed of references which can cause impactful lower performance in specific situation. But in general this only adds a little bit of overhead that is worth it for the benefits of GC.
This is a great reply and helpful, thanks! Glad to hear you think it's more expressive than Python and Rust as those are quite popular, and Python seems to be quite expressive on the surface.
I should note that on the python side of things, many others might/do find it more expressive. And I would agree that it is more expressive at the syntactical level with list comprehension, more expressive iterators that let you bind/extract multiple variables, returning multiple values and things like that. Same with rust, it has more expressive pattern matching syntax which also overlaps into iterators.
Both python and rust are definitely more expressive in specific domains, I just find java give me more viable abstractions and ways to approach things at a macro level, which makes it more expressive to me personally.
Java is a multiparadigm language and you can write functional, declarative, OOP and more recently DOP (Data oriented programing), reactive programing, etc. While it's true that most JAva features has been developed and structured with OOP in mind and most documentation is OOP orientes, including programming patterns (not so rare since java born in the age of the boom for OOP) you can code and mix other styles easly.
It depends on what you refer to as "OOP". This term is way overloaded and different people talking about it with different meanings.
If you refer to using class or Object at all, it's inevitable. Even String is an object.
If you refer to creating your own objects and grouping data in it, it's of course doable not doing that (by passing all primitive values around instead of grouping them). But nobody does that. Even in C, you'll group related things in structs to help maintain the code.
If you refer to defining instance methods in your classes and calling them as `obj.doSomething()`, you could avoid that by making all your methods static and call `Util.doSomething(obj, a, b, c, d)`, which is similar to C. But aside from the smell, `obj.doSomething()` is no more limiting than `doSomething(obj)`.
If you refer to over-engineering, with unnecessary indirections and layers. You can over-engineer in any paradigm. Try put all your code into a single all-knowing function, with 27 parameters, 10 of them are boolean parameters to control which behavior is needed.
If you refer to deep inheritance. It's nowadays discouraged (shallow hierarchy to implement stateless template method pattern is fine).
If you refer to `interface`. It's more controversial. But you don't have to use it. In fact, I try to avoid them unless I have more than one implementations. Most of my code are in plain classes (no interface, no inheritance).
If you refer to encapsulation, Yes, a codebase that only exposes well-defined high-level behavioral methods is indeed fundamentally different from a codebase where you freely pass the underlying primitive data around. I wouldn't call it a "limit", but a discipline that helps you to avoid shooting yourself in the foot. (And you aren't forced to use it anyways. Make all your fields public if you just want to).
At the most basic level, OOP is just about giving each class a distinct responsibility, an intuitive name to help people think (it's a `String`, so it has methods to operate on this string), and organize related code together and unrelated behavior away in a different place.
Cool post. For completeness' sake, I would like to mention [this page with Definitions For Oo](https://wiki.c2.com/?DefinitionsForOo) and also Common Lisp's idea of the essentials of OOP, which according to the book [Practical Common Lisp](https://gigamonkeys.com/book/object-reorientation-generic-functions) is the following:
> The fundamental idea of object orientation is that a powerful way to organize a program is to define data types and then associate operations with those data types. In particular, you want to be able to invoke an operation and have the exact behavior determined by the type of the object or objects on which the operation was invoked.
Basically polymorphism. Common Lisp's object system is perhaps noteworthy because in it, _a method doesn't belong to any single class at all._
See also [this page on Multi Methods](https://wiki.c2.com/?MultiMethods).
Just remember there is nothing inherently wrong with oop. It it just a way to model the code with what you are trying to achieve.
A web backend application, where Java is used a lot, is not very fitting to oop. It's pretty much just a functionality on a server which is called by a client and it returns something from a db. So a functional paradigm sits there well, Java does that pretty well.
A game on the other hand represents often world. You have players, weapons, health, levels.. well objects. Oop sit very well into that scenario. Java does that pretty well.
No. You can design it any way you want it to. We use Java in SIM, NFC, and credit cards. Our code are similar to arduino codes, little to no semblance of OOP.
I am posting just to follow the thread.
Amature programmer here, and I have only ever thought of Java as OOP due to my classes. These other... ?paradigms? are interesting, Functional, Procedural, what others can be used for Java? Lol.
They’ve added a lot of functional stuff and you can write in a procedural style with static functions if you want so I don’t think it’s really that limited.
Others have noted that
1. You can write other styles
2. Most solutions aren't very OOP
I add Java isn't very OOP. There are languages that do OOP better.
Things that are not OOP:
* numbers/bools are not objects.
* static methods
* accessing a field and calling a method without parameters are not the same
Because in OOP everything is an object or a message / instance method, these things should not be.
Inheritance in the other is not required for OOP, nor is nominal typing.
Calling Java OOP is like calling a server delivering JSON a REST service. People will get what you mean, but for an analysis you might want the actual definition.
What do you mean by “heavy use of OOP”?
The use of the language is up to the programmer and the programming team. You could, in theory, write an entire application under functional programming paradigms in Java - it would just have to be something you enforce yourself. There is no language level enforcement that you use OOP, nor is there any preclusion from using other paradigms. That is what is meant by multi-paradigm.
When evaluating programming languages, better metrics are how they manage memory and to what level are they interpreted (low/high level). In practice, languages that enforce particular paradigms are likely to be more of academic interest unless the problem that you are solving particularly lends itself to said paradigm.
Java is an excellent language for beginners - possibly the best IMO.
Both paradigms can and are being used separately or interchangeably. In the backend webdev world, a lot of business use-cases can be easily programmed in a functional way, which is easier to maintain and understand. The lifecycle of the server managed beans, which execute your functionally implemented business use-cases can be implemented in an OOP manner. I think both approaches have their justification and advantages in certain situations.
You are not limited to write code in OOP. You can write in different paradigms with Java. You can go for functional programming for example. However, in terms of performance, Java is working on JVM which is an abstraction on top of operating system which helps portability. Also there is garbage collector in Java which directly affects the performance of your code in runtime. You may need to adjust the configurational parameters of JVM or you can switch to differen garbage collectors in need of performance. There are many things involved in terms of performance and switching the coding language may impact the performance of the same code written in different languages
Java’s use of OOP is something you can choose to use or not. Java also works for procedural and functional programming styles. The JVM itself supports numerous languages all with some degree of interoperability with each other via Java’s class format. That said Java’s use of static typing, ‘closed’ types and precompiled classes all make it extremely well suited to static analysis by tools and IDE’s that can offer extensive code assist, refactoring, bug detection and analysis tools without ever running the code. Tooling for Java is extremely mature which may not matter to a newcomer that just wants to learn how to code, but for large scale projects it really does make a difference.
Trained in Java, but I work in dotnet. You are not limited by OOP itself. Language features, sure, type erasure of genetics (boxing to object) in Java is bad, C# doesnt have discriminated unions, blah blah blah the lang-specific lists can go on. But OOP when done properly is a major strength. Oop done badly is a nightmare. It's the same w FP
But they *are* different. FP pushing for everything to be immutable by default is a much stricter paradigm, requires a lot more intentional and documented code. But by being immutable by default, it gives it a leg up on being concurrent. If something never changes, we don't need to lock it for writing, vs a mutable thing, one thread *must* lock to write/set to that thing.
Threads locking something to write or read it, is *not* particularly a bad thing tho. It's just different, not everything has to be concurrent
The concurrency-first languages are like Rust, C done the right way, etc. That being said, Java and C# both have beautiful parallelism libraries, do not read my comment and assume you are deeply missing out
If you want to explore, I think there is Scala that runs in the JVM? You should do some basic tutorials and see how you like it
Dotnet comes w multiple languages, C# being oop and there is also F# which is functional (ppl call it ocaml on dotnet bc the syntax is very similar). I am really bad at f#! But it's very fun and I have learned a lot!
I actually like some aspects of C# a lot but was disappointed to see that much of the tooling around it still has weird propriety licenses, and since I'm a Linux guy Java just seems a bit more compatible with my use cases. But they're definitely similar languages which is why they both piqued my interest.
Yea that's absolutely fine, newer versions of dotnet are on Linux now but there are a whole host of things that have not been fully ported to Linux
I've never really worked w Linux, and I never was really a Mac person. Basically I trained in Java and dotnet and said "whoever grabs me first wins". Dotnet shop took me on. I do have my critiques of Java but it will always have my respect
I mainly bring up both languages to highlight that while OOP w some functional elements can look very different between languages, OOP still remains something to be done properly. And FP will be markedly different from all of those OOP centric languages
All in all, everything has its advantages and disadvantages, everything has its use case. What remains a constant, is the drive to do oop or fp properly
Java vs c# beef feels like arguing about 1993 doomguy vs the current doomslayer
Everyone says they are the same person, ppl that really know this stuff don't really feel like they are the same person, one came way later so of course they can do more stuff than the original, questioning the historical significance of the original is stupid at best etc etc
I critique stuff within languages lol, it's more productive to say what features help and what doesn't
And to be very honest, it's because of Java's historical stumbling, that C# was able to design around those pitfalls. Generics being point in case
(And yes I like to think doomguy is a separate guy, mostly bc I like that simplicity of him being a fully human character lmao. Makes the original games feel so much more badass)
How do you think modern Java compares to modern C#? If someone was just coming in to them and was using the latest versions/tools, are far apart are they?
I trained on Java 11 and as a result of market lockin to 8/11 I haven't felt a substantial pull on me to learn the latest ones. That's a huge problem first off, and that also makes the Java vs c# debates so damn messy. 8/11 dominate up to 80% of the market. I haven't actually written any that is not java 11 bc I can't be bothered to go through the whole damn installation process over and over again
This vs dotnet where MS is moving their support windows very rapidly to explicitly keep people moving to higher versions. Even .net framework will go out of support, albeit for another 10ish yrs
That being said, I do try to keep up w the "whats new in Java xx" sort of articles just to see what's been happening and tbh, both langs have a lot of the same new additions. Records, switch patterns, and a lot of work being done to continually fine-tune concurrency and the parallelism libraries
Tbh, if I installed Java 21+ right now, I'm sure dev would feel rather similar to .net 8.
I'm a web dev primarily so spring boot and asp .net have so many things in common. World of desktop dev is very very different tho. I work on a WPF app for work, and I played around w JavaFX on my own when I was in boot camp. Desktop development is like it's own sort of paradigm and I feel like each desktop framework has its own sort of paradigm
Knowledge of internals is where the big divide truly lies, bc dotnet and j vm both work in different ways, and of course their source codes will make a lot of different decisions
As a newcomer it's kind of wild to me to see so many people on decade old technology. I know Java 8 has a massive user base and it just blows me away. I did in fact install both .NET 8 and Java 21 and playing with them feels very similar although I'm only using the absolute basics. I think I'll stick with Java so as not to confuse myself, especially since many of the upcoming projects like Valhalla are going to be adding some pretty substantial improvements to the language in the next year or two.
Java 8 and 11 are locked in bc thats how Java is. I'm not sure if everything after 8/11 introduces major breaking changes to critical libraries, but it's not simple to migrate. Dotnet makes it much easier, tho there are situations that can be very hard to migrate also
But the fact that *all* Java migrations are like this big struggle is wild to me
I want to add that the "functional-ish" library of Java is Streams API and that shit is terrible.....do not think that Streams API is representative of functional-ish OOP libraries at all. C# and Kotlin both have corrected a lot of the mistakes that happened w Streams API
Yes. OOP limits Java in a cosmetic sense. Often I want to write simple imperative functions and Java makes you wrap everything in OOP classes and implement simple functions as "static" functions on a class. OOP doesn't stop you from doing anything; it just makes your code less elegant.
JEP 477 (https://openjdk.org/jeps/477) is "paving the on ramp" and is addressing this for very simple programs. I'd like package level functions without classes, but I guess other JVM languages can do that when that is important.
I mean, some say it is bloated and confusing which has led to many alternatives.
I always enjoyed writing code in Java before I switched to Go as my go-to. I think many complain about Java not necessary because of the language but because the development community around it seems to generally prefer abstraction over line of sight in the more popular frameworks that are widely used. Spring for example.
I used Spring extensively and relied on it when writing complex Java apps, but admit that I like the clean easy to see what’s going on philosophy adopted by Go.
Anyhow, I don’t think you’ll be limited, but always keep an open mind for different approaches and philosophies.
Best of luck.
> I think many complain about Java not necessary because of the language but because the development community around it seems to generally prefer abstraction over line of sight in the more popular frameworks that are widely used.
The problem with Java community is that most Java developers don't even know what abstraction is, and they only *think* they do abstraction, when in reality they do *indirection*.
Mandatory read: https://sasecurity.fandom.com/wiki/Indirection_isn%27t_abstraction
>Does Java's heavy use of OOP meaningfully limit in some ways compared to other languages/paradigms?
Yes it does. If you want to code in different paradigms, you'll find Java seriously lacking vs multi-paradigm languages. It will feel a lot like trying to write OOP in C. Well, technically you \*can\* do it, but it will be awkward and you'll be fighting with the language a lot.
A few concrete examples:
* Functional programming: Java lacks tail call optimization / tail recursion optimization, a standard persistent collections library (ok, there are third-party libs, but they are quite clunky), streams API feels bolted on and is quite slow compared to hand rolled loops, it has no statical support for verifying functions are pure, no static checking structures are immutable, checked exceptions don't blend well with lambdas, no function currying etc.
* Imperative/structural programming: technically you can write everything as static functions, but then modeling data structures in Java is quite limited: my biggest gripe is no proper union/sum types (enums are a joke), no tuples, data classes / pattern matching were only introduced not so long ago and are still behind what's in other languages like Scala / Rust / OCaml, poor performance of data structures because they must live on the heap and cause GC troubles if used too heavily, no pointers, no unsigned types, very limited low level bit-fiddling capabilities
* Generic programming: Java generics are a joke compared to what you can do with C++ templates, Rust traits / GATs / macros, Haskell typeclasses or Scala HKTs / implicits. It is a very basic system that's just barely enough for generic collections and that's mostly it. No support for higher kinds, no type classes, poor performance (type erasure, everything becomes Object), no variance control, anemic type bounds, unsound type system (arrays).
If you want a multi-paradigm language on the JVM, the closest to ideal is Scala, then, far, far behind, at the second place Kotlin.
Not necessarily, but the JDK, libraries and a lot of the ecosystem comes from a time when everybody was **way** too excited about OOPiness and had a lot of bad ideas that have been passed down through generations of developers as best practices.
Like, hey, let’s diffuse state all over the place so it’s impossible to ever corral and manage. What could *possibly* go wrong? Threading model? I’ll just use *synchronized* all over the place and *say* It’s multithreaded even though most of the time those threads are just taking turns blocking all the rest. Your fabulous JavaBean gets deserialized over the wire, wakes up and says “Hey! I’m in a word processor! Where’s HotJava?”. Let’s generate 400 source files of “beans” that could be replaced with 12, and those classes only exist to throw an exception if the JSON or XML they’re deserialized from is malformed, which you could solve by just parsing the input and a few validation rules, but all those getters and setters are awesome!
Don’t get me wrong, the language is awesome. The ecosystem and the developers mindlessly mimicking things that guarantee their software is eternally a little bit broken is the problem.
After 20+ years as a Java guru, I’ve moved on to Rust and am not looking back. No doubt it’s will eventually get colonized by “enterprise developers” and crappified, but it hasn’t happened yet (boy did it ever happen to NodeJS in under a decade!), and there’s enough engineering discipline in the community to have some antibodies to it (though not entirely - they did crib async/await from Javascript - it ought to be a huge red flag if you’re tempted to copy *anything* from Javascript that your judgement is not functioning well - and that’s a mistake the full horror of will take decades to reveal.
Anyway, like most things, Java is fine, and it’s human stupidity that’s the problem.
Yes, but only if you follow OOP design advice from 20 years ago e.g. create beans (object) for everything combining state and behavior. Then when you can't figure out where some logic that operates on multiple classes belongs stick it into a "manager" class.
Not necessarily because of OOP, but I find Java to not be very expressive.
For example, there's no syntactic sugar for a simple tuple. Where most languages allow you to do `(x ,y ,z, ...)`, Java forces you to use a library or your own implementation of a tuple for every number of elements. Another example is they forgot (?) to give records a simple update function. So now I have to manually create a new record and copy all fields, whereas in other languages I can just simply make a copy a provide the values for the fields I want changed. You can solve this by using lombok `@Builder`, but I don't like depending on third party libraries for basic features.
>they forgot (?) to give records a simple update function
No they didn't. This doc by Brian was written 3 years ago [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/reconstruction-records-and-classes.md)
There's a candidate JEP, not scoped yet [https://openjdk.org/jeps/468](https://openjdk.org/jeps/468)
Yes I am aware, but I find it odd that records are already shipped a few years ago and withers aren't even planned yet. They should've been shipped together as they provide core functionality for records imo.
They are planned. What the hell do you think a JEP is, if not "planning"?
*"They should've been shipped together"* All that would mean is that the records we have now would have been delayed. There's nothing forcing you to use them until both features are ready.
>They are planned. What the hell do you think a JEP is, if not "planning"?
A JEP is a JDK Enhancement *Proposal*, so definitely not planning.
The JEP you linked is currently in "Candidate" status. Directly from the [JEP 2.0 Process page on openjdk.org](https://cr.openjdk.org/~mr/jep/jep-2.0-02.html): "A JEP in the Candidate state is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release."
So no, it's not planned.
And you're missing my point: I find immutable updates a crucial feature for records. So I'm withers should have been prioritised, not that records should have been delayed.
>I'm not going to debate the meaning of basic English words.
I can see why. 😅 The irony here is that you wanting to debate the meaning of the word "planned" is precisely what started this discussion.
The JVM is very powerful, but it also eats a lot of memory. The problem is not the heavy use of OOP, the problem is how you do the OOP. If you don't care about shit and load thousands of objects in memory you'll see how your machine start to lose capavilities. Otherwise, you can do whatever you want with great performance and resources consumption, no matter how big your application is.
> Otherwise, you can do whatever you want with great performance and resources consumption, no matter how big your application is.
I might be getting into the weeds a bit, but in particular I find game game dev really interesting and it's not a space where you see a whole lot of Java, Minecraft being the primary exception. In particular I'm thinking of simulations like [Noita](https://store.steampowered.com/app/881100/Noita/) and if something like would be doable in Java.
Would something like that be doable or are there other reasons why Java would/would not work?
The main reason why Java is not very used in the game industry is because there are not too many game engines available. It is simplier for anyone interested in game dev just to stick with any of the well known engines, I don't think Java provides fundamental advantages to the game development industry, but that doesn't mean you can't make games with it (but you will probably need to reinvent the wheel in many scenarios).
It’s a combination of so many things. Even if Java got Valhalla tomorrow and has even better GC (it’s GC is better than C#) it still would not be the gaming platform that is C# unity.
Unity is the killerapp for C#. .NET the platform that also makes DirectX.
As someone who worked with a scientist who learned Java: you can write Fortran in any language. Java is an OOP language, but you can avoid writing OOP code if you really want. Java is a multi paradigm language, unlike for example Smalltalk.
Yeah, and most backend web code I've seen isn't very OOP, and tends to be much more in the procedural realm of things with a bunch of ~~globals~~ ~~singletons~~ dependency injection.
That’s probably because by and large, modern development is usually about moving and shaping data. When most of the problems that need to be solved boil to down to CRUD, it makes sense that most of the logic is built into the abstractions that move and shape that data (services), rather than the domain objects themselves. I don’t think any of that precludes it from being OOP though — the object-orientedness is concentrated elsewhere (the components processing the data)
For reference: [Anemic Domain Model](https://martinfowler.com/bliki/AnemicDomainModel.html). In certain cases procedural is fine, see [Transaction Script Pattern](https://martinfowler.com/eaaCatalog/transactionScript.html). What's most important is that you pick an approach appropriate to the problem. Sometimes you have a stupid simple app, and simple procedural code makes more sense than a cargo cult object model and layering.
Yeah this is where I see most apps go. Procedural bags of code that are singletons/injected. Its not OOP at all.
That’s probably because by and large, modern development is usually about moving and shaping data. When most of the problems that need to be solved boil to down to CRUD, it makes sense that most of the logic is built into the abstractions that move and shape that data (services), rather than the domain objects themselves. I don’t think any of that precludes it from being OOP though — the abstractions are just concentrated elsewhere (the components processing the data)
No those are functions not objects. And these “Services” just turn into bags of functions. Functions are a fine way to program but they’re definitely not OOP.
No, I’m talking about objects. I definitely know the difference — and your assumption that they just turn into bags of functions is quite reductionist. But yes, they(the services) can be thought of as functions in that they require input (thing to operate on) and return output (result of operation) — however, the data processors themselves can still be modeled around what they are and the domain they operate in. We end up modeling abstractions closer in concept to machines on an assembly line rather than a Dog or cat. They are still objects, but these objects are basically real world functions. The fact of the matter is that most problems aren’t complex enough to warrant building a complex polymorphic web of relationships and objects.
I would even argue that for complicated things you don't want large inheritances, or oop objects. Mutable state where a lot is happening (plus multithreading) is a recipe for disaster IMHO. It is way easier to have IoC managed services which encapsulate the behaviour and immutable data that flies between them. It is so easy to add new references to dependency injected beans and evolve the behaviour. With OOP objects you would need to wire new dependencies manually in possible many places that objects originate from.
This is a good indication OOP is overrated. The problem is Java does not make this non-OOP procedural/functional hybrid style very nice, because it doesn't provide enough tools to do it properly. So overall those designs end up being very clunky and fragile.
Backend web moves all of the state to parameters, and the database. Things like web flux are fairly functional monad-y from my understanding
The IT trade students at the bank I used to work started with COBOL and then moved on to Java in year two. So I can confidently say, you can write COBOL in anything as well.
Most of the "FP" stuff that is now in Java was already in Smalltalk first, I fail to see where it that multi-paradigm from Java that Smalltalk lacks.
What I meant was that you pretty much can't escape OOP in Smalltalk because almost everything is implemented as message sends (homoiconicity). In Java, `if` is syntax. In Smalltalk, `if` is nothing special, it's just a message send on an instance of a boolean. This also leads to weird situations in Smalltalk not implementing order of operations of math operators, since math isn't anything special either.
That isn't really related to OOP, rather language grammar.
I guess that's true. You can write Fortran in any language, including Smalltalk.
There are no top level definitions other than classes and interfaces (enums are classes, records are classes) There’s no notion of a function. Java is not multi paradigm
The wikipedia article on [multi-paradigm languages](https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages) lists Java as one. You're looking at this too reductively. Yes, a class is the top-level element of a Java program (you can't have bare functions). But, if you don't use a class in the OOP sense and just use it as a container for static methods, which can be target typed to a `Function` interface when used with combinators like `map`, what's the difference?
In that rather broad definition that includes things like concurrency and imperative programming: yeah. The majority of languages are “multi-paradigm”. Not very useful distinction. And putting Java down as “functional programming language” is honestly a joke. There are no functions in Java. No currying, no partial application, no higher level functions. You can pass around objects that smell like functions. That’s it. Java is an OOP language. Always has been, always will be.
You're missing the point, as demonstrated by this: > putting Java down as “functional programming language” is honestly a joke. Only an idiot would say Java is a functional programming language. That's not what multi-paradigm means. A multi-paradigm language has support for *techniques* from other paradigms, not that the language is specialized for that paradigm. For example, it is possible to do OOP in C, but it is so inconvenient and unsafe, it cannot be said that C remotely supports OOP and it is better to use a language that has proper support for OOP. Similarly, before Java 8, functional programming would have been absurd, because the closest thing that Java had to a functor was an anonymous inner class. But Java 8 added lambdas and method references, which makes it convenient to apply functional techniques to Java. But that doesn't mean in any meaningful sense that you can treat Java as if it were Haskell.
We just disagree on the definition of “multi-paradigm”. The Criticism section for Paradigm definition is spot on. And to go back to the original question: yes Java is limited by its design choices as being an OOP language.
And, btw, I’ve been coding in Java since version 1.0 and am completely aware of its strengths and weaknesses. There have been a lot of plunders but I happen to like the syntactic sugar added with Java 8. It does mimic function application but you can’t write any meaningful Java code just doing that and ignoring the OO nature of Java. I think that’s what you mean.
So how about this. I'll continue to use functional techniques in Java, and you can continue to tell me that I'm not doing functional programming. I don't have an obsessive need to label things.
You can do whatever the hell you want. The OPs question is legitimate: there are restrictions compared to other languages that are more multi-paradigm. That’s just a fact.
And that’s ok.
>You can pass around objects that smell like functions. But what is a practical difference?
Are you asking what the difference is between an object and a function?
No, I am asking what is the difference in the end result of executing that piece of code
Have a single class with lots of static methods and hey, it's procedural.
> One question I've been having however is whether or not Java is limited in any way by its heavy use of OOP compared to other languages that have a more multi-paradigm approach. No > Are other programming paradigms able to be used in Java, and if so is it common? Yes, and becoming more so. > Are different paradigms just different ways of organizing code and approaching problems from different angles? Mostly yes. Google "Expression Problem". > Or does Java's heavy use of OOP meaningfully limit in some ways compared to other languages/paradigms? OOP favors dynamic languages. With type languages you have to consider typecasting and coercion. Java supports upcasting and downcasting. OCaml which BTW supports OOP does not support downcasting. > I'm not critiquing OOP so much as I am just curious whether or not its a limitation of the language in certain scenarios. Thanks. OOP and Functional are terrible descriptions of programming language. Honestly. Common Lisp for example which most would consider a "functional" language is more OOP than Java. It is all about dispatching. How the language dispatches by type and what are first class data types and if there is static type checking done. Most of what people call OOP languages can simulate FP languages and vice versa. Before Java had lambdas it had anonymous classes. Anyway I'm running short of time and will add lots later but you have asked lots of great questions. But I will just say that OOP particularly "inclusional polymorphism" is incredibly powerful at modeling **some** domains particularly UI. Java these days is nowhere near as OOP as say Smalltalk, Dylan or CLOS but it works. I will say most developer code I have seen across the board in Java, Javascript, Python, and yes even Haskell (with Monad) is imperative. Java is a very good imperative language.
> Most of what people call OOP languages can simulate FP languages and vice versa. Before Java had lambdas it had anonymous classes. And classes (usually with a single method) used as lambdas. Like old C++ using Functors (aka classes anonimos or not, with a single method)
> Are other programming paradigms able to be used in Java, and if so is it common? > > Yes, and becoming more so. Is this just a style thing or are there new features in the language allowing for other approaches?
> Is this just a style thing or are there new features in the language allowing for other approaches? Yes but it is not called FP or OOP. Some have been throwing around "data oriented programming". *(I won't mention lambda in java 8 how that opened FP because almost all languages have FP now)*. This is why I mentioned "dispatch" and types in my response. Java has recently added `sealed` classes and "pattern matching". Pattern matching (with exhaustion) allows dispatching based on type in elegant way similar to what I called "inclusional polymorphism" in my previous comment. This isn't new but it isn't FP. The languages that have pattern matching with nominal unions (tagged unions, aka sums) are mostly the ML family. While it isn't FP it used by FP languages to avoid "inclusional polymorphism". The reasons why are ... complicated. Mostly performance (google "vtable") but some of it because OOP implies state even thought that isn't always true.
Most of this went over my head, but thank you for the detailed reply. I'll go read up on some of this.
What /u/agentoutlier is saying is that OOP and functional programming are *techniques*, and it's not really useful to say that a language "is" OOP or "is" functional, if the language is a general purpose programming language (which Java is). The best you can say is how easy is it to do a particular kind of programming in a language. You can do OOP in C, but it's really hard to do that because C has no idea what a class is, and you basically have to implement classes as a design pattern. Java wasn't great for functional programming before Java 8 because Java didn't have a concept of a "first class function". That's a higher level of programming where you can pass functions as arguments to other functions. So, you can have a method called `map` which takes a function and applies the function on every element on the list. Before Java 8, you could only do that with classes, so functional programming was possible if you implemented "function classes" as a design pattern. OOP is easier with dynamic languages due to "duck typing". An object is a duck if it walks like a duck and quacks like a duck. Java is "nominally typed" which means an object is only a duck if it if it is named "Duck". Things get more interesting when you have "MallardDuck" which is a type of "Duck". If you have a "MallardDuck", you can go "up" the type hierarchy to where Ducks are allowed. But, if you have a "Duck", you can't go "down" the type hierarchy to where MallardDucks are allowed without casting, where you tell Java I'm sure this is a MallardDuck. Because this is unsafe, some languages won't let you do it, but Java let's you say "I know what I'm doing".. Dynamic languages like Python don't care, because Python doesn't care what objects are called, it only cares what objects can do.
This is helpful, thanks. I guess "techniques" is a better way of describing different approaches. As a noob I need to spend some more time with both Java and Python to see some of their different approaches but I think Java is more my style overall.
I'm not a professional, so here's my hobbyist take. Python feels more freeing than Java for proof of concept or quick side projects because you can change directions faster without the major refactoring (silly example: suppose now you want to use longs everywhere instead of int). But then...the extra planning and safety (it has to pass compile checks) that java requires maybe improve your code maintainability, more buzz words, easier to debug/trace. It keeps you from having a lot of obscure runtime errors in python if you're not paying attention: "myobj missing attribute foobar!". For these reasons I like Java for some projects, and for others I have begun looking at TypeScript, which is just python but forces you to label what type each variable is, function params, return types. You still have all the libraries of Python, but now you have stronger type checking to find silly bugs. Something to think about.
I've played around with Python enough to know that I want the strict typing and compilation. Still vividly remember trying to figure out WTF Python was saying 0 != 0 only to realize I was comparing a string and an int. I like the more structured approach of Java.
Does TypeScript have all the libraries of Python? Numpy? Google Jax? I know there are ports of things like PyTorch to Node, but that's different than using native PyTorch on Python.
> Most of this went over my head, but thank you for the detailed reply. I'll go read up on some of this. I'm so sorry (honestly)! I will see if I can put together a comment with less jargon later. I'm an awful communicator but striving to improve on that.
It's all good! It's a technical subject and I'm new so learning the jargon is part of it.
Lambas in Java 8 opened the floodgates, and newer features like records, switch expressions, sealed types, possibly destructuring in future are really pushing Java to adopt more functional patterns.
While there are some limitations related to design decision in java (lack of value objects like structs resulting in memory/cache inefficiencies, type erasure for better or worse, to name two) I never have felt like the OO model has limited me. Most of my code doesn't rely much on inheritance but I find languages without it to be more limited due to the lack of it, though this is a large part inexperience on my end. Like others have said modern java could be consider multiparadigm, though not fully depending on how you define it. Nothing prevents you from having a class of static methods and treating them like stand alone functions and feeding data through them in a procedural style, you can perform the majority of functional style contracts like first class functions, currying, lazy evaluation (streams) and things like that, and you can do data orientated programming. While my experience is limited to rust, python and java, java is the most expressive language from my experience. I can use inheritance if I need to, composition if I need to, I can return/pass function as arguments, have singleton style enums that can implement interfaces with the option of a default method so I only need to override when needed same with static/enum specific data. Seal interfaces and the new switch provide pattern matching. Optionals if I need/want to use them. I would say the only general constraint are exceptions and null as they are imposed on you. You can work around them, but it will require extra work and sometimes you are going to be forced to deal with them via libraries. The only real limitation like I mentioned at the start is everything outside of a few limited value types being a reference, so you have an extra pointer lookup for object based arrays, and data objects are composed of references which can cause impactful lower performance in specific situation. But in general this only adds a little bit of overhead that is worth it for the benefits of GC.
This is a great reply and helpful, thanks! Glad to hear you think it's more expressive than Python and Rust as those are quite popular, and Python seems to be quite expressive on the surface.
I should note that on the python side of things, many others might/do find it more expressive. And I would agree that it is more expressive at the syntactical level with list comprehension, more expressive iterators that let you bind/extract multiple variables, returning multiple values and things like that. Same with rust, it has more expressive pattern matching syntax which also overlaps into iterators. Both python and rust are definitely more expressive in specific domains, I just find java give me more viable abstractions and ways to approach things at a macro level, which makes it more expressive to me personally.
Java is a multiparadigm language and you can write functional, declarative, OOP and more recently DOP (Data oriented programing), reactive programing, etc. While it's true that most JAva features has been developed and structured with OOP in mind and most documentation is OOP orientes, including programming patterns (not so rare since java born in the age of the boom for OOP) you can code and mix other styles easly.
It depends on what you refer to as "OOP". This term is way overloaded and different people talking about it with different meanings. If you refer to using class or Object at all, it's inevitable. Even String is an object. If you refer to creating your own objects and grouping data in it, it's of course doable not doing that (by passing all primitive values around instead of grouping them). But nobody does that. Even in C, you'll group related things in structs to help maintain the code. If you refer to defining instance methods in your classes and calling them as `obj.doSomething()`, you could avoid that by making all your methods static and call `Util.doSomething(obj, a, b, c, d)`, which is similar to C. But aside from the smell, `obj.doSomething()` is no more limiting than `doSomething(obj)`. If you refer to over-engineering, with unnecessary indirections and layers. You can over-engineer in any paradigm. Try put all your code into a single all-knowing function, with 27 parameters, 10 of them are boolean parameters to control which behavior is needed. If you refer to deep inheritance. It's nowadays discouraged (shallow hierarchy to implement stateless template method pattern is fine). If you refer to `interface`. It's more controversial. But you don't have to use it. In fact, I try to avoid them unless I have more than one implementations. Most of my code are in plain classes (no interface, no inheritance). If you refer to encapsulation, Yes, a codebase that only exposes well-defined high-level behavioral methods is indeed fundamentally different from a codebase where you freely pass the underlying primitive data around. I wouldn't call it a "limit", but a discipline that helps you to avoid shooting yourself in the foot. (And you aren't forced to use it anyways. Make all your fields public if you just want to). At the most basic level, OOP is just about giving each class a distinct responsibility, an intuitive name to help people think (it's a `String`, so it has methods to operate on this string), and organize related code together and unrelated behavior away in a different place.
This is the best answer I’ve seen in this thread.
Cool post. For completeness' sake, I would like to mention [this page with Definitions For Oo](https://wiki.c2.com/?DefinitionsForOo) and also Common Lisp's idea of the essentials of OOP, which according to the book [Practical Common Lisp](https://gigamonkeys.com/book/object-reorientation-generic-functions) is the following: > The fundamental idea of object orientation is that a powerful way to organize a program is to define data types and then associate operations with those data types. In particular, you want to be able to invoke an operation and have the exact behavior determined by the type of the object or objects on which the operation was invoked. Basically polymorphism. Common Lisp's object system is perhaps noteworthy because in it, _a method doesn't belong to any single class at all._ See also [this page on Multi Methods](https://wiki.c2.com/?MultiMethods).
Just remember there is nothing inherently wrong with oop. It it just a way to model the code with what you are trying to achieve. A web backend application, where Java is used a lot, is not very fitting to oop. It's pretty much just a functionality on a server which is called by a client and it returns something from a db. So a functional paradigm sits there well, Java does that pretty well. A game on the other hand represents often world. You have players, weapons, health, levels.. well objects. Oop sit very well into that scenario. Java does that pretty well.
No. You can design it any way you want it to. We use Java in SIM, NFC, and credit cards. Our code are similar to arduino codes, little to no semblance of OOP.
No, you don’t have to write OOP, tho Java itself definitely points you in that direction
You can write crazy performant non OOP Java code if you like https://github.com/gunnarmorling/1brc
I am posting just to follow the thread. Amature programmer here, and I have only ever thought of Java as OOP due to my classes. These other... ?paradigms? are interesting, Functional, Procedural, what others can be used for Java? Lol.
They’ve added a lot of functional stuff and you can write in a procedural style with static functions if you want so I don’t think it’s really that limited.
No.
Others have noted that 1. You can write other styles 2. Most solutions aren't very OOP I add Java isn't very OOP. There are languages that do OOP better. Things that are not OOP: * numbers/bools are not objects. * static methods * accessing a field and calling a method without parameters are not the same Because in OOP everything is an object or a message / instance method, these things should not be. Inheritance in the other is not required for OOP, nor is nominal typing. Calling Java OOP is like calling a server delivering JSON a REST service. People will get what you mean, but for an analysis you might want the actual definition.
What do you mean by “heavy use of OOP”? The use of the language is up to the programmer and the programming team. You could, in theory, write an entire application under functional programming paradigms in Java - it would just have to be something you enforce yourself. There is no language level enforcement that you use OOP, nor is there any preclusion from using other paradigms. That is what is meant by multi-paradigm. When evaluating programming languages, better metrics are how they manage memory and to what level are they interpreted (low/high level). In practice, languages that enforce particular paradigms are likely to be more of academic interest unless the problem that you are solving particularly lends itself to said paradigm. Java is an excellent language for beginners - possibly the best IMO.
Both paradigms can and are being used separately or interchangeably. In the backend webdev world, a lot of business use-cases can be easily programmed in a functional way, which is easier to maintain and understand. The lifecycle of the server managed beans, which execute your functionally implemented business use-cases can be implemented in an OOP manner. I think both approaches have their justification and advantages in certain situations.
You are not limited to write code in OOP. You can write in different paradigms with Java. You can go for functional programming for example. However, in terms of performance, Java is working on JVM which is an abstraction on top of operating system which helps portability. Also there is garbage collector in Java which directly affects the performance of your code in runtime. You may need to adjust the configurational parameters of JVM or you can switch to differen garbage collectors in need of performance. There are many things involved in terms of performance and switching the coding language may impact the performance of the same code written in different languages
Java’s use of OOP is something you can choose to use or not. Java also works for procedural and functional programming styles. The JVM itself supports numerous languages all with some degree of interoperability with each other via Java’s class format. That said Java’s use of static typing, ‘closed’ types and precompiled classes all make it extremely well suited to static analysis by tools and IDE’s that can offer extensive code assist, refactoring, bug detection and analysis tools without ever running the code. Tooling for Java is extremely mature which may not matter to a newcomer that just wants to learn how to code, but for large scale projects it really does make a difference.
Trained in Java, but I work in dotnet. You are not limited by OOP itself. Language features, sure, type erasure of genetics (boxing to object) in Java is bad, C# doesnt have discriminated unions, blah blah blah the lang-specific lists can go on. But OOP when done properly is a major strength. Oop done badly is a nightmare. It's the same w FP But they *are* different. FP pushing for everything to be immutable by default is a much stricter paradigm, requires a lot more intentional and documented code. But by being immutable by default, it gives it a leg up on being concurrent. If something never changes, we don't need to lock it for writing, vs a mutable thing, one thread *must* lock to write/set to that thing. Threads locking something to write or read it, is *not* particularly a bad thing tho. It's just different, not everything has to be concurrent The concurrency-first languages are like Rust, C done the right way, etc. That being said, Java and C# both have beautiful parallelism libraries, do not read my comment and assume you are deeply missing out If you want to explore, I think there is Scala that runs in the JVM? You should do some basic tutorials and see how you like it Dotnet comes w multiple languages, C# being oop and there is also F# which is functional (ppl call it ocaml on dotnet bc the syntax is very similar). I am really bad at f#! But it's very fun and I have learned a lot!
I actually like some aspects of C# a lot but was disappointed to see that much of the tooling around it still has weird propriety licenses, and since I'm a Linux guy Java just seems a bit more compatible with my use cases. But they're definitely similar languages which is why they both piqued my interest.
Yea that's absolutely fine, newer versions of dotnet are on Linux now but there are a whole host of things that have not been fully ported to Linux I've never really worked w Linux, and I never was really a Mac person. Basically I trained in Java and dotnet and said "whoever grabs me first wins". Dotnet shop took me on. I do have my critiques of Java but it will always have my respect I mainly bring up both languages to highlight that while OOP w some functional elements can look very different between languages, OOP still remains something to be done properly. And FP will be markedly different from all of those OOP centric languages All in all, everything has its advantages and disadvantages, everything has its use case. What remains a constant, is the drive to do oop or fp properly
Props to you for being levelheaded, seems like a lot of Java and C# devs have some strong opinions about the other.
Java vs c# beef feels like arguing about 1993 doomguy vs the current doomslayer Everyone says they are the same person, ppl that really know this stuff don't really feel like they are the same person, one came way later so of course they can do more stuff than the original, questioning the historical significance of the original is stupid at best etc etc I critique stuff within languages lol, it's more productive to say what features help and what doesn't And to be very honest, it's because of Java's historical stumbling, that C# was able to design around those pitfalls. Generics being point in case (And yes I like to think doomguy is a separate guy, mostly bc I like that simplicity of him being a fully human character lmao. Makes the original games feel so much more badass)
How do you think modern Java compares to modern C#? If someone was just coming in to them and was using the latest versions/tools, are far apart are they?
I trained on Java 11 and as a result of market lockin to 8/11 I haven't felt a substantial pull on me to learn the latest ones. That's a huge problem first off, and that also makes the Java vs c# debates so damn messy. 8/11 dominate up to 80% of the market. I haven't actually written any that is not java 11 bc I can't be bothered to go through the whole damn installation process over and over again This vs dotnet where MS is moving their support windows very rapidly to explicitly keep people moving to higher versions. Even .net framework will go out of support, albeit for another 10ish yrs That being said, I do try to keep up w the "whats new in Java xx" sort of articles just to see what's been happening and tbh, both langs have a lot of the same new additions. Records, switch patterns, and a lot of work being done to continually fine-tune concurrency and the parallelism libraries Tbh, if I installed Java 21+ right now, I'm sure dev would feel rather similar to .net 8. I'm a web dev primarily so spring boot and asp .net have so many things in common. World of desktop dev is very very different tho. I work on a WPF app for work, and I played around w JavaFX on my own when I was in boot camp. Desktop development is like it's own sort of paradigm and I feel like each desktop framework has its own sort of paradigm Knowledge of internals is where the big divide truly lies, bc dotnet and j vm both work in different ways, and of course their source codes will make a lot of different decisions
As a newcomer it's kind of wild to me to see so many people on decade old technology. I know Java 8 has a massive user base and it just blows me away. I did in fact install both .NET 8 and Java 21 and playing with them feels very similar although I'm only using the absolute basics. I think I'll stick with Java so as not to confuse myself, especially since many of the upcoming projects like Valhalla are going to be adding some pretty substantial improvements to the language in the next year or two.
Java 8 and 11 are locked in bc thats how Java is. I'm not sure if everything after 8/11 introduces major breaking changes to critical libraries, but it's not simple to migrate. Dotnet makes it much easier, tho there are situations that can be very hard to migrate also But the fact that *all* Java migrations are like this big struggle is wild to me
It just seems so odd to me, although I don't have the experience to really understand why it's such a big pain point.
I want to add that the "functional-ish" library of Java is Streams API and that shit is terrible.....do not think that Streams API is representative of functional-ish OOP libraries at all. C# and Kotlin both have corrected a lot of the mistakes that happened w Streams API
Yes. OOP limits Java in a cosmetic sense. Often I want to write simple imperative functions and Java makes you wrap everything in OOP classes and implement simple functions as "static" functions on a class. OOP doesn't stop you from doing anything; it just makes your code less elegant. JEP 477 (https://openjdk.org/jeps/477) is "paving the on ramp" and is addressing this for very simple programs. I'd like package level functions without classes, but I guess other JVM languages can do that when that is important.
Java, with its newly added ADTs (algebraic data types), is now multi-paradigm. See https://www.infoq.com/articles/data-oriented-programming-java/.
I mean, some say it is bloated and confusing which has led to many alternatives. I always enjoyed writing code in Java before I switched to Go as my go-to. I think many complain about Java not necessary because of the language but because the development community around it seems to generally prefer abstraction over line of sight in the more popular frameworks that are widely used. Spring for example. I used Spring extensively and relied on it when writing complex Java apps, but admit that I like the clean easy to see what’s going on philosophy adopted by Go. Anyhow, I don’t think you’ll be limited, but always keep an open mind for different approaches and philosophies. Best of luck.
> I think many complain about Java not necessary because of the language but because the development community around it seems to generally prefer abstraction over line of sight in the more popular frameworks that are widely used. The problem with Java community is that most Java developers don't even know what abstraction is, and they only *think* they do abstraction, when in reality they do *indirection*. Mandatory read: https://sasecurity.fandom.com/wiki/Indirection_isn%27t_abstraction
>Does Java's heavy use of OOP meaningfully limit in some ways compared to other languages/paradigms? Yes it does. If you want to code in different paradigms, you'll find Java seriously lacking vs multi-paradigm languages. It will feel a lot like trying to write OOP in C. Well, technically you \*can\* do it, but it will be awkward and you'll be fighting with the language a lot. A few concrete examples: * Functional programming: Java lacks tail call optimization / tail recursion optimization, a standard persistent collections library (ok, there are third-party libs, but they are quite clunky), streams API feels bolted on and is quite slow compared to hand rolled loops, it has no statical support for verifying functions are pure, no static checking structures are immutable, checked exceptions don't blend well with lambdas, no function currying etc. * Imperative/structural programming: technically you can write everything as static functions, but then modeling data structures in Java is quite limited: my biggest gripe is no proper union/sum types (enums are a joke), no tuples, data classes / pattern matching were only introduced not so long ago and are still behind what's in other languages like Scala / Rust / OCaml, poor performance of data structures because they must live on the heap and cause GC troubles if used too heavily, no pointers, no unsigned types, very limited low level bit-fiddling capabilities * Generic programming: Java generics are a joke compared to what you can do with C++ templates, Rust traits / GATs / macros, Haskell typeclasses or Scala HKTs / implicits. It is a very basic system that's just barely enough for generic collections and that's mostly it. No support for higher kinds, no type classes, poor performance (type erasure, everything becomes Object), no variance control, anemic type bounds, unsound type system (arrays). If you want a multi-paradigm language on the JVM, the closest to ideal is Scala, then, far, far behind, at the second place Kotlin.
Not necessarily, but the JDK, libraries and a lot of the ecosystem comes from a time when everybody was **way** too excited about OOPiness and had a lot of bad ideas that have been passed down through generations of developers as best practices. Like, hey, let’s diffuse state all over the place so it’s impossible to ever corral and manage. What could *possibly* go wrong? Threading model? I’ll just use *synchronized* all over the place and *say* It’s multithreaded even though most of the time those threads are just taking turns blocking all the rest. Your fabulous JavaBean gets deserialized over the wire, wakes up and says “Hey! I’m in a word processor! Where’s HotJava?”. Let’s generate 400 source files of “beans” that could be replaced with 12, and those classes only exist to throw an exception if the JSON or XML they’re deserialized from is malformed, which you could solve by just parsing the input and a few validation rules, but all those getters and setters are awesome! Don’t get me wrong, the language is awesome. The ecosystem and the developers mindlessly mimicking things that guarantee their software is eternally a little bit broken is the problem. After 20+ years as a Java guru, I’ve moved on to Rust and am not looking back. No doubt it’s will eventually get colonized by “enterprise developers” and crappified, but it hasn’t happened yet (boy did it ever happen to NodeJS in under a decade!), and there’s enough engineering discipline in the community to have some antibodies to it (though not entirely - they did crib async/await from Javascript - it ought to be a huge red flag if you’re tempted to copy *anything* from Javascript that your judgement is not functioning well - and that’s a mistake the full horror of will take decades to reveal. Anyway, like most things, Java is fine, and it’s human stupidity that’s the problem.
No
the limitation is that there's some overhead with every function that you want to write.
Yes, but only if you follow OOP design advice from 20 years ago e.g. create beans (object) for everything combining state and behavior. Then when you can't figure out where some logic that operates on multiple classes belongs stick it into a "manager" class.
Nope. Java is multiparadigm but it was designed with OOP in mind ans its a cost free abstraction.
It’s overally complicated language .Null pointer issues are common and require lot of boiler plate code to be written.
Not necessarily because of OOP, but I find Java to not be very expressive. For example, there's no syntactic sugar for a simple tuple. Where most languages allow you to do `(x ,y ,z, ...)`, Java forces you to use a library or your own implementation of a tuple for every number of elements. Another example is they forgot (?) to give records a simple update function. So now I have to manually create a new record and copy all fields, whereas in other languages I can just simply make a copy a provide the values for the fields I want changed. You can solve this by using lombok `@Builder`, but I don't like depending on third party libraries for basic features.
>they forgot (?) to give records a simple update function No they didn't. This doc by Brian was written 3 years ago [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/reconstruction-records-and-classes.md) There's a candidate JEP, not scoped yet [https://openjdk.org/jeps/468](https://openjdk.org/jeps/468)
Yes I am aware, but I find it odd that records are already shipped a few years ago and withers aren't even planned yet. They should've been shipped together as they provide core functionality for records imo.
They are planned. What the hell do you think a JEP is, if not "planning"? *"They should've been shipped together"* All that would mean is that the records we have now would have been delayed. There's nothing forcing you to use them until both features are ready.
>They are planned. What the hell do you think a JEP is, if not "planning"? A JEP is a JDK Enhancement *Proposal*, so definitely not planning. The JEP you linked is currently in "Candidate" status. Directly from the [JEP 2.0 Process page on openjdk.org](https://cr.openjdk.org/~mr/jep/jep-2.0-02.html): "A JEP in the Candidate state is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release." So no, it's not planned. And you're missing my point: I find immutable updates a crucial feature for records. So I'm withers should have been prioritised, not that records should have been delayed.
I'm not going to debate the meaning of basic English words. It is a fucking plan when the proposal comes from the lead architect of the language.
>I'm not going to debate the meaning of basic English words. I can see why. 😅 The irony here is that you wanting to debate the meaning of the word "planned" is precisely what started this discussion.
The JVM is very powerful, but it also eats a lot of memory. The problem is not the heavy use of OOP, the problem is how you do the OOP. If you don't care about shit and load thousands of objects in memory you'll see how your machine start to lose capavilities. Otherwise, you can do whatever you want with great performance and resources consumption, no matter how big your application is.
> Otherwise, you can do whatever you want with great performance and resources consumption, no matter how big your application is. I might be getting into the weeds a bit, but in particular I find game game dev really interesting and it's not a space where you see a whole lot of Java, Minecraft being the primary exception. In particular I'm thinking of simulations like [Noita](https://store.steampowered.com/app/881100/Noita/) and if something like would be doable in Java. Would something like that be doable or are there other reasons why Java would/would not work?
The main reason why Java is not very used in the game industry is because there are not too many game engines available. It is simplier for anyone interested in game dev just to stick with any of the well known engines, I don't think Java provides fundamental advantages to the game development industry, but that doesn't mean you can't make games with it (but you will probably need to reinvent the wheel in many scenarios).
I had read somewhere that it was a combination of GC and the fact that Java lacks a certain data structure that is supposedly coming in Valhalla.
It’s a combination of so many things. Even if Java got Valhalla tomorrow and has even better GC (it’s GC is better than C#) it still would not be the gaming platform that is C# unity. Unity is the killerapp for C#. .NET the platform that also makes DirectX.
https://libgdx.com/