41–50 of 50 posts
https://github.com/orfjackal/retrolambda
"Retrolambda lets you run Java 8 code with lambda expressions on Java 7 or lower. It does this by transforming your Java 8 compiled bytecode so that it can run on a Java 7 runtime. After the transformation they are just a bunch of normal .class files, without adding any runtime dependencies."
Can we expect any improvement in startup time so that it becomes a little bit more suitable for command line tools?
Earlier quoted context omitted.
> I'm not sure you understand what you're looking at. Yes, I do. The issue is that their ideas of lambdas work exactly in those cases where using a lambda is just a nice replacement for existing AICs. With that reasoning they thought that they could get away without standard function types. But then, they added their "bulk operations" to collections and started to realize they were in trouble, because there didn't ex…
> But then, they added their "bulk operations" to collections and started to realize they were in trouble, because there didn't exist any SAM types they could use _and_ coming up with names for anonymous function literals was kind of idiotic. But with function types already ruled out and time running short, they decided to make up ad-hoc function types. This is simply not true. Doug Lea, the author of java.util.concu…
How is this in any way disagreeing with what I said? Did you actually look at Doug Lea's reasoning back then? I don't think he would defend any of his claims today. Back then, the issues caused by not having function types just weren't anticipated. This would be obvious if one followed the appropriate mailing lists where this was discussed in depth.
> Already back in 2007-2008 it became clear that function types are a bad fit for Java. Java's designers explicitly mentioned currying, general functional-style programming, and user-defined control structures as things they wanted to avoid.
Beating down your own straw men seems to be your hobby, I guess?
> Again, not true. Java's designers are extremely focused on performance, and did not "realize" all of a sudden boxing has a non-negligible impact on performance.
No, they were just betting the house that the JVM engineers would save their asses, but as we know that didn't work out so well. They didn't really have a plan B, so they started to manually duplicate code for some primitive types.
> Again, the idea is always do the least "powerful" thing possible that will give you the most benefit.
This hasn't worked out at all and is one of the reasons why Java is incredibly hard to evolve. One just can't keep piling half-assed ideas on top of each other forever.
Anyway, I'm not sure why you are so defensive. Yes, Java will ship with some kind of lambdas, but they will be inferior to pretty much anything out there in terms of usability, readability, maintainability, performance and will be a major pain point when evolving the language in the future.
Why not just accept it and move on?
Earlier quoted context omitted.
> I love the myth that java never broke backwards compatibility. Bytecode maybe (), they definitely broke syntax compatiblity. Proof?
If by "syntax compatibility" he means code that compiles in one version does not compile is another, that's definitely true. Name collisions with the new default methods in Java 8 are one source. If your Comparator-implementing class has a method "void reverseOrder()", that will no longer compile. Here's a couple of recent examples the Guava authors have fixed. Fortunately they were in internals and not their public…
What is meant by "breaking backward compatibility" is when the grammar is altered in a way that makes existing sources no longer compile.
Earlier quoted context omitted.
I don't know if you're just being naïve or if you have absolutely no clue about language design. In case it's the former, "a lot nicer" is subjective, so it carries no weight in the discussion. If the latter... well, go read a few books on compiler design and language theory.
Yes, insult away. You do know D the language was written by compiler expert, right - if you had a point or just insult.
Earlier quoted context omitted.
> But then, they added their "bulk operations" to collections and started to realize they were in trouble, because there didn't exist any SAM types they could use _and_ coming up with names for anonymous function literals was kind of idiotic. But with function types already ruled out and time running short, they decided to make up ad-hoc function types. This is simply not true. Doug Lea, the author of java.util.concu…
> This is simply not true. Doug Lea, the author of java.util.concurrent, and of ForkJoin in particular, was one of the main driving forces behind lambdas; he requested them about 7 years ago precisely for those bulk operations. The same Doug Lea rejected function types way back then in favor of CICE. How is this in any way disagreeing with what I said? Did you actually look at Doug Lea's reasoning back then? I don't…
Because it's not true. I don't know if you've seen the lambda performance benchmarks but they're pretty darn good. I don't know what you mean by "usability" but some uses of lambdas in other languages are not a right fit for the Java philosophy. When it comes to maintainability, lambdas are great. Method handles don't enforce any particular implementation strategy, and the current language does not even preclude introducing function types in the future if it proves to be as big a pain point as you claim; OTOH, introducing function types now would have made it pretty much impossible to go back.
Now, let me be clear: I am not saying Java is the best language out there (I don't think such a thing exists). I am not even saying it's the best language for the specific goals it took upon itself. All I'm saying is that given its unbelievably huge adoption, backwards compatibility and philosophy, its maintainers are doing a pretty good job.
Earlier quoted context omitted.
Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that doesn't seem to be true.
> Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/pa... The amount of times they managed to back themselves into a corner is just horrifying. > Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that do…
Nonsense. Just because you throw out a design doesn't mean that "everything is lost": you've learned a lot in the process and you're going to use that knowledge to draft the next design.
Java is often made fun of for moving at a glacial pace but quite a few languages could learn a thing or two about the benefits of shipping features that are designed right from v1 (Scala has been much more reckless in that area).
Earlier quoted context omitted.
> Only briefly - it looks pretty straight forward. Could you explain what's wrong with it? I think this link says it all: http://download.java.net/jdk8/docs/api/java/util/function/pa... The amount of times they managed to back themselves into a corner is just horrifying. > Also they pushed a number of features that were going to land in Java 7 back to Java 8 because there wasn't enough time to finish them. So that do…
> Anyway, they recently started from scratch again on modularization, so pretty much all the work done on Jigsaw before that is lost anyway Nonsense. Just because you throw out a design doesn't mean that "everything is lost": you've learned a lot in the process and you're going to use that knowledge to draft the next design. Java is often made fun of for moving at a glacial pace but quite a few languages could learn…
... which is exactly what I said in the next sentence, right? :-)
> but quite a few languages could learn a thing or two about the benefits of shipping features that are designed right from v1
Eh, could you mention a few things which were "designed right from v1"? I can only imagine enums, but what else?
Earlier quoted context omitted.
Yes, insult away. You do know D the language was written by compiler expert, right - if you had a point or just insult.
I was not questioning Andrei's skills, only yours.
Java has a reputation of a bad community, and you just underline it here.
Earlier quoted context omitted.
Yes, Yes I do. And as for backward compatibility, they already did. I love the myth that java never broke backwards compatibility. Bytecode maybe ( ), they definitely broke syntax compatiblity. : The various xml parsers and other library thrash really do break backwards bytecode compatiblity.
> I love the myth that java never broke backwards compatibility. Bytecode maybe (), they definitely broke syntax compatiblity. Proof?