On 21 Apr 00, at 15:38, Jonathan K. Weedon wrote:
> Dan,
>
> So, how do APIs in Java which are untyped handle this problem.
> For example, the reflection APIs in Java are untyped. So, how
> do I call a method using reflection which takes an "int" parameter.
> The answer, of course, is to use wrapper types. So instead of
> an "int", I have to pass an "Integer". So it goes with EJB, at
> least in our product. The PK type will be "int", but if you
> call getPrimaryKey (which is an untyped method) you get back
> an "Integer" containing the PK's value.
Hi Jonathan,
This is fair enough and what I expected. Although beans written to
use primitive types as a primary key wouldn't be portable, this is
true of many vendor extensions. The question for the bean
developer is always to balance the value of the extension against
the cost of not being portable. I think for this list, the more
interesting question is the one you raise about the design of the
specification:
> Again, the benefit with this approach is that it is syntactically
> invalid to set the PK to null. An "int" can never have a
> null value. Which again, is very much in alignment with the
> concept of a primary key.
>
> So again, "int" ought to be a valid PK type. Why would it not
> be?
>
Before your e-mail, I had never even considered the possibility of a
null primary key object. I went hunting through the spec just to
make sure it was legal. It seems to be, so thank you for making
me aware of the possibility. Did anyone else miss this possibility?
Does a null primary key break any application servers out there?
Maybe we can add this to the RMI test :)
I wonder how often in practice a business application allows a null
value for a primary key. I can't think of an example where it would
be a good idea. Can anyone else? Personally, I wouldn't mind if
the next version of the spec made null primary key objects illegal,
but maybe I'm missing something.
But assuming that null primary keys are necessary and legal, what
are the costs and benefits of this proposal to use primitive types?
Most implementations of a server would probably wrap that
primitive type right away, so the main advantage would be just that
syntactic check on the return. The cost? Probably a few extra
lines of code in a server implementation. I guess I could take it or
leave it.
But I really am curious about whether anyone else missed the null
primary key possibility, or if I just have a blind spot.
Thanks,
Dan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
