1

I have been given an abstract class:

public abstract FooPACImpl {
    ...
}

And two autogenerated subclasses:

public replyTypeFooPAC extends FooPACImpl {
    ...
}
public requestTypeFooPAC extends FooPACImpl {
    ...
}

And an API for creating a network pattern (request/reply) that uses a request Type and a reply Type (A and B are expected to be auto-generated sub-classes of FooPACImpl like the above):

Replier<A, B> get_simple_replier (
    String topic, 
    Object<A> requestType, 
    Object<B> replyType) {...}

Requester<A, B> get_simple_requester (
    String topic, 
    Object<A> requestType, 
    Object<B> replyType) {...}

I pull the topic string, and the string names of the two types A and B from an XML stub:

<rr>
    <topic>MyReqRepTopic</topic>
    <reqtype>foo.bar.baz.myReqTypeFooPAC</reqtype>
    <replytype>foo.bar.baz.myReplyTypeFooPAC</replytype>
</rr>

Apparently, reflection in Java can't handle directly a "public abstract" super class?

FooPACImpl foopa = (FooPACImpl) Class.forName(reqtypeName).newInstance();

results in

java.lang.IllegalAccessException: Class foo.bar.fnorb.ServiceSupport \
    can not access a member of class foo.bar.baz.myReqTypeFooPAC with \
    modifiers "protected"

1) Why "with modifiers 'protected'"? FooPACImpl.getClass().getModifiers returns "public abstract"

2) Is this exception thrown because the class is abstract? or does it have to do with a possible constructor 'protected FooPACImpl () { };'?

3) And, is this even achievable? My understanding is that if you subclass AA with BB, you can use AA where a BB is expected, since BB will have anything that AA is expected to have (methods, fields, etc). Although, it's been awhile. I may be a bit hazy on the particulars of inheritance in java.

Thanks for any points/pointers, and a yes/no answer for #3 is sufficient. In the case of a 'no', hints to how it could be implemented without reflection. I do have access to the code generator templates for the autogenerated stuff, if that helps.

rip...
  • 996
  • 5
  • 20
  • 1
    It would help if you could provide a short but complete example demonstrating the problem - ideally with conventional class names, too... – Jon Skeet Aug 21 '14 at 09:50
  • The error mentions a class foo.bar.fnorb.ServiceSupport, is this the class where you try to do the instantiation? – Koen Weyn Aug 21 '14 at 09:51
  • I think this error might occur if the constructor of class foo.bar.baz.myReqTypeFooPAC is protected. You mention the class is public, but its constructor might be protected. – Koen Weyn Aug 21 '14 at 09:54
  • @KoenWeyn : You nailed it -- the class was public, the ctor of the subclass was protected. Correct, ServiceSupport is the class where I'm doing the reflection in. – rip... Aug 21 '14 at 10:17
  • @JonSkeet : what's the local definition of a conventional class name? – rip... Aug 21 '14 at 10:18
  • @rip...: One that follows [Java naming conventions](http://www.oracle.com/technetwork/java/codeconventions-135099.html). – Jon Skeet Aug 21 '14 at 10:20
  • I had a long comment that stated i.a., I used foo. etc as people had the tendency to focus on minutia that -- whether it was the done thing or not -- had no bearing on the answer. I deleted that and asked "what's the local definition of a conventional class name" because I didn't really understand the context for the comment. Near as I can figure, the "class name" fail was I used lower-case initial on the class names of the two FooPAC examples, and that I didn't use com. or aq. and instead relied on the 'foo' metasyntactic particle. Any others before I fix the OP? – rip... Aug 21 '14 at 11:13

1 Answers1

2

In the auto-generated sub-classes of FooPACImpl, there were two protected constructors:

protected myReqTypeFooPAC() {
    super(...);
}

protected myReqTypeFooPAC(boolean b) {
    super(..., b, ...); 
}

I was looking for the problem in the parent class, but it turned out to be the constructor thing. Changing those to public allowed the code to run as expected, which I can do either using reflection? or by changing the codegen templates...

rip...
  • 996
  • 5
  • 20