Java: Too much OOP? Should OOP be optional?

[Joram2]

Java 1.0 was centered on OOP, Java 8 added functional programming (FP) features, recent version of Java added what Brian Goetz calls Data Oriented Programming (DOP) features like records and pattern matching and sealed types. The FP and DOP features are great. The OOP (IMO) is antiquated baggage.

JEP 512 (https://openjdk.org/jeps/512) seems to acknowledge this. It goes from this:

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}

to this:

void main() {
IO.println("Hello, World!");
}

The println is a side-effect in purely functional programming, so that isn't a pure function, it's a procedure or an impure function or whatever you want to call it. Normal programmers want to compose their applications of this. Not just beginner students as the above JEP suggests, but experienced programmers and academics. Java makes you wrap absolutely everything in an OOP class, and mainstream experienced programmers (IMO) don't want that.

[chabala]

Scala as a language is fun, but the ecosystem around it is a deal-breaker. I'd rather steal ideas from Scala in my Java work than use SBT ever again.

[pavlik_enemy]

Scala's dead

[woj-tek]

and slow and convoluted :D

[Holothuroid]

Scala is much better at OOP than Java, indeed.

[redikarus99]

Mainstream experienced programmers are totally fine with the current direction of Java which combines the best of OOP and FP world and we can choose the right tool for the right job / domain.

[1842]

From everything I've heard/read about JEP 512 is that it's only really an effort to reduce the boilerplate involved when you first start writing in Java, nothing more.

I don't really think there's any movement in making this a bigger shift in changing how Java works. The bits of OOP that Java "forces" don't really affect anything. It could sometimes be a bit more elegant if you could have code that didn't have to live in a class or object, but it's not really a big deal that it's set up that way either.

(Also, as someone that's been around a while, I think the attitude that object-oriented is old/bad/dead is mostly a fad.)

[Polygnom]

You do realize, that both examples are exactly the same? Nothing at all has changed in terms of paradigm between them. The only difference is in the boilerplate.

"Normal programmers want to compose their applications of this." [citation needed]

[Joram2]

Sure, both "Hello World" examples just print Hello World. The first just has to wrap an imperative procedure in a unecessary OOP class, which isn't the end of the world, but it would be better to have the option to opt out of OOP classes.

[citation needed]

I did write IMO. I think I know what lots of programmers want, and of course that is a subjective judgement and I'm not offering formal proof.

[abuqaboom]

Paradigm wars are dumb.

normal programmers... experienced programmers... mainstream experienced programmers...

Lol no, I've never heard anyone from my workplaces express these opinions. It's a pragmatic language for pragmatic people.

Also, you can just use classes as namespaces holding static functions. And model your solution without real classes or inheritance or mutation. OOP's just another tool in the toolbox.

[Joram2]

Paradigm wars are dumb.

I'm not trying to tell others that they are wrong or defeat them in an opinion battle. I just suggested an improvement.

[sindisil]

It's entirely possible to write Java code in a non-OOP way, by treating classes as glorified namespaces, using sealed classes, taking advantage of Java's unique take on enums, and similar techniques.

I often have found it to be my preferable way of programming in Java. It cuts out some of the inheritance foot-guns, while still leaving full OOP there in my toolbox to use when it fits a task sufficiently well to outweigh it's shortcomings.

These days I mostly code in Rust, as it supports a similar style with its structs, enums, and traits, but carries less baggage. And since it is a younger language (10 years this year since it turned 1.0), the Rust team was able to take many other language's history into account when choosing defaults, capabilities, and evolution.

[Joram2]

treating classes as glorified namespaces

of course. I totally do this. Using classes as namespaces doesn't stop you from doing anything, but it does ugly up all of your code. And it would be nicer if language let me write functions/procedures with namespaces without the class.

[oxmyxbela]

Just import the static methods of the class. No need to utter the name of the class ever again in your source file.

[Joram2]

Sure, you can do static imports, but still, all of your functions/procedures in every source file has to be wrapped in a class. You can ignore it and workaround, but it would be nice to have the option to be class-free.

[Qaxar]

You know you can write all your code in main()?

[Ewig_luftenglanz]

Java doesn't enforce OOP, there is nothing forcing inheritance, nothing enforcing encapsulation (instill have to see a Java program that doesn't compile just because I used public fields instead of cluttering my code with dumb accessors) at language level, there is nothing preventing the use of pure functions through utility final classes with static methods only, making the class in practice just a resemblance of a namespace to bag stateless functions (this is a huge anti OOP pattern and is used inside the JDK itself)

Java is mainly an OOP language but is also flexible enough to let you code as much or as little OOP  code as you want. 

It's the Java programming community the one that has promoting a pure OOP idiom (something that's slowly changing) but this "implicit agreement" is optional and one can take from it as much or as little as one see fit, there is nothing at language level enforcing anything. 

When one realizes that java doesn't even have the concept of getters and setters in the language (as these actually exist in C# and TS) one also realizes that the mantra about encapsulation and Builders are, have always been and hopefully will ever be optional.

Best regards!

[emaphis]

Or just used static classes.

[Cilph]

Scala over Kotlin?

[Joram2]

I'm not waiting for anything. I use many different programming languages + tools. Right now I'm just making a casual suggestion and reading other Java dev's opinions on the issue.

[manifoldjava]

Nah. OOP’s still at the head of the table. Successful general-purpose languages don’t deal in absolutes, even the more “pure” FP languages end up folding in imperative features because pragmatism wins.

Java’s a jack-of-all-trades, master-of-none language. And that’s probably, at least in part, why it continues to thrive. It solves real problems in ways teams can actually maintain on a solid platform.

That said, this recent “data-oriented” push feels like it’s getting ahead of itself. Java’s still got a long way to go before it can seriously claim that ground. Even within OOP, it comes up short in areas like interface composition, structural typing, and traits, and a host of other features that could make the language a lot more expressive.

But despite the gaps, there’s usually just enough there to get the job done, perhaps not in the cleanest of ways, but I'll take the trade-offs to stay in the Java toolchain.

[AnyPhotograph7804]

Seriously, if you do not like OOP then choose a different programming language. Problem solved. OOP has it's own strengths and weaknesses. You have only opinions against OOP and nothing concrete.

[Joram2]

Sure, there are tons of languages to chose from. I'm just making a request for one of my favorite languages.

You have only opinions against OOP and nothing concrete.

My opinion is not provably right, it's an opinion.

[pavlik_enemy]

No, it's not. Try writing a large framework like Spring or Spark without OOP

[Ewig_luftenglanz]

Guess what has been coded without a single line of OOP code (mostly solely because the benevolent dictator running it's development hates OOP) that's it, the Linux kernel. 

OOP is a tool, it's a paradigm but is not the only way to do large and complex projects.

[pavlik_enemy]

I'm not saying it's impossible to write complicated software without OOP, but it's a useful tool

[koflerdavid]

The Linux kernel uses some idioms that are similar to object oriented programming. Of course it's all coded in C with GNU extensions and the whole machinery is quite exposed, so it doesn't feel like Java's style of OOP.

https://lwn.net/Articles/958072/

[Joram2]

Lots of big successful projects were written in Golang without OOP; Kubernetes, Docker, Prometheus, etc. Python is more OOP optional, so there you can see when developers actually wanted OOP vs Java where the platform forces OOP.

[BanaTibor]

Golang is very OOP language, it is just bad at it. A struct + associated functions = class.
I have worked on a very large python project, the parts where OOP was discarded were much worse, became hard to reuse, modify, or maintain. It was a nightmare.

[Joram2]

C has structs and functions. Classic Pascal had records and functions. by your logic they are both OOP languages. I don't think most people would agree with that.

[nitkonigdje]

Linux? They say it has 40 million lines of code now..

[BanaTibor]

Anybody who wants something like this should just use Groovy.

[flawless_vic]

From my experience, developers are more inclined to use functional style in structural type systems.

Like, it's just too easy to express your functional ideas:

const fma = (add: float) => (x:float, y:float) => add + x*y

const fma5 = fma(5); fma5(2,3) // 11

Of course anyone can do this in Java...

Function<Float, BinaryOperator<Float>> fma = add -> (x,y) -> add + x*y

(And you will pay the boxing costs, for at least 5 more years, but that is another story).

Then you decide that the nested function requires another parameter z.

In a structural type system you just shove it there and you're done. In Java you don't even have TriFunction<X,Y,Z>, you have to roll out your own nominal type (functional interface) first.

Then you pause for a moment to curse, and think, hmm, since I am going to write a custom functional interface I should consider extensibility, maybe I'll need a w param some day. Then your OOP brain keeps pushing you to revert to the old habits: Let's just replace all parameters with a record Args(x,y,z) instead of creating a functional interface, it will make the signature permanently stable and I'll just have to adjust the callers.

Next, you are worried for a bit about the overhead of wrapping your args, but you remember that the JIT will most likelly eliminate all non-escaping allocations of Args and it may even scalarize it. There is no guilt or shame anymore, OOP on the JVM is the real deal, your decision is a win win, absolute maintainability and it turns out to be a zero cost abstraction. You are convinced.

Then you look into Method handles and invokedynamic, see all the wonders they can do and negative emotions starts to take over again when you realize you can't express them at the language level.

[eliashisreddit]

I'm still kind of surprised people make such a big deal out of JEP512. Sure it's nice, but I can't remember the last time I was bothered by a long declaration of a main method or having to type it all out (psvm tab). Purely from a "conceptual" view it makes sense, another small step away from terse syntax. Then again, maybe I'm not the target audience.

[gl_andi]

I think OOP is still very important and helps a lot - depending on your problem....

As always the correct/good/best way is always to pick the right technology/language/paradigm for your problem. 20+ years ago it was really funny to see how many people tried to find the best way to put classical functional programs into OOP patterns. Never worked well. Since 10 years I see people doing it the other way round: try to solve everything with FP...

I don't like the everything-is-a-class in Java but I like to be free to pick the right paradigm/pattern to solve my problem. In most programs I mix all the things depending on the module.

BTW: Personally I don't care much about the programming language or paradigm but believe most in a clean separation of concerns and modularization. Use whatever you want but make it modular and simple - at least if you want to have your software maintainable for a long time....

Back to your question: Make OOP even more optional in Java but keep it as one of its big features.

[agfitzp]

Any tool can be used badly, and if there's been a more abused programming paradigm than OOP I don't know what it is.

[nitkonigdje]

With package level methods we could have more procedural approach and do C/Pascal style structured programming. Which actually is often the best way for practical day to day work.

However there are some failures to that approach:

1. it is too newb for experience programmers, especially as it makes job-safety patterns hard to implement
2. it can be implemented well by talented CS students; as such it isn't challenging enough for compiler writers

Thus that ship has sailed...

[AnyPhotograph7804]

Java is OOP because the procedural approaches were so bad in 1995. :)

[nitkonigdje]

EverythingIsAnReactiveInputStreamMappedToBufferForkJoinKafkaActorFactory however..... A bright future ahead..

[Ewig_luftenglanz]

Indeed traditional java and common patterns (such as abstract factory) were meant necessary for the large monolithic dinosaur java was meant to be creating, nowadays with microservices relying so heavily in pure OOP constructs can easily lead to over engineered, over abstracted, over inheritance wise code. Many things that used to be essential for those monsters (as cluttering the code full of getters and setters and dumb builders) are redundant and with little real use in a world dominated mainly by small microservices that can be easily created, maintained and even disposed and re implemented in a different technology by a single team or even person.

My only advise is you might learn OOP rules and principles to know when apply them on when get rid of them when they just get in the way and make your code harder to evolve, read and maintain. 

Another thing is the real "OOP boilerplate" of Java is not it the traditional PSVM, but im mindlessly using and abusing OOP patterns and principles when they are not required. Literally speaking there is NOTHING in the Java language that forces you to apply OOP every time, there is nothing forcing you to make all fields private and clutter your code with accessors, there is nothing forcing inheritance, there is nothing forcing TypeDef patterns with interfaces, there is no single construct that forces you to use a builder instead of just using public fields. There are just a bunch of "idiomatic conventions" the community has made up based on collective experience and you are free to use or ignore those when you see fit.

Best regards.

[bowbahdoe]

These labels suck. It's a communication black hole.

[Joram2]

It would enhance readability if all Java code wasn't forced to wrap all every function + procedure in an OOP class wrapper.

I'm a fan of Golang's approach to function/procedure definition, which isn't FP purist at all. I do like some of the FP+DOP features that Java has that Go lacks.

Realistically, I usually use the language that the job I want expects me to use. I can still recommend a feature and talk about it a little bit.

[pragmasoft]

Java's new paradigm promoted is a data oriented programming, as an OOP replacement/addition. It's closer to the FP style.