On Mar 30, 2016, at 5:17 AM, MacGregor, Duncan (GE Energy Connections) <duncan.macgre...@ge.com> wrote: > > I’ve been doing some work on getting useful coverage information from Jacoco > for Magik, and some of the same issues probably apply to other JVM language > implementations such as JRuby and Nashorn, so I thought I’d ask a couple of > things here. I’m attempting to get some changes into Jacoco to better handle > source files which are not organised in the standard java way, either because > they are organised according to other existing conventions (as in our case), > or in an extremely ad hoc fashion (javascript/nashorn). > > > 1. What are people recording as the source file for their generated class > files? Does it include an absolute or relative path (is it relative to some > well defined root)? > 2. What package are your classes in? > > The three current proposals for changing jacoco are to > > 1. Ignore the package when a source file contains directory separators > 2. Add an “ignore package” configuration option for source lookup > 3. Add configuration options to ignore packages for specified file > extensions > > I think any of these three options would work in my case, but I’d like to > make this change as widely applicable as possible.
(Sounds like they need something like the javac -sourcepath option, plus maybe stuff like "patch -pN" to elide path components. Too many degrees of freedom.) For java.lang.invoke code, most generated classes are in 'java.lang.invoke' (surprise!). Most are anonymous classes (which means there is an illegal slash "/" in the Class.getName.) Somewhat perversely, we store a SourceFile attribute of "LambdaForm$something", where the something is vaguely informative on the theory that it will soothe irritated readers of backtraces. PDH (probably doesn't help) — John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev