I am an old school java developer. Can someone explain me why this is a "feature"? I can remember by counting my fingers the times I had to use "instanceof", and it was some classical reflection/injection/instantiation framework 'vodu'. If you are using instanceof in a normal java program, you are just making it wrong. It looks like some new javascript guys arrived in the block and are trying to make java look something messy like Scala. What real world problem is this trying to solve? Are you just fucking bored because you are all out of ideas and every JDK release we need "something"? Why these JEPs only have "boxes,rectangles,A,B,I" class examples and not a simple real world class scenario? Why we need to make java "friendly" to work with generic objects? it should be hell! I cant wait for JDK 50.
Lots of compilers are written in functional languages and use pattern matching for traversing abstract syntax trees, dispatching on the node type. The OO way to do this is to put all logic relating to a particular class in the class itself. The functional approach is to put all logic for a given method/function in one place and handle all the different types. They are two different philosophies both with different tradeoffs, and which is best depends on the type of program you're writing. But it's nice for a language to support both, so you can pick and choose which approach is best for a given problem.
It shows the majority of its strength in switch statements. You can mostly just use the instanceof for a one line destructuring of a compound object into its constituents. The corresponding rust statement is the `if let` or `if case let` if you are more of a swift fan. Generally you would use it with sum types which were previously extremely nasty to work with in Java but are more useful now with sealed classes.
The pattern shows up a lot with result and option types but you can do it any other time where a tagged union makes sense. The classic way to do a tagged union in Java was just a personal taste amongst bad options: tagging interface and instanceof on implementations or an encapsulating class that will return null (or throw an exception) if the gets are called for the types which aren't encapsulated.
If in your career you never needed to enumerate cases that required different data in each case and you couldn't see how binding those requirements into an invariant via the type system was helpful then you probably won't use these new features either. Some people thought it was helpful but the boilerplate cost was too high so wouldn't do it in practice (I am in this category).
Edit: you could also make tagged unions more type safe with callbacks, but then implementing a closure to pull the value out of the callback was just annoying.
"If in your career you never needed to enumerate cases that required different data..." . Maybe one or two times... but it is not like "hey, it is impossible", or "shit, I have to write 10 more lines" in this rare code I will never put my eyes again. What I get angry is that people will start to use everywhere, in places they should not be using. because the guy did not wanted to stop five minutes to think about it. The river flows through the easiest path, but this does not means it is the smartest path.
Unfortunately, I've seen plenty of Java 8 code where people did not "stop five minutes to think about it". I don't think any language can protect us from ourselves.
It's fair that you've found sensible ways to achieve your goals without ever needing pattern matching. Nobody should fault you for that. But can you grant that other developers might have other sensible ways to achieve other goals (or sometimes other ways to achieve the same goals!)?
I think most Java developers will be familiar with the visitor pattern. In almost all cases (there are exceptions!), I detest it; I find sum types with pattern matching to be a far superior way to say what I mean. Java added `sealed` interfaces recently, so you can actually model a closed family of types. Now pattern matching closes the loop, giving you a supremely ergonomic way of dispatching over that closed family without using a visitor.
Maybe it's not clear from other responses, but the part of the JEP about an "exhaustive switch" is critical here. Java statically guarantees that you've handled each member of your closed family, just like if you forgot to implement a method for a visitor.
"...look something messy like Scala", I feel bad you feel this way as Scala is an incredibly powerful and elegant language.
It's ironic because you're throwing shade at Javascript when JS developers are doing the same thing against Typescript. Fearing what you don't know or understand under the guise that change is bad or things are "good enough".
I agree Scala is very powerful. I said messy because it is "too powerful", added too many features. I think this is their mistake. I respect the community, but can show my opinion as you can about java.
I really don’t feel that Scala has too many features. It is a relatively small language which is very elegant due to having almost no edge cases. Sure, due to not having many features yet being very expressive it has to have very powerful language primitives that can be abused, but I really don’t think that it is as bad as its name.
Java is also a messy language and the reason for a lot of the mess in Scala. If you want elegance, then you should probably learn something like Haskell.
Because there are scenarios where pattern matching (or instanceof) is the better and more ergonomic thing to use. One obvious example I can think of is event handling.
If anything, this is _not_ something JS devs are asking for, but rather devs using functional languages.
I also think of API ergonomics. Unspecified input with the same single endpoint, while under the hood will be absolute spaghetti, from a developer adoption standpoint can be make or break.
And if you're strongly typing your system rather than relying on strings, extra so.
Exactly, this is what OP was trying to point out. With the record matching feature, you don't need the extra abstract base class anymore.
This is not to say that abstract base classes are never a good idea, but sometimes in Java they were only there for the convenience of one handler method, to prevent the use of instanceof.
This didn't improve readability. That's when the record matching can be a good improvement.
Sometimes it isn't desirable to scatter the logic across many classes, or conflate the data and the handling. The Java world has the "visitor pattern" to help deal with that, but its double-dispatch is clunky, complex and verbose. Pattern matching just generalises switch and makes it more useful. Java is genuinely a better language with this change.
I wish they had better examples, so here is one. Suppose you are making a scene graph, and you want to have a visitor and run code based on the type of the nodes in the graph. Well, consider two approaches. The first approach is to use a bunch of ifs and instanceof, but this isn't clean and it is fragile. The second approach is to make an interface that has all the types listed under a handler (void handle(Type1 t), void handle(Type2 t), ...) and then write some boiler plate code to do the dispatch.
This feature aims at the conciseness of first model (instanceof) with the safety of the second approach (i.e. all types are handled).
I would love this feature for my project! ( https://www.adama-platform.com ) since I use Java to implement a programming language.
The sealed interface, final implementation case is an interesting one to inspect. Now you can, for example, write a parser with a fixed set of tokens and write switches that exhaustively handle every token. You now get compile time guarantees.
Sure, though as I mentioned in other comment, pattern matching is basically a better Visitor pattern. Which is while not the most common pattern, is not that much of a niche either.
My problem is with the "just adds"... Scala made this mistake, and ended with many different ways to do the same task. It is a powerful language, but I believe languages must have only one (or two) concise way to to things.
The "multiple ways of doing things" is a feature, not a bug and something which lives in almost every programming language. It's become a meme at this point and a lazy argument against a language.
> It's become a meme at this point and a lazy argument against a language.
This might be a casual dismissal of what is in fact a nuanced aspect of programming languages.
Multiple ways of doing the same thing can make the language less accessible because it becomes confusing to reason about what the "right" way is.
That said, this particular addition merely reduces repetitive toil, and it follows similar existing Java conventions, for example see the Java-7 equivalent of Python "with-statements".
yep, agree with you. I become more aware of this when I worked some years in a huge ruby project. Everything was allowed, and with tons of DSLs you dont know anymore what is happening.
This is obviously false in full generality, C++ has many (M A N Y) ways to do anything, and I have never seen even the most fanatic C++ fans defend this as a good thing. Nearly every single C++ dev hates some (large) subset of the language, which subset is another matter entirely, but a subset nonetheless.
Bjarne Stroustrup once noted in Design & Evolution of C++ that people want different things from the seemingly simple artifacts we call "Programming Languages". Some people want an algorithmic language to express procedures cleanly in, others want a design language to express large scale systems in. Some want a terse and uniform "executable mathematics" notation, others want a down-to-earth worse-is-better lets-make-some-goddamn-apps-and-put-some-fucking-bread-on-the-table working class language. Some want a language with an emphasis on the lone author, others an emphasis on the corporate business team. A language as a tool that you wield skillfully for the single purpose it was built for, a language as a toolbox full of gadgets, a language as a material to build the previous two from, a language as a community hub to organize around, etc etc etc. I have seen people argue that "Language" the wrong metaphor to understand computer notations entirely.
This is why you can't say anything general about programming languages.
If you wanted the idiomatic only-one-way-to-do-things approach to do things, Java is not and has never been the language of choice for that. Why do we have 10 different dependency injection /logging / web frameworks? Who cares! Let's add an 11th for good measure. I don't want java to be idiomatic and purist conformant tedium.
You're welcome to switch your language of choice to go if that's really your bag.
The examples you gave are not language features, are frameworks/libraries... not the discussion. (the only exception I can see is the "logging API", but this is debatable)
Highly compositional design patterns in Java. When you have a fairly large set of custom types that are hierarchically structued in nature, it can be quite useful.
In most standard IT applications it may be less common. I've seen it used fairly well in scientific applications. There are of course other ways of approaching working with and acting on wide taxonomies of objects that could exist but this is one of them.
instanceof is but one possible use case. Arguably the most useful part of pattern matching is inside switch expressions, and there is an equivalence between the Visitor pattern and this, but the latter is much more readable and maintainable. Sure, the visitor pattern is not that often used, but in certain niches that make use of ASTs often it is pretty much a must.
The way this is phrased gives a bad name to those mythical enterprise/old/Java developers. I personally don't want to be associated with this stereotype, I have another 20 years of interviews in the future.
I started programming in Java in 2002. I had some of your stated attitude learning Scala ten years ago. Probably because I grew up on Turbo Pascal and C++ , majored in EE, and didn't hear about PL theory. I cannot fathom anyone wishing to go back to Java after using Scala (as a better Java, without cats/scalaz&Co) or at least Kotlin. The way you describe new Java features I'd think you come from a golang background.
I have nothing against staying on the JVM for the rest of my career. For this to be feasible we need modern languages fully supported and popular. I personally want more concise syntax and more elegant abstractions in my daily life.
100% agree. Using 'instance of' in Java is a terrible anti-pattern, same as trying to do pattern matching. You should lift that code into instance methods and let the runtime pick the right implementation.
There are some cases when it's actually simpler or more maintainable or more useful to do the dispatch locally. A language that allows you to both is tougher to learn and can have a higher risk of pitfalls, but also means that a seasoned practitioner can apply the right tool in the right situation.
In terms of the classic 'patterns', it's the difference between standard dispatch and the 'Visitor' pattern. There are cases where you want to specify each case of data structure locally, and others where you want to specify each method of each variant locally. Welcome to the expression problem!
There are cases in Java where you do want a true POJO - just a bag of structured data. This is probably a very strong candidate for using along side that.
The downside to that is if you want to write a new function that deals different subclasses, you can't keep all the logic in one place; you have to spray its implementation across all the different types it has to handle. This is the #1 reason I prefer languages with sum types and pattern matching (or the ability to emulate it via unions and instanceof checks, e.g. TypeScript or Python + mypy).
You could implement a crappy union type in Java with a type-safe API, but if you want to program in that style you are really better off using an ML or Scala.
I actually disagree. instanceof is a fast operation on the JVM and can make code easier to read than equivalent OOP (less hopping around). However, you must be careful that all cases are covered since Java lacks exhaustive pattern matching.
This is true.... Old guys know nothing... for years we told the javascript guys the mess they were doing, and voila, all dynamic languages suddenly started to convert into statically-typed, and at the end, they have this webassembly, that runs in a schizophrenia-type VM wannabe. Congrats. You lost 10 years of your life because you didnt listen to us when we said that we have learned something from Self and Smalltalk.
> and voila, all dynamic languages suddenly started to convert into statically-typed
This is... just wrong.
Plenty of people are using JS without any sort of typing whatsoever. Other dynamic languages, like Clojure, Gradle, Elixir, Pharao (a smalltalk), just to mention a few, are still going strong.
> they have this webassembly, that runs in a schizophrenia-type VM wannabe
wasm is mostly being used as a target for C(++), Rust and even C# programs that want to run in the browser. It's there to expand the reach of the browser. Most JS projects don't touch the stuff.
Typescript is absolutely coming to dominate the field IME. Obviously I have no true idea about the relative use % everywhere but I haven't worked at a place in the last few years that wasn't at least trying to use it. There's enough legacy JS out there to provide work for people who hate static types for many years though.
> This is true.... Old guys know nothing... for years we told the Java guys the mess they were doing, and voila, all OOP languages suddenly started to move to functional paradigm. Congrats. You lost 10 years of your life because you didnt listen to us when we said that we have learned something from ML and Scheme.
Your problem isn't that you're old. It's that you don't understand how little you know in this space and this renders you too arrogant to learn anything new. New to you, that is, because the concept of pattern matching is actually many decades old. You encounter it in undergraduate PLT coursework, famous comp sci textbooks like SICP, and virtually any language outside the imperative/OO lineage.
Thinking you have an I-told-you-so moment with static typing and dynamic languages only shows you don't understand the details and tradeoffs in the design space. For example TypeScript's approach to static typing is very different to Java's and these differences reflect consideration of the problems being solved, JavaScript's specific use cases, its history and the path dependence of its design. Because these details are invisible to you the whole thing is simplified in your mind to "everyone is switching to static typing just like I said they should!" In fact this type of prognostication was never useful or meaningful. The hard part wasn't deciding to build static typing onto JavaScript. The hard part was determining specifically what that should look like, how it would fit nicely with the language and then doing the work of building it and driving adoption.
TypeScript is successful not because it is static typing but because it is a form of static typing that's exceptionally well suited to JavaScript and its use cases. If people like you had their way it would have been a failed attempt to bolt a Java style type system onto JavaScript, worsening the design debt in a language and ecosystem that is already loaded with it. This already happened on a smaller scale with classes in ES6 which were driven by Java devs writing JavaScript and wanting something familiar instead of trying to understand the language.
You might be right that adding pattern matching to Java isn't a great idea but at the moment your disagreement is based in ignorance. You've been given ample explanations of pattern matching in this thread. Put down the ego and take some time to learn on your own.
I've never been a fan of Java due to the GC and the boilerplate and runtime overhead (time but also space) that come with it. But I've always had respect for it because it felt so minimal and consistent in its own way, bulky but solid kinda like a BMW car.
Now that functional stuff and instanceof fluff is something else. I don't like it either.
Unless you only prefer low-level languages, Java’s runtime is anything but bulky. It is one of the fastests runtimes out there, so runtime overhead is relative.
The runtime might be an efficient implementation of the language, but the language itself (given GC and still no custom value types AFAIK) implies a distinct bulkiness compared to what I am used to. This is as I said my personal feeling when using the language, and is based on the number of keystrokes I've needed in the past to get from A to B, as well as the runtime overhead (memory overhead for many small objects, add in GC and chances are it's very noticeable time-wise too).
It much depends on the task of course. My biggest project in Java was a SAT solver years ago, and millions of little clauses did not sit well with it at all. I ended up changing the data organization internally. My first attempt, the natural AOS would have been also the best choice performance-wise in C, but in Java it choked the GC. I had to switch it around to SOA which was quite awkward but it reduced the number of objects from millions to a small constant.
Also thinking of the number of lines of code running for JIT, GC, whatever... in the background all the time...
I get that, and sure enough for certain workloads it is definitely not ideal. But I think you would be surprised at how fast it can actually be.
In projects where you can’t get away from object allocation (due to it being less deterministic for example) with some clever trick like arenas and the like, chances are the GC will be actually much faster than malloc-ing them all — and while it may not sit well with you, GC running in the background just amortizes the cost of each deallocation to basically zero time overhead (of course at the cost of memory overhead).
But I’m not trying to dismiss your experience or anything, the JVM has its place and of course there are plenty of use cases where it is not the best fit at all.
I said it felt (to me) "bulky but solid kinda like a BMW car" which I think is a fair criticism and also a statement of respect, so what you tripped you up?
And that statement was not about the allocation time. But my understanding is that deallocation (GC) is not amortizable to constant for long-lived objects.
We can probably agree that having to code a separate class (with object overhead) to represent each little tuple of 2 integers or so, is bulky - programming-wise but also concerning the memory overhead (and possibly GC overhead).
Programming in C does not imply using malloc() to allocate individual objects. This is a bad practice.
I kinda feel the same. Modern Java is written like some Python/JS Mashup. Its one reason old code bases are a huge mess because code is written in many different styles.
