RFR: 8014513: Sjavac doesn't detect 32-bit jvm properly

[Kumar Srinivasan]

Hi  Erik,

I am so sorry I responded to the wrong email, I was referring to 8014513.
subj line corrected

Kumar

> Hi Erik,
>
> So what else needs to be done for this ?  I take it this has been 
> reviewed by Jon
> who is the most familiar with it. If all it takes is someone to 
> sponsor this push,
> I can do so, let me know.
>
> Thanks
>
> Kumar
>
>> 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
>