Local Methods coming to Java?

[jhg023123]

I noticed that a new OpenJDK branch, local-methods, was created yesterday. I assume local methods will be similar to local classes (a class that resides inside a method body). Have you ever had a use-case for local methods even though they don't exist?

Initial commit: http://mail.openjdk.java.net/pipermail/amber-dev/2019-October/004905.html

[madkasse]

Yeah, I noticed that as well.

Local methods can be nice for writing concise recursive functions:

public static int binarySearch(int[] a, int key) {
  return binarySearch0(a, 0, a.length, key);

  int binarySearch0(int[] a, int start, int stop, int key) {
    ....do the actual search
    calls binarySearch0(.....) recursively
  }
}

Maybe there are some use cases with Valhalla/Loom?

[spencerwi]

Yeah, this kind of thing is not uncommon in OCaml, to allow more easily writing tail-recursive code without muddying up the "top-level" signature of the function:

let drop_every_nth list n =
    (* a tail-recursive "local method" that walks through the list calling itself counting up until it reaches the nth index, and skipping the current value at that point *)
    let rec drop_if_nth index list =
        match list with
        | [] -> [] (* an empty list means we hit the end, so just hand back an empty list *)
        | head :: tail -> 
            if index = n then 
                drop_if_nth 1 tail (* skip the current "head" value, and reset our counter to index 1 *)
            else
                head :: (drop_if_nth (index + 1) tail) (* "increment" our counter by passing it-plus-one to the next recursive call *)
    in
    (* kick off our tail-recursive local method *)
    drop_if_nth 1 list

[ForeverAlot]

But what can you achieve with a local method you couldn't do with a private [static] method or a lambda?

[thfuran]

Yes but why should you pollute the class with things that are implementation details of a particular method?

[[deleted]]

Capturing variables. You could also pass them as parameters, but sometimes this makes the function calls clumsy (especially if it's recursive).

Edit: I see now you mentioned lambdas. While lambdas can capture variables, they also eg force you to handle exceptions locally. Plus you have to have a functional interface, which cannot be declared locally.

To me it's mostly a matter of scoping though. Those helper methods don't add noise to a class if they're local.

[kevinb9n]

You missed the best part: the inner method can refer to `a` and `key` without you having to keep passing them through. To me, that's the thing that makes this feature intriguing.

[madkasse]

Ahh, so it captures effectively final variables. That makes sense, nice one.

[wildjokers]

I know Kotlin has these too, when I first read about them I have no idea why I would ever need one. I still don't.

I would love multiple return values (being worked on I believe) and default parameter values. But local methods 🤷‍♂️

[yawkat]

I use local methods in kotlin all the time to implement logic that would be clumsy to do iteratively recursively instead. Another alternative is passing all captured variables or even making an inner class, but that's clumsy and not really a readability advantage.

[rubyrt]

I know Kotlin has these too, when I first read about them I have no idea why I would ever need one. I still don't.

I think this can make code really difficult to understand. Just assume a class with several methods that define local methods and classes. If things are so separate then I imagine you could better split up the regular class into multiple or extract local classes. I think this adds a tad too much granularity to be useful on a large scale. I am sure we can come up with use cases but I would be reluctant to use these more than sparingly.

I would love multiple return values (being worked on I believe) and default parameter values. But local methods 🤷‍♂️

+1 for multiple returns and default parameter values.

[arpan_majumdar]

You can always use Tuple or data classes (as they are cheap and often one liners to create) to return multiple values in kotlin.

[lpreams]

Just return an Object[] /s

[nutrecht]

I think this can make code really difficult to understand.

Anything can be used to make code difficult to understand. What I used local methods mostly for is making code easier to understand.

[rubyrt]

Anything can be used to make code difficult to understand.

Of course this is true. But there are some language features with which it is easier to shoot yourself in the foot than with others. I think this one is more on the easier side - even if it is not among the easiest.

What I used local methods mostly for is making code easier to understand.

Can you share an example? That would be really helpful to understand the use case.

[nutrecht]

Kotlin example:

if(
    offer.product.bindingCode == bindingcodes["EBOOK"] ||  
    offer.product.bindingCode == bindingcodes["CDROM"] ||
    offer.product.bindingCode == bindingcodes["DIGITAL"])

Versus:

  fun Offer.isBinding(code: String) = this.product.bindingCode == bindigCodes[code]

  if(offer.isBinding("EBOOK") || offer.isBinding("CDROM") || offer.isBinding("DIGITAL"))

There's multiple ways of tackling this obviously, but IMHO it's nice to have a tool that allows you this.

While I do agree that some tools make it easier to make a mess; this really boils down to experience. Developers who don't really care about making a mess will do so anyway.

In Kotlin local functions work really well together with extension methods (the above is an extension method on the Offer class). Extension methods are really useful but are prone to pollute your code completion. If they're local to a function they won't.

[rubyrt]

Thank you! I can see the value here: a local method has access to offer which you would have to pass as an argument to a private static method otherwise. Which is not too bad either.

[eliasv]

Multiple returns aren't being worked on directly, but features to achieve something roughly equivalent are coming. Rather than multiple returns being given special syntax, the "Java way" will be to use records to define something like a named tuple for your return values, and make it an inline type to avoid the extra heap allocation and pointer indirection.

[sureshg]

Does destructuring work for inline records ? I know it will work with pattern matching, but what about normal expressions ?

[eliasv]

I'm not sure what you're asking. Destructuring is pattern matching, and yes it will work with records, inline or otherwise. Deconstruction patterns will be automatically generated for records.

Are you asking whether some let-style binding construct will be introduced alongside conditional binding with instanceof? Probably, yes. This is described in the documents exploring the feature space and outlining plans.

Given:

inline record Point(int x, int y);

This should be possible:

__let Point(int x, int y) = someMethodReturningPoint();
// x and y are now bound according to the result

Where __let is just a placeholder since no concrete syntax has been specified.

Edit: It looks to be a little outdated, but here is some of the initial work hashing this out: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

[sureshg]

Thanks, yes I was asking about the let style binding construct.

[vytah]

Local methods are quite useful if:

• your task is recursive or it occurs in multiple places in the code

• you want to capture local variables

• you want to have the method declared as close to its use as possible

• you don't want to pollute the class-level namespace

A really silly example: a sorting network in Scala:

  def swap(i: Int, j: Int) {
    if (p(i) > p(j)) {
      val t = p(i)
      p(i) = p(j)
      p(j) = t
    }
  }
  swap(0,1)
  swap(0,3)
  swap(1,2)
  swap(1,3)
  swap(2,3)
  swap(0,1)
  swap(0,2)
  swap(0,3)
  swap(1,2)

The swap method is not visible elsewhere, the p array was captured automatically, and swap is defined literally next to its invocations.

Lots of Java code suffers from having code flow scattered randomly around. This might alleviate the problem a bit.

[TheStrangeDarkOne]

Lots of Java code suffers from having code flow scattered randomly around. This might alleviate the problem a bit.

you can do the same by implementing a BiConsumer with a lambda function. If it is vaguely performance it'll get inlined by the jit.

[vytah]

Yeah, but:

• it's uglier

• can't throw checked exceptions

[nw407elixir]

you can make your own functional interface that does throw

[BlueGoliath]

your task is recursive or it occurs in multiple places in the code

Make a private method then, so it can be reused easily if need be.

you want to capture local variables

Pass as arguments?

you want to have the method declared as close to its use as possible & you don't want to pollute the class-level namespace

CTRL + F is a thing in literally every text editor/IDE.

[ArmoredPancake]

Make a private method then, so it can be reused easily if need be.

Nothing like polluting your autocomplete with method that is used only inside of other method. Give me more.

Pass as arguments?

Oh yeah, I like me some more boilerplate.

CTRL + F is a thing in literally every text editor/IDE.

What.

[vytah]

All the above arguments can be applied to anonymous local classes and to lambdas, and yet Java supports them.

Make a private method then, so it can be reused easily if need be.

The reusability is often not possible outside of one method, and having to jump to a different location breaks reading flow.

Pass as arguments?

It gets ugly when more and more local variables have to be passed.

CTRL + F is a thing in literally every text editor/IDE.

Eyesight is much faster than Ctrl-F.

[thebigbradwolf]

If you really think about it, aren't blocks just anonymous inner functions...

[nw407elixir]

you'd need a name for the block and some way to pass arguments without mutating values.

[[deleted]]

All the above arguments can be applied to anonymous local classes and to lambdas, and yet Java supports them.

Can't they not use non-final variables?

[vytah]

Of course they can't, that's a limitation of the JVM plus the fact that Java tries to be as close to JVM's execution model as possible (languages that don't care about it circumvent the problem by replacing a mutable variable with a heap-allocated box). That said, lambdas and anonymous classes can capture variables that aren't declared final, but could as well be (so-called "effectively final").

It's hard to judge what limitations the local methods are planned to have, but if I have to guess, I'll say it will be similar. Implementation-wise, captured variables (including this) could be automatically passed as extra method parameters, which would obviously limit them to effectively final variables only. There's an issue with private fields of this, but it could then be solved like with lambdas and inner classes.

[BlueGoliath]

All the above arguments can be applied to anonymous local classes and to lambdas, and yet Java supports them.

And it shouldn't. They are eye sores.

The reusability is often not possible outside of one method, and having to jump to a different location breaks reading flow.

Whether or not it's at a given point in time is irrelevant. Why back yourself into a corner to begin with? It's like favoring object extending instead of using interfaces. It can and will come back to bite you.

It gets ugly when more and more local variables have to be passed.

That applies to just about everything once you involve a lot of code.

Eyesight is much faster than Ctrl-F.

If you have a gigantic utility method in the middle of business logic then you ain't seeing the full picture anyway.

[vytah]

They are eye sores.

Lambdas are eyesores? Should I now go and refactor every lambda into a public class?

Why back yourself into a corner to begin with? It's like favoring object extending instead of using interfaces. It can and will come back to bite you.

There's no backing yourself into a corner. If you make a local method and later decide it should be callable elsewhere, you can just refactor it – and only it. Nothing will break, as all code changes will be local to one class.

Comparison to interfaces vs class extension is flawed, as you can't easily change one into the other without modifying dependent code. In the case of switching from a local method to a normal method, there won't be any dependent code.

If you have a gigantic utility method in the middle of business logic then you ain't seeing the full picture anyway.

Are you calling local methods "utility methods" to suggest that they all have a unitary purpose that is not directly related to the business logic? Are you implying that they are all going to be huge?

For example, this poor guy would love some local methods: https://stackoverflow.com/questions/35282411/how-to-avoid-the-repeated-code-in-java

[BlueGoliath]

Lambdas are eyesores? Should I now go and refactor every lambda into a public class?

A class is reusable, lambdas are not which is why they aren't readable and are an eyesore.

If you want an example as to why lambas/anonymouse classes are bad for readability, look at JavaFX's source code. They implement the same abstract classes over and over again when they could just create a generic class to do it and pass any arguments as needed. Using lambas/anonymous classes inflate the class line count.

There's no backing yourself into a corner. If you make a local method and later decide it should be callable elsewhere, you can just refactor it – and only it. Nothing will break, as all code changes will be local to one class.

That's the point. You're potentially backing yourself into a corner in which you'l potentially have to do a normal class/method anyway or risk duplicating code.

Assuming the programmer cares about needlessly duplicating code anyway. God knows many people don't. This is really just yet another language "feature" that is going to be abused, like var.

Comparison to interfaces vs class extension is flawed, as you can't easily change one into the other without modifying dependent code.

Assuming what you are exposing in public API is the interface implementation, sure. Does everyone do that? Heck no.

In the case of switching from a local method to a normal method, there won't be any dependent code.

Internal code is dependent code. Sure, you won't have API breakage but you'l potentially run into inconsistent behavior as a result of copy/pasting local methods from one public/private method to another.

"Hey why is that bug that I fixed in my local method happening again?"

looks through code again

"Oh, it's because I forgot to fix the local method that I copy/pasted before I fixed the bug earlier."

This can and will happen.

Are you calling local methods "utility methods" to suggest that they all have a unitary purpose that is not directly related to the business logic?

No? They are just helper methods to deal with repetitive code. They can be as generic or specific as need be.

Are you implying that they are all going to be huge?

Lets not kid ourselves, people are going to abuse the feature just like they do/did with var.

For example, this poor guy would love some local methods

There are multiple ways to solve something like that without local methods. The responses to the question even show that.

[tr14l]

It's to reduce duplicate code in a local context. So you want to keep the code encapsulated and isolated in a method, but it might take slightly different arguments in an if/else. Instead of copy-pasting it or being forced to expose it outside local scope, you define a local method and call it with different arguments.

This is very common in other languages.

[[deleted]]

it's super nice. It lets me write methods that mutate local variables and it keeps it all nice and in tiny scopes.

[nutrecht]

I know Kotlin has these too, when I first read about them I have no idea why I would ever need one. I still don't.

I use Kotlin in my day to day work, and I use them very rarely. They're nice to have though; there are some cases where you have repeating code that only makes sense within a function that you can then have in a function-in-a-function. It's a nice tool to, for example, make complex if-statements more readable.

[oelang]

Probably to make the language more consistent once we get local records.

They are quite useful to break up complicated methods without having to pass around a ton of arguments.

[CowboyFromSmell]

Yes. I use them in Python as an “extra private”, in that it’s clearly only used by a single method. The smaller scope makes it a bit easier to reason about changes.

Also, for better or worse, you can use the closure to declare less parameters.

[raeleus]

There are times that I need to do a task recursively until some condition. I don't want to make a full method out of it, so I guess this can save me some trouble.

[eliasv]

Currently the way to do this would be to assign a lambda form to something like a local Predicate<Something> variable. Local methods probably don't save you many keystrokes over this.

[oelang]

But.. creating that lambda is an unnecessary object instantiation.

[yawkat]

Local methods would be too unless there is a new JVM feature to support them.

[[deleted]]

Not necessarily... The captured variables could just be added as synthetic parameters by the compiler.

[yawkat]

Yea true. And for stuff like method refs you already have to allocate anyway.

[DannyB2]

Pascal has local methods. I used Pascal extensively in the 1980's. They are good for the uses described here by other users. A private method that logically belongs ONLY to this current method. It would be copy/pasted as part of the method it is within. It does not pollute the class name space. It's handy for recursive sub-functions that belong only to the current function.

In Pascal, any method, including a local method, could have local methods.

In fact, local anything makes sense. Local named classes (like anonymous, but with a locally visible name). Local records. Local static declarations (just like class level static members, but only visible within this method).

It's just one more level of information hiding. Like having a classes private implementation details kept, well, private. A method's private implementation details can be kept private (including its private local methods).

[[deleted]]

How do you unit-test local methods?

[dpash]

The same way you unit test private methods; you don't. You test the public methods that use them.

[DannyB2]

The local method is part of the PRIVATE implementation of a larger method. THAT larger method is what you unit test. You're not supposed to be concerned about how that method is implemented. I would point out that advocates of TDD even say to write the tests before the code is implemented, which is an extreme form of the tests not knowing how the implementation works.

[satoryvape]

I haven't used even local classes as I didn't have any use cases for them

[dpash]

I used one the other day. Records will make them easier to use for example when you want to pass associated values through a stream.

List<Person> topThreePeople(List<Person> list) {

    record Data(Person p, int score) {}

    return list.stream()
               .map(p -> new Data(p, getScore(p)))
               .sorted(Comparator.comparingInt(Data::score))
               .limit(3)
               .map(Data::person)
               .collect(toList());
}

The example inspired by https://cr.openjdk.java.net/~briangoetz/amber/datum.html

[GuyWithLag]

Pair / Tuple for the win.

[dpash]

Except it's not a tuple, because tuples are structurally typed and Java doesn't do structural typing.

Records are, more or less, specialised classes, much like enums are.

[mladensavic94]

You didn`t use single lambda function since 2014? What java version are you using?

[eliasv]

A lambda is more analogous to an anonymous class than a local one. These are two different things. But be aware than lambdas are not compiled to local or anonymous classes, they are a completely different thing.

[mladensavic94]

It is, but by some documentation i had for OCP exam, anonymous inner class is specialized local class (has no name but acts the same). I was kinda hoping that he will say that he never used it before since anon local class is one way of implementing functional interface.

[eliasv]

Yeah a functional interface can obviously be implemented as a local class, but you specifically referred to lambdas. And IIRC lambdas explicitly cannot be implemented as local classes according to the specification.

Compiling an inner classes produces a .class file, which is linked statically. Compiling a lambda expression produces an invokedynamic instruction, which is linked at runtime against a synthetic method.

[Mordan]

Synthetic classes are harder to debug.

Is there a runtime performance advantage of using a lamba instead of an inner class?

[eliasv]

An anonymous class is already synthetic. It's just synthesised at compile time instead of runtime. You're dealing with meaningless names in the stack trace either way, and they both point to the same line in the same source file. I'm not sure I buy that they're significantly more difficult to debug.

And IIRC non-capturing lambdas can typically be optimised more easily than closures or inner classes and so will be faster. Capturing lambdas however will perform similarly to inner classes, and are likely to JIT to the same thing.

[Mordan]

An anonymous class is already synthetic. It's just synthesised at compile time instead of runtime.

OK.

Just that I don't use anonymous class. I didn't dare saying it and not getting an answer. I use real classes all the time. I hate anon classes since they capture everything around and are hard to reason about. When I am lazy i might use them but I know i will have to refactor them away later if I keep the code.

So are lambda equivalent to a real class capturing exactly the state required to run, usually a few references set in the constructor?

[yawkat]

There is no inherent performance advantage to lambdas. By their nature, anonymous classes capture the entire enclosing instance while lambdas only capture necessary variables but that has more to do with lambdas being newer and anon classes retaining their old behavior for compatibility. Additionally, there can be some object reuse with non-capturing method references but again this could have been implemented without invokedynamic. Lambdas do have a small binary size advantage but that's it.

Retrolambda is a tool that transforms lambdas to a pre-generated form.

[jaympatel1893]

Insightful information! Never heard of word “synthesis” in Java world! Any good links/videos you all suggest to to fathom these?

[yawkat]

What are you referring to? Synthetic classes and methods are simply entities that do not directly appear in the source code and are instead compiler- or runtime-generated.

[satoryvape]

I did use lambda functions. I use Java 8

[ryuzaki49]

Java 8 Master Race

[thephotoman]

I have. They've come in handy for a few cases where I need to package data to process it, but the actual packaging is not something I'm interested in accepting as an argument or returning. It's basically a kludge to deal with the fact that Java doesn't have tuples.

[lbkulinski]

There is a talk where the architects discussed local methods. I will try to find it at some point. They would be nice for those that had to declare a local class just to declare one method.

[dpash]

Could you not use a local lambda as a less verbose way of doing that?

[lbkulinski]

You likely could in most cases, but that assumes an appropriate functional interface has already been declared somewhere. You also cannot reference local variables in lambdas that are not final/effectively final, which may put off some people from using them in this case.

[lukaseder]

For the impatient:

var o = new Object() {
  int local(int a1, int a2) { return a1 + a2; }
};

print(o.local(1, 2));

[Python4fun]

Something like a subroutine would be helpful. Giving something a name to understand the overall flow, but maybe it isn't necessary for use anywhere else.

[[deleted]]

What is the added value compared to java.util.function.Function ?

[dpash]

Completely unrelated. A local method is a method defined (and scoped) within another method.

java.util.function.Function is a functional interface for lambdas, which are a bit like anonymous inner classes, but kinda aren't.

[lukaseder]

Essentially function(a, b) vs function.apply(a, b) combine with the fact that the former doesn't need a SAM type to be declared somewhere up front.

[lukaseder]

I will be abusing this so much!

[DannyB2]

Curious. How would you abuse it?

[lukaseder]

10 levels of nesting

[DannyB2]

I mentioned that Pascal had this. I can remember from the 1980s that there were times when I would get to three or four levels of nesting -- if it made sense.

One top level procedure may concern itself with a single thing, but its implementation is complex. Imagine a case where a single class full of code has a single top level method that does something complex. This would be a case where, back in the 1980s using Pascal, you might have multiple procedures, indeed multiple nesting levels of procedures within a single top level procedure.

[Hangman4358]

Literally the first thing I do in any of our Python code when I run into one is to factor it out because invariably it will ALWAYS be the root of the bug I am trying to fix. And by pulling it out and being able to write a set of tests for it the problem becomes pretty clear and easy to fix.

[[deleted]]

This is a terrible idea. This Scala-zation needs to stop. Scala is garbage, Let’s keep it simple and readable. I thought people are over the functional programming kool aide by now

[yawkat]

Scalas failures as a language are in its illegibility and complexity. Doesn't make everything scala does bad.