3 ms·

One more way to bypass this requirement is to add a private static method that returns something you want to pass to super()/this(). And on the subject of Java

One more way to bypass this requirement is to add a private static method that returns something you want to pass to super()/this(). And on the subject of Java restrictions that get in the way: if you use a local variable in an anonymous inner class or lambda, it needs to be final. This presents a problem for when you call a method that runs your lambda at some point before it returns and you want to modify some variables from there. The ugly workaround is to declare a final single-element array. It satisfies "needs to be final", but its single element can still be assigned to from anywhere since "final" only applies to the object reference to the array itself.

deleted 4y ago
[deleted]
layer8 4y ago
> One more way to bypass this requirement is to add a private static method This doesn’t work if it requires multiple arguments to be generated with common code, unless you’re okay with effectively running that common code twice, which in turn is problematic when it has side-effects (like logging). See https://news.ycombinator.com/item?id=34482908 https://news.ycombinator.com/item?id=34482908 for an alternative way of solving this.
vbezhenar 4y ago
Yes, inability to modify variables from the lambda is extremely frustrating and makes exactly zero sense as compiler can always convert variable to a wrapper object on the heap. I guess this is another improvement for the future. Too bad that Java's future is Lisp's infancy.
- fidgewidge 4y ago
  Btw Kotlin solves that. You can write to non final variables inside lambdas.
  - vbezhenar 4y ago
    Yep, Kotlin solves almost all pain points with Java and presents a good show-case which Java language developers should have followed IMO. Another examples of Java pain points solved in Kotlin which I could remember: top-level functions (which are actually bundled in some "standard" class name. Pretty much syntax sugar but very nice. Auto cast. Like you check variable with instanceof and after this check it's automatically casted to the target type. Java has some weird syntax for this but I don't see why this was necessary at all. More default imports. Why should I qualify java.util. it's pretty much standard. I'm not asking for every java.x package to be auto-imported, but commonly used packages should be. Class properties instead of getter/setter ceremony. Records are alternative approach but I don't find it useful yet. Nullability. Of course that's a hard question and adding nullability to existing type system looks like gargantuan task. What could be done is introduce some java.xxx annotation, let module projects to be not-null by default (so you don't need to create package-info.java in every package just to make it not-null) and make all nullability issues to be warnings from javac. Basically it's already exists but not standard and implementation quality varies. Reified generics. Basically it's a hidden Class<T> clazz argument passed automatically to the function. This is brilliant solution to type erasure problem and it should really have been adopted. I'd vote for all those features to be implemented in Java similarly to their Kotlin implementations.
- int_19h 4y ago
  Part of it is that lifetimes become complicated. Do you convert each variable into a separate object, or do you shove all of them into a single object representing all captured variables from that frame? If the former, it's very space-inefficient if you're capturing lots of stuff, as is typical with callback-oriented programming. If the latter, then a lambda referring to a single variable from some stack frame will keep all other captured variables in that frame alive. Which can be especially surprising if the lambda that is alive captured a single int, and that causes a huge array that referenced by a different local that can no longer be reached to remain allocated. FWIW C# does the latter, and it works "good enough" in practice. But I've seen more than one mysterious memory leak caused by it, too - I think most of the time they just aren't big enough for people to notice.

deleted 4y ago

[deleted]

layer8 4y ago

> One more way to bypass this requirement is to add a private static method This doesn’t work if it requires multiple arguments to be generated with common code, unless you’re okay with effectively running that common code twice, which in turn is problematic when it has side-effects (like logging). See https://news.ycombinator.com/item?id=34482908 https://news.ycombinator.com/item?id=34482908 for an alternative way of solving this.

vbezhenar 4y ago

Yes, inability to modify variables from the lambda is extremely frustrating and makes exactly zero sense as compiler can always convert variable to a wrapper object on the heap. I guess this is another improvement for the future. Too bad that Java's future is Lisp's infancy.

fidgewidge 4y ago
Btw Kotlin solves that. You can write to non final variables inside lambdas.
- vbezhenar 4y ago
  Yep, Kotlin solves almost all pain points with Java and presents a good show-case which Java language developers should have followed IMO. Another examples of Java pain points solved in Kotlin which I could remember: top-level functions (which are actually bundled in some "standard" class name. Pretty much syntax sugar but very nice. Auto cast. Like you check variable with instanceof and after this check it's automatically casted to the target type. Java has some weird syntax for this but I don't see why this was necessary at all. More default imports. Why should I qualify java.util. it's pretty much standard. I'm not asking for every java.x package to be auto-imported, but commonly used packages should be. Class properties instead of getter/setter ceremony. Records are alternative approach but I don't find it useful yet. Nullability. Of course that's a hard question and adding nullability to existing type system looks like gargantuan task. What could be done is introduce some java.xxx annotation, let module projects to be not-null by default (so you don't need to create package-info.java in every package just to make it not-null) and make all nullability issues to be warnings from javac. Basically it's already exists but not standard and implementation quality varies. Reified generics. Basically it's a hidden Class<T> clazz argument passed automatically to the function. This is brilliant solution to type erasure problem and it should really have been adopted. I'd vote for all those features to be implemented in Java similarly to their Kotlin implementations.
int_19h 4y ago
Part of it is that lifetimes become complicated. Do you convert each variable into a separate object, or do you shove all of them into a single object representing all captured variables from that frame? If the former, it's very space-inefficient if you're capturing lots of stuff, as is typical with callback-oriented programming. If the latter, then a lambda referring to a single variable from some stack frame will keep all other captured variables in that frame alive. Which can be especially surprising if the lambda that is alive captured a single int, and that causes a huge array that referenced by a different local that can no longer be reached to remain allocated. FWIW C# does the latter, and it works "good enough" in practice. But I've seen more than one mysterious memory leak caused by it, too - I think most of the time they just aren't big enough for people to notice.