-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eliminate the need for VM agent #27
Comments
Is there some disadvantage to using the Java agent? For example some project that is unable to use Retrolambda because of it. I can only come up with the disadvantage of requiring the typing of more command line parameters, but invoking Retrolambda should anyways be automated in the build. I'm worried that relying on the internal dumping mechanism would be more fragile - the implementation details are more likely to change between Java 8 releases. The Java agent mechanism only assumes the naming pattern of the generated classes. The dumping mechanism assumes details of how Regarding this patch, instead of faking the file system, it would be preferrable to override |
This is quite interesting as I'm currently working on something similar to what @jtulach is attempting. In RoboVM we would like to support Lambdas so what I'm doing is to break out the stuff from OpenJDK which is responsible for creating the bytecode for the lambda inner classes at runtime ( Would you guys be interested in using this? I haven't published anything yet but once it works I will put it somewhere under the RoboVM organization. |
If somebody is compiling Java 8 code with lambdas, that means that they have JDK 8 on their development machine and they will always be able to run Retrolambda under Java 8 as part of their build. I don't see any advantage in trying to avoid the Java 8 runtime or Java agents. On the contratry, a third-party mechanism of generating the lamdba classes has the disadvantage that it has not been tested as much as the JDK's implementation and it may have its own bugs. Plus it's more code to maintain. In RoboVM's case it makes sense to include the lambda reification in the RoboVM compiler, to have one tool that does all the work. But you are anyways generating native code, which is a much bigger problem scope than just backporting lambdas to older Java VMs. |
Hello Niklas. I was glad to find RetroLambda as writing the same from scratch would
2014-08-17 16:55 GMT+02:00 Niklas Therning notifications@github.com:
|
Hello Esko, Also I wanted to avoid starting separate VM during the Maven execution. Right, the dumping mechanism may more easily go away, while the actual Subclassing ProxyClassesDumper was the first thing I wanted to try, but 2014-08-17 11:07 GMT+02:00 Esko Luontola notifications@github.com:
|
That's a good point. If we can avoid forking the process, then it would also make the build faster. The overhead of starting a JVM is about 100-200ms and that is multiplied by the number of modules times two (i.e. main and test classes). I think that feature should be toggleable, just in case it causes problems for some (e.g. Maven is not run under Java 8 or the dumper implementation changes). I can have a look at it. |
Please create a pull request where instead of modifying |
As requested: #28 |
This has been included in Retrolambda 1.6.0. It made my other project's build faster - from 52 to 42 seconds. 👍 |
I eliminated the need for VM agent by hooking into internal lambda classes dumping mechanism. I don't know if that is direction you'd like to move, so I am not starting a pull request, rather than recording my work in an issue.
The text was updated successfully, but these errors were encountered: