To allow for partial implementation we'd still have to subclass and implement the abstract methods to do something.
So either they delegate to some other method like InvocationHandler.invoke or we implement them to throw a RuntimeException or Error like AbstractMethodError. If someone wanted them to throw AbstractMethodError, they could implement their InvocationHandler.invoke to throw it. We could definitely make an annotation that implies this is the behavior someone wants. In fact, we could have annotations that imply how an abstract method should be handled and allow people to use them either on the bean class or the individual method. -David On Sep 21, 2013, at 11:19 AM, Romain Manni-Bucau <[email protected]> wrote: > wouldn't it be more relevant to replace it by interceptors? = allow > abstract ejb if an interceptor intercepts them. > > the ejb would have @AbstractAllowed and the interceptor @Handle or sthg > like that > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* > > > > 2013/9/21 David Blevins <[email protected]> > >> On Sep 21, 2013, at 4:40 AM, Romain Manni-Bucau <[email protected]> >> wrote: >> >>> I think we already have it through cdi and decorators but it doesnt hurt >> to >>> get it this way ;). >> >> Similar to decorators, yes. Just as the @Proxy+InvocationHandler concept >> is similar to interceptors. >> >> Big difference in both from their decorator/interceptor equivalent is that >> with those you'd still be required to have concrete bean class. Sort of a >> downer if you never actually want it to be called. >> >>> Fun feature allowing partial impl btw! >> >> Exactly! And interestingly enough, since it's a subclass and the subclass >> *is* the actual class instantiated, even "this" invocations to abstract >> methods will go to the invoke(..) method. >> >> >> -David >> >>
