<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/11/15 11:41 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap="">On 6/11/15, 11:20 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<pre wrap="">
I would have to go back into the code and dig out why this didn't work, but I know that it didn't. There were places where actions were typed to be receiving a SAMLObject that didn't in fact always receive a SAMLObject and that broke. Some of them were probably in the non-SAML parts of the system.</pre>
</blockquote>
<br>
<br>
If so, then they probably shouldn't have had a specific generic
type. It would be ok for an Action, etc, to have generic
parameters, meaning not actually specify the type, if they do not
care about or operate on the inbound/outbound message types. The
don't have to declare specific types. The calling/instantiating
code would do that. I wonder if that was the fundamental issue
here...<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap="">
It's possible it was less about SAMLObject and more about a specific type of object, AuthnRequest or Response perhaps, and the actions were no longer exclusive to that message type. I really don't remember, I just remember that it all failed to hang together and I know I sent some notes about it at the time. Things either started not compiling, or were opening up the chance of cast exceptions.</pre>
</blockquote>
<br>
As I mentioned, the way generics work, if you do not have
non-generic aware code treating the components non-generically, then
you literally can not have a ClassCastException.<br>
<br>
E.g. If something declares a Set<String> and passes that into
something else which is *not* generically-aware and it treats it as
just a Set and stores arbitrary Objects in it, then you have a
problem. The solution is to not have the non-generically-aware
component in the first place.<br>
<br>
This was an issue in the early days of generics where you had lots
of non-generic code, esp for collection types and such. But
shouldn't be an issue for our own code, since we control it...<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap="">
If you recall, we determined through testing that if the runtime behavior violates the assumption of the generic class, you just get a class cast exception. Just claiming that a type is Foo when the type isn't always Foo is just an implicit cast to Foo at the top of the method. And that was what the actions were doing essentially, in places where it wasn't always going to be a Foo.</pre>
</blockquote>
<br>
Right, v2 did that and it was wrong. The solution is to not have
generic types being treated by other things non-generically.
Everything has to be genericed. If it is, cast exceptions literally
can not happen. It's guaranteed by the compiler. Or so my generics
book tells me.<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap="">
Perhaps my error was in not just picking a different generic type parameter instead of removing the generic, but I don't think in actual fact that it's possibly an error to ever inherit out the generic, because all that does is eliminate a type that's going to get erased at runtime anyway. I'm basically making the inheriting code non-generic which just means the types aren't implicit to the compiler.</pre>
</blockquote>
<br>
I don't quite grok that, but perhaps it's what I said above.
There's a difference between: 1) having generic parameters on a
class 2) actually nailing down the generics right in the class
definition. You don't always want or need to do the latter. Not
nailing down allows the class to be used in the widest possible way.<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap="">
If you're worried that we're injecting something that is type-locked into something I removed the generic from,</pre>
</blockquote>
<br>
<br>
I *think* I'm actually concerned more about the opposite case, but
not sure.<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
<pre wrap=""> the only way that could fail at runtime is with an implicit cast that would have happened anyway because if the object it's handed is the wrong type, that was going to fail at runtime one place or the other. All we're possibly doing is moving around a cast exception from one class to another. I don't think it can introduce a failure mode that wasn't already going to fail.</pre>
</blockquote>
<br>
<br>
Head spinning, can't go on, need more oxygen... <br>
<br>
<br>
<blockquote cite="mid:09B524C0-80B7-486D-AF05-1EA87E6EAED5@osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>