[rfc][icedtea-web] policytool in itweb-settings

[Andrew Hughes]

----- Original Message -----
> On 01/23/2014 11:16 PM, Andrew Hughes wrote:
> >> On 01/22/2014 07:57 PM, Andrew Azores wrote:
> >>> On 01/22/2014 07:26 AM, Jacob Wisor wrote:
>  >>> [...]
> >>> Amazing, thank you for all the help with this! But are you sure about
> >>> this
> >>> problem of the constant going out of scope of the Thread? Yes, variables,
> >>> method
> >>> parameters, and exception handler parameters will never be *shared*
> >>> between
> >>> threads (as in each Thread will have a local variable by the same name
> >>> but
> >>> these
> >>> two will be distinct from each other in memory), but does this really
> >>> mean
> >>> that
> >>> the variable can go out of scope for the Thread by the time it runs?
> >>
> >> First of all, the term "scope" in the context of programming languages
> >> only
> >> refers to visibility of memory resource identifiers from a given section
> >> of
> >> source code. It has no implications on nor any assumptions can be made
> >> based
> >> upon it about the visibility of memory resources in any target execution
> >> environment. A given programming language scope may or may not have an
> >> equivalent abstraction, representation, or constraint in the target
> >> execution
> >> environment. In Java, both cases can be found, depending on the language
> >> construct. So, please do not confuse applying the term "scope" from a
> >> programming language to an execution environment. Most execution
> >> environments
> >> do
> >> not deal with scopes. They rather have limitations on addressing modes or
> >> have
> >> memory management units etc.
> >>
> >> In the source code at hand, Runnable.run() does not lose scope of
> >> launchCommand.
> >> Otherwise, the source code would not compile, simply because scope
> >> checking
> >> is
> >> done at compile-time, never at run-time. However, what bothered me was
> >> that
> >> Runnable.run() needs to access the object via the reference stored in the
> >> local
> >> constant variable launchCommand. Accesses can only be accomplished through
> >> reading the value of a field, an array element, or a local variable (or a
> >> return
> >> value that is also placed on the stack). And, since launchCommand isn't
> >> passed
> >> and stored nowhere in the source code explicitly to Runnable, I would
> >> rather
> >> assume it is not going to be available at run-time. So, I decided to dig
> >> deeper
> >> into this by disassembling the relevant classes. As it turns out, the
> >> OpenJDK
> >> 7
> >> compiler synthesizes a "final synthetic java.lang.String[]
> >> val$launchCommand"
> >> field in Runnable. IMHO this is a violation of the Java Language Spec. It
> >> is
> >> no
> >> violation of the JVM Spec, of course. But, it is annoying and confusing
> >> that
> >> the
> >> so called "Java reference implementation" silently starts to violate the
> >> Java
> >> Language Spec in order to get around corner cases or to patch things up so
> >> that
> >> it just runs. :-( This means that you can never be sure about the code
> >> that
> >> the
> >> compiler is going to generate or rather you have to be always aware that
> >> it
> >> will
> >> possibly generate some wired and dubious stuff into your byte code. This
> >> is
> >> totally against Java's original intention of a compile-time error
> >> preventing
> >> type-safe verifiable platform. *rant start* They have turned this idea
> >> upside
> >> down by eliminating errors silently or implicitly instead of leaving
> >> programmers
> >> in control of their programs and the way they want to solve problems. Why
> >> did
> >> they do that? Did they fear some programmers being to dump to solve
> >> problems
> >> themselves? *end of rant*
> >>
> >
> > I'm assuming this is using OpenJDK's javac to compile?
> 
> Right.
> 
> > Out of interest, have you tried compiling it with ecj and seeing if that
> > gives a different result or emulates
> > the same hack?  I suspect this is something that was done to support inner
> > classes.
> 
> No, I did not try ecj, and I probably won't because of enough time already
> spent
> digging into it. But, I did try compiling with OpenJDK 7's javac with -source
> and -target switches set to different versions. On all instances the compiler
> did generate synthetic fields but with varying values in field_info
> structure's
> access_flags field. For some versions those synthetic fields were flagged
> ACC_PRIVATE, some 0 (default) and/or ACC_FINAL, and once even ACC_PUBLIC
> (wtf?).
> :-D For versions prior to 1.6 the field_info.access_flags field has never
> been
> flagged with ACC_SYNTHETIC which seems to be correct.
> 
> I don't know whether this is a hack, but a compiler that does this kind of
> implicit code generation seems to violate the Java Language Spec imho. Simply
> because the Java Language Spec does not state whether accessing local
> constant
> variables from an inner class on a different thread is a legal construct or
> not,
> or what the side effects of it are. Do I get to access this synthetic field,
> e.g. using a different language than Java or when using this inner class as a
> library? IMHO this violates the memory model specified in §17.4, especially
> §17.4.1 for shared variables. Or, the spec is perhaps not clear enough about
> this and should be amended in §4.12.4, §8.1.4, and/or §17.4.1?
> It is just confusing that the generated code does not reflect the source
> code.
> 

Yeah.  ecj is the only alternate up-to-date implementation I know of.  If it does
the same thing, then it's clearly some kind of defacto standard for handling this,
illegal as it may be.  If it complains and errors out, that's a clear javac bug
and there's more chance of it being fixed.

> > As to the PolicyTool issue itself, it seems the bug in building on 6 is due
> > to:
> >
> > changeset:   2400:b3466e2c3819
> > user:        mchung
> > date:        Tue May 18 13:12:46 2010 -0700
> > summary:     6951599: Rename package of security tools for modularization
> >
> > a change in OpenJDK 7 which moved PolicyTool from sun.security.tools to its
> > own
> > package, sun.security.tools.PolicyTool:
> >
> > -       $(call make-launcher, policytool, sun.security.tools.PolicyTool, ,
> > )
> > +       $(call make-launcher, policytool,
> > sun.security.tools.policytool.PolicyTool, , )
> 
> So, I was right about that some tools' package names had been changed. :-)
> 
> > If that's the only issue with using that, I don't see why we couldn't just
> > backport
> > that change to OpenJDK 6 so the location is consistent across all JDKs
> > again.
> >
> 
> Hmm... just thinking; what about software that already has been adapted to
> this
> change since the release of OpenJDK 7? It may assume this change still being
> in
> effect when running on a Java 6 JRE. Or, what about software that has never
> been
> or never will get updated to accommodate for this change, simply because it
> has
> been compiled for no later than JDK 6 only? This backport would break that
> software too.
> 

I thought the same pretty much after posting this, and even more so when Andrew
basically told me on IRC that this code was never designed to be run from Java code
anyway (it calls System.exit).

> Jacob
> 

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