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