RFR: 8015145: Smartjavac needs more flexibility with linking to sources

Jonathan Gibbons jonathan.gibbons at oracle.com
Thu Jun 20 12:00:33 PDT 2013

I'm not sure about the presumption that multiple -sourcepath options are 
OK, unless they are concatenated later in sjavac.  javac only accepts 
the last one.

-- Jon

On 06/19/2013 11:36 PM, Erik Joelsson wrote:
> Trying again. I would like to get a formal review on this if possible.
> /Erik
> On 2013-06-13 09:41, Erik Joelsson wrote:
>> Would be great if someone could take a look at this, thanks.
>> /Erik
>> On 2013-06-07 14:43, Erik Joelsson wrote:
>>> Here is a patch solving a problem with -sourcepath for sjavac.
>>> First some background. The security sources (the ones that require 
>>> signing) need to be built to a separate directory. If they aren't 
>>> (as is the case now) security tests will fail if run on the exploded 
>>> jdk image (the one you get when just typing make or make jdk). In 
>>> JDK-8009280, I'm trying to fix this. The solution I have for that 
>>> bug is working well, except when running with sjavac, and basically 
>>> builds all classes except the security classes first to the normal 
>>> outputdir and then as a separate step builds just the security 
>>> classes to a different outputdir.
>>> There are two issues that need to be addressed in sjavac for this to 
>>> work. First, it needs to be possible to supply the same source root 
>>> both to the -src and -sourcepath option (but with different filter 
>>> rules). Sjavac is very picky and only links to sources that are 
>>> included in either of those options, and since we are excluding the 
>>> security sources from -src, we need to add them to -sourcepath.
>>> The second thing is more of a bug as far as I can tell. Sjavac 
>>> compares the found set of sources to compile with what the makefile 
>>> think needs to be compiled, as a safety check. Currently, sjavac is 
>>> including sources that are just being linked to in this comparison. 
>>> I would think that it should only include sources that are meant to 
>>> be compiled.
>>> http://cr.openjdk.java.net/~erikj/8015145/webrev.langtools.01/
>>> http://bugs.sun.com/view_bug.do?bug_id=8015145
>>> /Erik

More information about the compiler-dev mailing list