This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RawData ?


Tom Tromey writes:
 > >>>>> "Michael" == Michael Koch <konqueror at gmx dot de> writes:
 > 
 > Michael> Execept the copyright statement and package name both java
 > Michael> files are identical. Thats why I thought they could be
 > Michael> merged.
 > 
 > I've been wondering, but haven't yet brought up, whether this is
 > something Classpath really wants to do.  It imposes a cost on all
 > implementing VMs, and compilers.
 > 
 > Note that we don't even handle RawData properly -- for instance I
 > think `Object foo = <Rawdata>' should be invalid.  Any cast to RawData
 > should also be rejected by the compiler.

Yes.  Some code assumes that everything is a subclass of Object and so
we don't need to check the cast.  This is a good optimization.
RawData breaks the type system in this regard.

 > Likewise the interpreter and verifier probably need special cases
 > here.  There may be other problems, in reflection or JNI.  I'm not
 > sure.
 > 
 > 
 > Hmm, maybe we should get rid of it and use long :-)

I'm wondering if it might be a good idea to have a type which is the
equivalent of "integer attribute ((mode(pointer)))" or somesuch.
However, it wouldn't need to be an arithmetic type.

We could then replace all instances of RawData with that.  We wouldn't
be able to use it for an IdentityHashmap key, which would be a shame.

 > If Classpath does continue with this, we could consider changing.  A
 > patch to do this would also have to change the compiler (that's easy
 > in this case though).

Seems reasonable.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]