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

Erik Joelsson erik.joelsson at oracle.com
Thu Jul 11 07:42:52 PDT 2013


Friendly reminder that this still needs feedback. This issue needs a 
solution for the security team to be able to adopt the new build.

Thanks
/Erik

On 2013-06-25 13:05, Erik Joelsson wrote:
> The way I understand sjavac, multiple -sourcepath options are used to 
> define separate filter rules (include/exclude) for each such option. 
> Here is the way this is already implemented:
>
> 1. sjavac will apply the filter rules and build a list of visible 
> sources, from all sourcepaths.
> 2. The list of visible files is handed to SmartFileManager.
> 3. All sourcepath options are concatenated and handed to javac.
> 4. When javac needs to look up a source, it turns to SmartFileManager 
> that will check the list and see if the source is actually visible.
>
> What this patch does is acknowledging that there is a difference 
> between -src and -sourcepath (one is for source to be compiled, the 
> other source to be linked to) and because of that, it sometimes makes 
> sense to add the same source root to both of these options, but with 
> different filtering rules.
>
> /Erik
>
> On 2013-06-20 21:00, Jonathan Gibbons wrote:
>> 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