1

I'm new to Java and have gotten myself into a situation where it's evident that I'm misunderstanding something about how it handles Generics, but reading tutorials and searching stackoverflow hasn't (at least so far) given me clarity beyond that I suspect I'm misusing wildcards. As a heads up I have a C++ background, so how it deals with templates is probably coloring how I've approached this.

Here's the basic structure of my inheritance using representative classes

abstract class PacketHeader{
   // some stuff
}

class TypeOfPacketHeader extends PacketHeader{
   // extended stuff
}

abstract class Packet<T extends PacketHeader>{
    T mHeader;
    // some methods treating T as a type of PacketHeader
    // some abstract methods
}

class TypeOfPacket extends Packet<TypeOfPacketHeader>{
    static TypeOfPacket obtain {
        return new TypeOfPacket();
    }
    // overriden abstract functions that call specific TypeOfPacketHeader methods on mHeader
}

interface PacketParser<T extends Packet<? extends PacketHeader>>{
T obtainPacket();
        void parse(T packet);
}

class ImplementedPacketParser implements PacketParser<TypeOfPacket>{
     TypeOfPacket obtainPacket(){
         return TypeOfPacket.obtain();
     }
     void parse(TypeOfPacket packet){
         // code that relies on TypeOfPacket specific functions
     }
}

That seems to all be correct (or at least eclipse isn't complaining), issues seem to arise when I'm attempting to make use of them. My first attempt was:

class User{
    PacketParser mParser;

    User(PacketParser parser){
        mParser = parser;
    }

    void DoSomething(){
         Packet packet = mParser.obtainPacket();
         // do some stuff with the packet
         mParser.parse(packet);
    }
}

and led to warnings of Raw types. So I tried...

class User{
    PacketParser<? extends Packet<? extends PacketHeader>> mParser;

    User(PacketParser<? extends Packet<? extends PacketHeader>> parser){
        mParser = parser;
    }

    void DoSomething(){
         Packet<? extends PacketHeader> packet = parser.obtainPacket();
         // do some stuff with the packet
         mParser.parse(packet);
    }
}

But this leads to an error that

The method parse(capture#9-of ? extends Packet) in the type PacketParser> is not applicable for the arguments (Packet)

At this point I've decided that I'm misunderstanding something about how the generics are working, so I've turned to stackoverflow to hopefully point me to where I've gone wrong and maybe point me in the right direction.

Khanmots
  • 181
  • 1
  • 10
  • 1
    IMHO Don't go wild with generics trying to describe everything as this is a short road to confusion. Try to keep it as simple as you can and its more likely to make sense. ;) – Peter Lawrey Jun 19 '12 at 20:39
  • Well, to me at least, it seems that it's far easier to get the architecture for these inflection points in the design figured out now rather than try to develop solely for one case now and then shoehorn them in later. – Khanmots Jun 19 '12 at 20:48

2 Answers2

0

I have made some changes to your code.It compiling now.Try using this.

   abstract class PacketHeader {
    // some stuff
   } 
   class TypeOfPacketHeader extends PacketHeader {
        // extended stuff
    }

    abstract class Packet<T extends PacketHeader> {
        T mHeader;
        // some methods treating T as a type of PacketHeader
        // some abstract methods
    }

    class TypeOfPacket extends Packet<TypeOfPacketHeader> {
        static TypeOfPacket obtain() {
            return new TypeOfPacket();
        }
        // overriden abstract functions that call specific TypeOfPacketHeader
        // methods on mHeader
    }

    interface PacketParser<T extends Packet<? extends PacketHeader>> {
        T obtainPacket();

        void parse(T packet);
    }

    class ImplementedPacketParser implements PacketParser<TypeOfPacket> {
        public TypeOfPacket obtainPacket() {
            return TypeOfPacket().obtain();
        }

        private TypeOfPacket TypeOfPacket() {
            // TODO Auto-generated method stub
            return null;
        }

        public void parse(TypeOfPacket packet) {
            // code that relies on TypeOfPacket specific functions
        }
    }

Your User Class.

class User{
    private PacketParser mParser;

    User(PacketParser parser) {
        mParser = parser;
    }

    void DoSomething() {
        Packet packet = mParser.obtainPacket();
        // do some stuff with the packet
        mParser.parse(packet);
    }
}
Akhi
  • 2,242
  • 18
  • 24
0

In your User code, the compiler doesn't know that the ? extends Packet<? extends PacketHeader> on the mParser field is the same type as the Packet<? extends PacketHeader> packet local variable.

You need to bind the type of packet that will be used by making User generic:

class User<T extends Packet<?>> {
    PacketParser<T> mParser;

    User(PacketParser<T> parser){
        mParser = parser;
    }

    void DoSomething(){
         T packet = parser.obtainPacket();
         // do some stuff with the packet
         mParser.parse(packet);
    }
}

// and then when instantiating your User, specify the packet type:
new User<TypeOfPacket>(new ImplementedPacketParser())

Now the compiler knows that the Ts it sees represent the same type of Packet<?>, whereas each time it sees ? extends Packet<?> could be different subtypes of Packet<?>.

Edit: An additional note: the "? extends PacketHeader" is not needed in the PacketParser interface declaration, because the Packet class already limits its T to PacketHeader and its subtypes.

// ? is implicitly constrained to "extends PacketHeader" because of
// the way Packet's generic is defined
interface PacketParser<T extends Packet<?>> {
matts
  • 6,738
  • 1
  • 33
  • 50
  • II think that I understand what's going on now, and I appreciate you pointing out the implicit constraint. Was hoping that since the packet was obtained from the mParser that the compiler would be able to figure it out, but perhaps that was too much to hope for (I sure wouldn't want to try to write the compiler that could do that...) – Khanmots Jun 19 '12 at 20:59
  • Seem to have it all implemented and compiling without errors or warnings now. Had to make a few tweaks at the layer above, but wasn't too bad. Thanks a bundle! – Khanmots Jun 19 '12 at 21:40