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

Reply via email to