RFR: 8014513: Sjavac doesn't detect 32-bit jvm properly
Erik Joelsson
erik.joelsson at oracle.com
Mon Jun 10 00:51:46 PDT 2013
Hello Kumar,
I'm not sure if I need a sponsor for pushing, do I? I'm a jdk8 reviewer.
Both of these changes still need to be properly reviewed by someone in
langtools, probably Jon. There will be additional work in the build
scripts to get sjavac default and the problems resolved for the JCE
team, but I will handle that in jdk8/build as usual.
/Erik
On 2013-06-07 22:52, Kumar Srinivasan wrote:
> 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
>>
>
More information about the compiler-dev
mailing list