Prev: Getting rid of "if condition" by some math equation.
Next: String.intern() (Was: create a string of <n> equal chars <c>)
From: Andreas Leitgeb on 16 Jul 2010 18:02
>> Lew wrote:
>>> Not only is it more typing (and you know I don't regard that as much
>>> of an excuse), but it requires some compilation magic for enum
>>> instances' inner-class bodies to get at an enclosing private
>>> constructor, not needed when they access an enclosing package-private
>>> constructor.

> Andreas Leitgeb wrote:
>> What would an [enum instance's] inner-class body do with an outer enum's constructor?

Lew <lew(a)lewscanon.com> wrote:
> Use it to generate its own implicit constructor, of course. They're
> just like any other anonymous inner class that way.

My apologies for missing the "instance's"-part.

I'm still puzzled about that gross hack of creating bridge-methods(&c'tors)
rather than letting the jvm recognize certain accessors of privates as still
legal. There surely exists some reason for it somewhere out there.

From: ClassCastException on 16 Jul 2010 22:23
On Fri, 16 Jul 2010 22:02:30 +0000, Andreas Leitgeb wrote:

> I'm still puzzled about that gross hack of creating
> bridge-methods(&c'tors) rather than letting the jvm recognize certain
> accessors of privates as still legal. There surely exists some reason
> for it somewhere out there.

Security, most likely. The bridge methods can be made by the compiler.
Recognizing certain outside accesses of private members, at the bytecode
level, as legal would require relaxing some of the stringent checks done
by the JVM's bytecode verifier, which could in turn potentially create
exploitable security holes.
From: Andreas Leitgeb on 17 Jul 2010 22:54
ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
> On Fri, 16 Jul 2010 22:02:30 +0000, Andreas Leitgeb wrote:
>
>> I'm still puzzled about that gross hack of creating
>> bridge-methods(&c'tors) rather than letting the jvm recognize certain
>> accessors of privates as still legal. There surely exists some reason
>> for it somewhere out there.
>
> Security, most likely. The bridge methods can be made by the compiler.
> Recognizing certain outside accesses of private members, at the bytecode
> level, as legal would require relaxing some of the stringent checks done
> by the JVM's bytecode verifier,...

Not relax, just change.
Every class that has inner classes has an attribut "InnerClasses" defined.
If some class attempts to access private parts, the jvm would just have
to check the "InnerClasses" and know if that access would be granted or
denied.
My (€0,00 valued) bet is on "hysterical raisins" :-)
From: ClassCastException on 17 Jul 2010 23:49
On Sun, 18 Jul 2010 02:54:51 +0000, Andreas Leitgeb wrote:

> ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
>> On Fri, 16 Jul 2010 22:02:30 +0000, Andreas Leitgeb wrote:
>>
>>> I'm still puzzled about that gross hack of creating
>>> bridge-methods(&c'tors) rather than letting the jvm recognize certain
>>> accessors of privates as still legal. There surely exists some reason
>>> for it somewhere out there.
>>
>> Security, most likely. The bridge methods can be made by the compiler.
>> Recognizing certain outside accesses of private members, at the
>> bytecode level, as legal would require relaxing some of the stringent
>> checks done by the JVM's bytecode verifier,...
>
> Not relax, just change.
> Every class that has inner classes has an attribut "InnerClasses"
> defined. If some class attempts to access private parts, the jvm would
> just have to check the "InnerClasses" and know if that access would be
> granted or denied.

Could a hostile class make itself appear to be a member of that set, as
far as the verifier was concerned?

There is also the matter that runtime access to all privates would be
granted, not just to the particular ones for which javac made synthetic
accessors. A newer (or maliciously substituted) version of an inner class
could get at all the privates of an older version of the enclosing class.

> My (€0,00 valued) bet is on "hysterical raisins" :-)

Despite what I've said, this seems the most likely.
From: Andreas Leitgeb on 18 Jul 2010 07:44
ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
> On Sun, 18 Jul 2010 02:54:51 +0000, Andreas Leitgeb wrote:
>> ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
>>> On Fri, 16 Jul 2010 22:02:30 +0000, Andreas Leitgeb wrote:
>>>> I'm still puzzled about that gross hack of creating
>>>> bridge-methods(&c'tors) rather than letting the jvm recognize certain
>>>> accessors of privates as still legal. There surely exists some reason
>>>> for it somewhere out there.
>>> Security, most likely. The bridge methods can be made by the compiler.
>>> Recognizing certain outside accesses of private members, at the
>>> bytecode level, as legal would require relaxing some of the stringent
>>> checks done by the JVM's bytecode verifier,...
>> Not relax, just change.
>> Every class that has inner classes has an attribut "InnerClasses"
>> defined. If some class attempts to access private parts, the jvm would
>> just have to check the "InnerClasses" and know if that access would be
>> granted or denied.
> Could a hostile class make itself appear to be a member of that set, as
> far as the verifier was concerned?

It would be the same effort as to fake access to each bridge method.
If one goes that far (namely monkeying with the original package/zip),
one could just as well patch away the "private" flag from the target
class's methods.

> There is also the matter that runtime access to all privates would be
> granted, not just to the particular ones for which javac made synthetic
> accessors.

On Java level, an inner class can call anything from the outer class.
Also, Java doesn't really protect from sufficiently well-done monkeying
on class files. Restricting a possibly patched inner class to only the
bridged methods seems goofy to me, unless it was just the side effect
of some other goal. A malevolently patched inner class could likely do
enough bad things with just the bridged methods, already.

>> My (€0,00 valued) bet is on "hysterical raisins" :-)
> Despite what I've said, this seems the most likely.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Getting rid of "if condition" by some math equation.
Next: String.intern() (Was: create a string of <n> equal chars <c>)