RFR: 8014513: Sjavac doesn't detect 32-bit jvm properly
Kumar Srinivasan
kumar.x.srinivasan at oracle.com
Mon Jun 10 09:37:52 PDT 2013
On 6/10/2013 9:16 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> Hello Kumar,
>>
>> I'm not sure if I need a sponsor for pushing, do I? I'm a jdk8 reviewer.
> I believe a sponsor is only for those without commit access. As Kumar
> is a reviewer, you should have all you need now to push this.
>
> Incidentally, http://openjdk.java.net/bylaws makes no mention of a "sponsor"
> other than in the context of a group sponsoring a project. So I'm not sure
> where the concept comes from, but it's not part of the rules.
I think I used the term sponsor loosely, what I meant was, does this
need to be pushed
to TL/langtools, if so does Erik wants to push it or does he want
someone else to do so.
It appears that he is all set.
Thanks
Kumar
>
>> 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