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

[Andrew Hughes]

----- 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.

> 
> 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
> >>
> >
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07