This discussion is archived
1 2 Previous Next 29 Replies Latest reply: Dec 14, 2009 7:16 AM by 843798 RSS

Dynamic Reflection Casting to Super-Class

843798 Newbie
Currently Being Moderated
Hi,

NOTE
I answered this question in the process of asking it, but I don't feel as if I found the answer in my searching so I posted it anyway. The example code works (if you replace classes a and b with real classes inside of unique packages)

Please forgive me if this is a re-post, but I've done quite a bit of reading of the many relevant results of searches here and on Google, but I don't feel like I've found the answer to my question (Or I just didn't understand the answers).

What I am trying to do Is take an instance of a known class and dynamically cast it to its super-class by string. This would allow me to start with any class and reuse the code.

Example:
class a {
  public String Name;
}

class b extends a {
  public Sting Name;
}

class Program {
  public static int main() {
    b oB = new b();
    oB.Name = "b";
    object oA = (Class.forName("a")).cast(oB);
    Field fProperty = Class.forName("a").getField("Description"); //NOTE the full class name goes here i.e. java.lang.String
    fProperty.set(oA, fProperty.getType().cast("a"));
  }
After that code is executed I would like for oB.Name to return "b" and oA.Name to return "a" (oA would have to be casted to access the name directly, but you can use reflection to get it from oA as an object).

I needed this functionally to allow me to create "oB" by reflection also, and move all of my object specific logic into XML attributes.

Hope this helps someone else having problems with dynamic reflection!

-Nomad311
  • 1. Re: Dynamic Reflection Casting to Super-Class
    EJP Guru
    Currently Being Moderated
    Mostly unnecessary fluff.
    class Program {
      public static int main() {
        b oB = new b();
        oB.Name = "b";
        Field fProperty = oB.getClass().getSuperclass().getField("Description");
        fProperty.set(oB, "a");
      }
    No class names as strings needed at all, and none of the dynamic casts were necessary either.
  • 2. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    I suppose, but I had a more complicated scenario in mind when writing that code. I try to simplify my code as much as possible when posting to forums; that way the idea isn't lost in the implementation. The structure I am programming for has n levels of inheritance; in other words oB could be an instance of the following class:
    class c extends b {
      public String Name;
    }
    Thanks for the response though, a person looking for a more simple approach may find your code applicable. Also, I'm not too familiar with Java casting/boxing internals, but I would imagine that your code would error more often with out explicitly attempting to cast that field's value (in that "set()" method).
  • 3. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    I can't edit that orginal post but that "getField" method should read:
    class Program {
      public static int main() {
        b oB = new b();
        oB.Name = "b";
        Field fProperty = oB.getClass().getSuperclass().getField("Name");
        fProperty.set(oB, "a");
      }
    }
    Edited by: nomad311 on Dec 14, 2009 8:29 PM
    ...I'd love for someone to honestly say that cleared things up
  • 4. Re: Dynamic Reflection Casting to Super-Class
    EJP Guru
    Currently Being Moderated
    The structure I am programming for has n levels of inheritance
    So call .getSuperclass() n times. No need for classname strings whatsoever.
    a person looking for a more simple approach
    Is there some reason why that doesn't include you?
    I would imagine that your code would error more often with out explicitly attempting to cast that field's value (in that "set()" method).
    I* cannot imagine why you would imagine any such thing. It's that kind of thinking that has led to all that fluff, even in this cutdown example. It should have been self-evident to you that it will get class cast exceptions exactly as often as yours, no more, no less, with less code. The object is either of the correct class or it isn't. If it is, OK; if it isn't it will fail, end of story. Your extra code doesn't change that: ergo it is redundant.
  • 5. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    Your a very blunt person, so I'm sure you would appreciate the same...
    ejp wrote:
    The structure I am programming for has n levels of inheritance
    So call .getSuperclass() n times. No need for classname strings whatsoever.
    This is borderline stupid, naive at best, you would need to know how many levels you want to go up in the inheritance tree then implement a solution, hopefully with a block of comments, explaining why you chained three getSuperclass() calls togther. The 'dynamic' version of this approach would be to 'search' by iterating up the tree and checking rather that type has the desired field (what should be done if they all have it?).
    I would imagine that your code would error more often with out explicitly attempting to cast that field's value (in that "set()" method).
    I* cannot imagine why you would imagine any such thing. It's that kind of thinking that has led to all that fluff, even in this cutdown example. It should have been self-evident to you that it will get class cast exceptions exactly as often as yours, no more, no less, with less code. The object is either of the correct class or it isn't. If it is, OK; if it isn't it will fail, end of story. Writing extra code can't possibly change that.
    Although I've forgotten the syntax of this, I'm sure that it is possible to handle custom boxing for a class. Which, according to you is pointless to implement (sarcasm intended, BTW it continues). Do you know how to cast an integer, say 100, to a string without these pointless casting methods? How about from it's hex, 0x64?

    The only way explicitly calling that cast() method is pointless, is if it is called internally, which I have the sneaky suspicion that you didn't research that.
    >
    You're just creating code, and difficulties, where none exists.
    Although a straight forward and simplistic answer applies to the majority of problems, it typically applies only to a narrow domain of problems. Meaning simple and clean code, typically, is not dynamic (see title if your confused about why that adjective applies here). If all the worlds technology related problems could be solved so easily then I wouldn't have a job and robots would handle development of the next release of Windows, Android, Citrix or any other trivial software solution out there.

    For the record, I've only wasted my time in typing this response in the hope that this will be you last post in the ignorance that there is only one 'good' answer to a problem.
  • 6. Re: Dynamic Reflection Casting to Super-Class
    EJP Guru
    Currently Being Moderated
    This is borderline stupid,naive at best, you would need to know how many levels you want to go up in the inheritance tree then implement a solution, hopefully with a block of comments, explaining why you chained three getSuperclass() calls togther.
    It's only 'borderline stupid' or 'naive' if it gets one of your radical over-implementations. Just keep calling getSuperclass() until you hit java.lang.Object.
    The 'dynamic' version of this approach would be to 'search' by iterating up the tree (what should be done if they all have it?)
    No idea, but that's not a question that's addressed by your code either.
    Although I've forgotten the syntax of this, I'm sure that it is possible to handle custom boxing for a class.
    What's 'custom boxing for a class'?
    Do you know how to cast an integer, say 100, to a string without these pointless casting methods?
    There is no such thing as 'cast[ing] an integer, say 100, to a string', and 'these pointless casting methods' certainly don't do it: nor do they do type conversion either, if that's what you intended.
    How about from it's hex, 0x64?
    How about it? Calling Class.cast() doesn't do that. So it is still pointless.
    The only way explicitly calling that cast() method is pointless, is if it is called internally
    +If it isn't pointless, why does it still work when you take it out?+ Because that is precisely what happens. Please explain.
    which I have the sneaky suspicion that you didn't research that.
    Before you accuse other people of not checking their facts, it is highly advisable to check them yourself,* in order to avoid complete embarrassment, as here, and any necessity to make a grovelling apology, as here. To me. Here. Obviously it is you who hasn't researched it, tested it, or even thought about it analytically. Next time you are tempted to make a stupid, snide, gratuitous, and baseless remark like that, especially about people who are trying to help you, I suggest you think again.
    Although a straight forward and simplistic answer applies to the majority of problems
    Irrelevant. That's just a straw-man argument. It's beyond dispute that you introduced objects and method calls that add precisely nothing (except risk - see below): a redundant oA object, redundant strings to identify superclasses, and a redundant call to Class.cast(). When you remove them, the result is certainly simpler, which is always desirable, but there is no semantic difference.It certainly doesn't make it 'simplistic'.
    [more irrelevant waffle snipped]
    For the record, I've only wasted my time in typing this response
    I agree. You could have had the courtesy or the common sense to try it my way and see whether I'm right. Risky business otherwise, as we shall see.
    in the hope that this will be you last post in the ignorance that there is only one 'good' answer to a problem.
    Nobody said any such thing, so that's another straw-man, but let's subject the question of who is ignorant and who is relying on sneaky suspicions and unfounded guesswork to a scientific test:
    public class AutoBoxTest
    {
         int     count;
         
         /** Creates a new instance of AutoBoxTest */
         public static void     main(String[] args) throws Exception
         {
              AutoBoxTest     object = new AutoBoxTest();
              Field     f = object.getClass().getDeclaredField("count");
              try
              {
                   f.set(object, f.getType().cast(1));
              }
              catch (ClassCastException exc)
              {
                   exc.printStackTrace();
              }
              try
              {
                   f.set(object, f.getType().cast(Integer.valueOf(1)));
              }
              catch (ClassCastException exc)
              {
                   exc.printStackTrace();
              }
              try
              {
                   f.set(object, 1);
              }
              catch (ClassCastException exc)
              {
                   exc.printStackTrace();
              }
              try
              {
                   f.set(object, Integer.valueOf(1));
              }
              catch (ClassCastException exc)
              {
                   exc.printStackTrace();
              }
         }
         
    }
    Please explain why the only lines in the above that throw a ClassCastException are the ones containing your Class.cast() call?
  • 7. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    We could bicker all day so I will address the majority of your responses by saying: you're focusing on the wrong thing, namely, the few lines of throw away code that I used to illustrate a more complex programming problem (oh yeah and terminology scoff ...casting vs conversion; the functional result is the same, using two technically different objects together - how was that deflection helpful to anyone?).
    The 'dynamic' version of this approach would be to 'search' by iterating up the tree (what should be done if they all have it?)
    No idea, but that's not a question that's addressed by your code either.
    Actually my solution addresses the question by avoiding it (you've lied here in an attempt to discredit a solution that you, apparently, don't understand); in my solution you specify the class explicitly.
    You seem to be keener on making gratuitous snide remarks about people who are trying to help you than you are in the actual answer, or the truth of the contentions you are making here.
    You sir began the mudslinging by attempting to invalidate a working solution to a real world problem in favor of a solution that fails to address the problem that has been spelled out quite well.

    But, I have said it once and I'll say it again, thank you for your help. What confounds me is that you refuse to acknowledge that my solution does solve the problem in question, and quite completely.

    When I made a remark about dropping the explicit cast, I made it clear that this was a guess, my intention was to warn future adapters of a possible danger.

    And, in your attempt to prove my concerns about dropping that call wrong, all you've done is shown that that cast does have an affect on the outcome of the algorithm; all I wanted to note is that it could happen. Again, thank you; you've been, unintentionally quite helpful!

    No I haven't tested this code in the wild, I performed a single test in the domain, to which my solution belongs. It works there.
    Please explain why the only lines in the above that throw a ClassCastException are the ones containing your non-pointless Class.cast() call?
    My theory on your exception:
    You're attempting to cast an Object to an int privative (something that is done via conversion, not casting ...I believe you covered that difference) rather than the Integer object, which I would think would work.

    Back to my problem, which is the purpose of the thread and the problem that is supposed to be addressed by a proposed solution. What I have typed above WILL NOT appear verbatim in production code. That said, in the way I intend to use this algorithm I plan on using an object created via reflection form a class name. At the time that I call that cast I will be passing it a reference to an Object, this approach has been tested and does work (this was not demonstrated above because it would have unnecessarily complicated the sample code).

    All sarcasm and machismo aside,
    You are a moderator here, which is why I have given you're comments so much weight, and taken the time to address your responses. I, and assume that other do also, tend to hold the opinions of moderator in higher regard, if for no other reason, because I know that they spend a significant amount of their time on a given forum. Do you stop to think about how stating, maybe even insisting, that a call to a method made available to the developer has no significance could affect the reader? Someone new to programming or even a vet exploring new territory can be easily lead down the wrong path, because of your ego (I can see no other reason for refusing to back down on an issue that you don't know a definitive answer to especially when I never said you're approach is wrong)?
  • 8. Re: Dynamic Reflection Casting to Super-Class
    EJP Guru
    Currently Being Moderated
    you're focusing on the wrong thing, namely, the few lines of throw away code that I used to illustrate a more complex programming problem (oh yeah and terminology scoff ...casting vs conversion; the functional result is the same, using two technically different objects together - how was that deflection helpful to anyone?).
    (a) I focussed on the code you posted. Not on the code you didn't post. Can't see that; can't comment. (b) Correct use of terminology is nothing to scoff at: it is essential in a technical discussion. I agree that introducing conversion was a deflection and I still don't know why you did it.
    Actually my solution addresses the question by avoiding it (you've lied here in an attempt to discredit a solution that you, apparently, don't understand); in my solution you specify the class explicitly.
    (i) Abuse reported. (ii) I understand it all right, I just think it has redundant and over-implemented features.
    You sir began the mudslinging
    False. Read the thread.
    What confounds me is that you refuse to acknowledge that my solution does solve the problem in question, and quite completely.
    It doesn't. I have proved it. You haven't refuted the proof, or provided a counter-proof.
    When I made a remark about dropping the explicit cast, I made it clear that this was a guess, my intention was to warn future adapters of a possible danger.
    And you were half right. There is a possible danger. With the explicit cast. Not without it. Back to front from your initial fears. Nice to have them allayed, isn't it?
    And, in your attempt to prove my concerns about dropping that call wrong, all you've done is shown that that cast does have an affect on the outcome of the algorithm
    'All I have done'? What else could possibly be required? And do you really consider throwing an exception merely an '[e]ffect on the outcome of the algorithm'?
    all I wanted to note is that it could happen. Again, thank you; you've been, unintentionally quite helpful!
    You still have it back to front. The code I posted proves your code wrong. Not the other way round. So of course I was helpful, and the allegation that it was unintentional is merely pointlessly offensive.
    No I haven't tested this code in the wild, I performed a single test in the domain, to which my solution belongs. It works there.
    So does removing the cast. Try it.
    My theory on your exception:
    You're attempting to cast an Object to an int primitive
    Correct, but it's not me that's 'attempting to cast'. It is your code that's doing that, not mine: and mine works. Not yours. Do consider that.
    rather than the Integer object, which I would think would work.
    No thinking necessary. The code I posted proves it to work.
    I have given you're comments so much weight
    I'm sorry to say that can see no evidence of that whatsoever.
    Do you stop to think about how stating, maybe even insisting, that a call to a method made available to the developer has no significance could affect the reader?
    Of course. That's why I said it. That's also why I proved it. That's why I'm engaged in this discussion.
    Someone new to programming or even a vet exploring new territory can be easily lead down the wrong path, because of your ego (I can see no other reason for refusing to back down on an issue that you don't know a definitive answer to especially when I never said you're approach is wrong)?
    I also am concerned to preserve the integrity and high standard of these forums by not leaving errors lying around uncorrected to mislead future readers, but it is clear from all this drivel that you still don't get it. You still don't understand, or perhaps cannot accept, conclusive proof. I suggest you run the code I posted. Then explain why it works without the typecast. Then explain why the typecast is still a good idea that won't 'lead down the wrong path'. Do that and do stop trying to blame me for your own errors and your own failure to understand.

    Let's summarize. In this thread you have made the following claims for the Class.cast() call:

    (a) it is necessary
    (b) it can perform 'custom autoboxing', whatever that is (queried: unexplained)
    (c) it can perform conversion from int to String
    (d) it can decode hex strings
    (e) 'the only way explicitly calling that cast() method is pointless, is if it is called internally', which you hadn't (haven't) tested, and which you accused me of not having researched!
    (f) the cast does 'have an [e]ffect on the outcome of the algorithm' which turns out to be an exception, and the very one you were trying to avoid

    That's rather too many unacknowledged errors on your part to accuse others of 'refusing to back down'.
  • 9. Re: Dynamic Reflection Casting to Super-Class
    791266 Explorer
    Currently Being Moderated
    nomad311 wrote:
    We could bicker all day so I will address the majority of your responses by saying: you're focusing on the wrong thing, namely, the few lines of throw away code that I used to illustrate a more complex programming problem (oh yeah and terminology scoff ...casting vs conversion; the functional result is the same, using two technically different objects together - how was that deflection helpful to anyone?).
    The 'dynamic' version of this approach would be to 'search' by iterating up the tree (what should be done if they all have it?)
    No idea, but that's not a question that's addressed by your code either.
    Actually my solution addresses the question by avoiding it (you've lied here in an attempt to discredit a solution that you, apparently, don't understand); in my solution you specify the class explicitly.
    I think you need to calm down, and cool off a bit. I can understand that it can be frustrating to debate in a forum, but name calling isn't helping your case.

    Kaj
  • 10. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    nomad311 wrote:
    What I am trying to do Is take an instance of a known class and dynamically cast it to its super-class by string. This would allow me to start with any class and reuse the code.
    In keeping with the blunt nature of this thread, this sounds like a load of vaguely-thought-out waffle. Running reflection on member variables isn't going to make your code any more flexible, probably exactly the opposite. Reflective code doesn't care about the types being reflected upon anyway. Field.set takes an Object as an argument, casting some other reference to something else has zero effect on that. Bandying about the word "dynamic" as if it had any meaning here doesn't make it any less so. Plus, of course, your code as posted won't even compile.

    You should also be aware that there's a world of difference between blunt talk - which is very useful in a technical context - and outright trying to be offensive.
  • 11. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    Using Class.cast serves, in my estimation, exactly two purposes:
    1) Move the ClassCastException into library code instead of user code. In your case, this isn't needed because the ClassCastException would happen in library code anyway.
    2) To obtain a reference with a type T, by using Class<T>.

    In fact, 2) is the main usage and that's why it was only added in 1.5. Before that if you wanted to check if the object could be cast to the class, you would just use Class.isInstance and throw a ClassCastException or whatever based on the result.

    You're not doing it for 1). And you're not using a typed Class instance since you're obtaining the class by name, so you're not doing it for 2). So you're not doing it for any reason.
  • 12. Re: Dynamic Reflection Casting to Super-Class
    3004 Newbie
    Currently Being Moderated
    nomad311 wrote:
    you're focusing on the wrong thing, namely, the few lines of throw away code that I used to illustrate a more complex programming problem
    It sounds like you agree that for the case shown, your "dynamic" code adds nothing, but that there are other, more complex situations that it addresses that ejp's code does not. Perhaps you can produce an SSCCE that demonstrates one of these situations. If so, it will advance the discussion to the actual point you're trying to make. If not, it's difficult for an objective observer to see anything more than, "Trust me, it's there," hand waving.
  • 13. Re: Dynamic Reflection Casting to Super-Class
    843798 Newbie
    Currently Being Moderated
    kaj,
    what name have I called anyone? I called his proposed solution to my question "borderline stupid", meaning I didn't call his approach stupid much less the poster.

    george,
    where is your justification for your comment, you made no attempt to solve the question at hand, and you apparently didn't read the whole post before chiming in. Making the code compilable would have complicated the example, how many possible outputs could this code give

    endasil,
    thank you, i clearly stated in the first post that I didn't know what that method was doing, and you're the only person to attempt to explain when it should be intentionally used. And your explanation is correct, I don't want that restriction there.

    jverd,
    How did I not comply to this ideology (I've fixed those errors that have prevented some of the readers from comprehending the problem and/or solution).
    S - 14 lines of well formatted code
    S - I make references only to the necessary libraries that are a part of the JDK
    C - When this solution (better read algorithm) is applied, it works
    E - You b.Name shadows a.Name, c is only needed to answer the question, why must the solution be dynamic ...a question in it self that warrants the question, why would to want a solution that only works in one use case?

    All of these letters abbreviate an adjective, and adjectives describe qualitative values. I felt as if my example and explanation of the problem and the solution left little room for confusion within the target audience (It would take pages to explain the problem and solution to my mom ...shes not reading this forum though right? ...Neither are students in Intro to Computer Programming).

    No one who has rejected my solution is confused about the problem or the solution (which is what that article addresses), but no one that as posted here has even attempted to presented a solution that doesn't involve this level of reflection yet solves the throughly described problem.

    No one here seems to be interested in why I went through the trouble of researching a coming up with a solution to this problem. One person asserts that there is no need for such a dynamic solution, and gives one that can only be applied to a single scenario. Not only does no one see a problem with this, they agree. To what, that I should limit this library to handle just this one/two scenario(s)? Then what, expand it as necessary? Create another library? For what benefit? Speed? Efficiency? This library will be used on an application or utility server, not inside an Android app. What's the ultimate goal of convincing me and others that a solution to an existing problem is invalid?
  • 14. Re: Dynamic Reflection Casting to Super-Class
    EJP Guru
    Currently Being Moderated
    kaj, what name have I called anyone?
    Me. See above. You have made numerous personal remarks; all false; and all entirely unacceptable in any civilized discussion. Good manners and intellectual integrity alike require that you apologize.

    What you should be doing of course is thanking me for debugging your code for you, and finding a case where it won't work. I've saved you and your employer quite a bit of money.
    No one who has rejected my solution ...
    No-one has rejected your solution. It has been criticized. Your reaction to that has been unprofessional and immature.
    no one that as posted here has even attempted to presented a solution that doesn't involve this level of reflection yet solves the throughly described problem.
    You didn't ask. There is no extra 'level of reflection' in your code beyond any other solution. It can in fact be done without reflection.
    No one here seems to be interested in why I went through the trouble of researching a coming up with a solution to this problem.
    You didn't say. Presumably it was because you had the problem, whatever it was. You didn't define the problem either. We don't read minds. It's a forum, not a seance.
    One person asserts that there is no need for such a dynamic solution
    Which person? Nobody has said anything about 'dynamic' except you, and you appear to be simply misusing the term.
    To what, that I should limit this library
    This +'library'?+ These three lines of code you mean? that can be cut down to two?
    For what benefit? Speed? Efficiency?
    Handling primitive attributes without ClassCastExceptions is a benefit. Correctness, simplicity, lower maintenance, lower cost, speed, and efficiency. These are all benefits.
    This library will be used on an application or utility server, not inside an Android app.
    It doesn't matter where it goes: good code is good code, and it saves money; rubbish is still rubbish, and it costs money. Don't perpetrate it.
    What's the ultimate goal of convincing me and others that a solution to an existing problem is invalid?
    A pointless and stupid question. If your solution was invalid we would be doing you a favour by telling you so, but in fact nobody said it was invalid. It does have a few problems, starting with the fact that it doesn't handle primitive attributes, and it certainly doesn't have any of the miraculous properties you claimed for it, in your apparently terminal confusion between typecasting and type conversion. So if you're relying on any of those you are in for an avoidable surprise.

    All that can be tested very simply: by writing the code my way and executing it. If it doesn't work, I'm wrong. If it works, I'm right.

    Clearly you haven't even tried that, so you don't even know what you're talking about when you argue with us, and abuse us, and waffle, and drivel.
1 2 Previous Next