Groups > comp.lang.java.programmer > #5800

Re: Automatic linking of related objects in constructor

Path	csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From	supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Newsgroups	comp.lang.java.programmer
Subject	Re: Automatic linking of related objects in constructor
Date	Thu, 30 Jun 2011 18:23:46 -0400
Organization	supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
Lines	29
Message-ID	<iuit1i$e85$1@speranza.aioe.org> (permalink)
References	<eYKdnUijTfibapfTnZ2dnUVZ_uadnZ2d@westnet.com.au> <iuf5rd$26m$1@dont-email.me> <alpine.DEB.2.00.1106302133350.3024@urchin.earth.li>
NNTP-Posting-Host	sVU5oalDgoYYKaoZo9xviQ.user.speranza.aioe.org
Mime-Version	1.0
Content-Type	text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding	7bit
X-Complaints-To	abuse@aioe.org
User-Agent	WinVN 0.99.12z (x86 32bit)
X-Notice	Filtered by postfilter v. 0.8.2
Xref	x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5800

Show key headers only | View raw

On 30/06/2011 5:51 PM, Tom Anderson wrote:
> As i said, this is not actually a good idea - too clever for its own
> good, and probably has some gaping vulnerability i haven't thought of -

1. setAccessible(true) followed by your choice of reflection dirty
    tricks -- either on A, or B, or even the "unmodifiable" Set
    returned by A.getBs().

2. public class C extends B implements Cloneable, Serializable

    followed by clone, round-trip through ObjectFooStreams and a byte
    array or disk file, etc. etc.

3. Native code hacks -- pass a B to a native method that then goes to
    town on it with C pointer arithmetic and unsafe casts.

4. Assorted byte code hacking.

Of course 1 won't work in e.g. unsigned applets, nor 3, and 4 probably 
won't pass the bytecode verifier in stock JVMs, though 4 combined with 
gcj or Jet compilation to native code might work. 2 is the biggest hole 
but you can implement clone and writeObject in B to throw exceptions to 
plug it. Note that just copying the object by either method will break 
the invariant, and serialization adds the ability to further hack the 
serialized object while it's in the form of a defenseless byte array or 
disk file.

If you want safety combined with serialization you need the B-has-a-C 
strategy pattern approach, I suspect.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Automatic linking of related objects in constructor "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-06-29 19:56 +1000
  Re: Automatic linking of related objects in constructor "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-06-29 19:58 +1000
  Re: Automatic linking of related objects in constructor Lew <noone@lewscanon.com> - 2011-06-29 07:28 -0400
  Re: Automatic linking of related objects in constructor Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-29 08:29 -0400
    Re: Automatic linking of related objects in constructor Tom Anderson <twic@urchin.earth.li> - 2011-06-30 22:51 +0100
      Re: Automatic linking of related objects in constructor supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-30 18:23 -0400
  Re: Automatic linking of related objects in constructor markspace <-@.> - 2011-06-29 09:17 -0700
  Re: Automatic linking of related objects in constructor supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-06-29 19:58 -0400

csiph-web