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

[Jacob Wisor]

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.

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

Jacob