retrolambda icon indicating copy to clipboard operation
retrolambda copied to clipboard

Incremental support for default/static methods in interfaces

Open evant opened this issue 7 years ago • 3 comments

As far as I know, the only reason default/static methods in interfaces isn't enabled by default is because it has to process the interface and the implementations together not allowing it to be incremental. I'd like to try to figure out how to fix this. It seems like there needs to be some metadata at the usage sites to know that the interface it's dealing with has default methods. Would it make sense to read from the ouptdir to see if a helper class was generated? Or maybe generate an extra metadata file that could be read in?

evant avatar Mar 15 '17 14:03 evant

Storing metadata inside the interface or an external file solves part of the problem. Another problem is that javac will be unaware of that metadata, so you would not be able to compile code which depends on the backported classes, unless you recompile everything. Whatever solution will also need to think that how it will fit the workflows of build tools and IDEs.

luontola avatar Mar 17 '17 08:03 luontola

My thinking is that it will be best to make it easy to use retrolambda on an uberjar, instead of backporting every module individually. But if you can produce a proof of concept that works reliably some other way, it would be cool.

luontola avatar Mar 17 '17 08:03 luontola

Yeah that was part of my plan, provide deps as java 8 and let retrolambda process them as well. That way you don't need a partially processed jar.

evant avatar Mar 17 '17 13:03 evant