Hi, As a matter of curiosity, I just want to know if we can redefine the built-in Java classes. Say for example the Applet class, Button class ,etc. If yes then why? And I am not talking about final classes like String.
If you want to make it so "new javax.Swing.JButton()" created an instance of your custom class instead of the standard library ... well we could try it in controlled environments but it's so non-standard as to probably be a pretty bad idea.
If you want to say "new MyButton()" or better yet "factory.getButton()" and get a customized version of JButton, then you're in business. That's what object oriented polymorphism is all about. If that's new to you, try How My Dog Learned Polymorphism for a good start. [ July 08, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Hi, The things you people are saying are not the same which i mean. I know its a bad idea but still its an idea to redefine the java.lang.Thread class and that too in the same package (?)!!! or say java.lang.Object again in the same package..
I have tried this and it works !! So i just want to know the reason behind it because it violates many of the language rules including the one which states that you cannot have two classes in the same package with the same name.
So please provide some definite lead on this I will be thankful if Marc or Ulf post a reply on this topic.
Thanks in advance
Joined: Jun 22, 2007
Originally posted by Amit Ghorpade: Hi, I have tried this and it works !! So i just want to know the reason behind it because it violates many of the language rules including the one which states that you cannot have two classes in the same package with the same name.
Sorry...I cannot understand one thing.. In Java you can only have ONE SINGLE public class per file and its name must perfectly match the name of the physical file (both of .java and .class). Now...to do what you are pretending to do...you should have put a second Object.class (or .java) file in the same directory where original ones are.. But I don't think Windows (or any other OS) would allow you to have 2 files in the same directory with perfectly identical name. And you necessarily had to put that file in the same directory...because packages structure must mandatory match directories structure.
Maybe you already had a .java file and you had a .class one? Or the opposite, it's conceptually the same. In this case everything is legal..because the JVM will only consider the .class version letting aside the .java which is need only for developers to better understand how an API class works.
You can cause your own classes to be found, in preference to ones built into the JRE/JDK by defining the "boot class path" and ensuring your classes are in that class path. The Sun JVM has argument -Xbootclasspath, if I remember correctly.
I have used that for replacing the Sun built-in CORBA ORB with a different home-made one. That's a reasonably valid thing to do. Note that those classes do not have package java.something, they are org.something.
I guess there must be some restrictions to what you can replace, but I have not investigated in detail. It's clearly ludicrous to imagine replacing things like java.lang.Object or java.lang.Thread.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Hi again, well i was not playing fun around and i said what i meant. I admit that i tried to meddle with the language semantics and the above posts were something even i was wondering about. I know its weird of me but i tried it just for the sake of curiosity. I am not kidding at all. Please find more information on this in the following Java bug database link. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578568
Vote for this bug if you feel its worth your vote.. Hope I am not misunderstood by you. Thank you. [ July 12, 2007: Message edited by: Amit Ghorpade ]
subject: Can we redefine any of the Java built-in classes