Inheriting the abstract class HttpURLConnection

Hello,
I am trying to establish a communications link between my application (a simple web browser) and a URL. Therefor I have created HttpURLConnector, a class which extends HttpURLConnection which in turn extends URLConnection. Since HttpURLConnection and URLConnection are abstract, I have to override three methods in my class. Those are connect(), disconnect() and usingProxy().
My problem is that I do not know what code should be written inside the methods connect() and disconnect() (lets leave usingProxy() aside). Could you help me please? I post a sample of the code.
Thank you
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.text.*;
import java.io.*;
import java.net.*;
public class Browser extends JFrame {
     JEditorPane jep;
     Browser() {
          jep = new JEditorPane();
          jep.setEditable( false );
          jep.setContentType( "text/html" );
          getContentPane().add( new JScrollPane( jep ) );
          JButton button = new JButton("Click Me");
          button.addActionListener( new ActionListener() {
               public void actionPerformed(ActionEvent e) {
                    System.out.println("Clicked");
          getContentPane().add(button, BorderLayout.NORTH);
          JButton button2 = new JButton("GO");
          button2.addActionListener(new ActionListener() {
               public void actionPerformed(ActionEvent e) {
                    URL url = null;
                    try {
                         url = new URL("http://forums.java.sun.com");
//                         url = new URL("http://www.yahoo.com");
                    catch(MalformedURLException exc) {
                         System.out.println(exc);
                    HttpURLConnector http_urlc = new HttpURLConnector(url);
//                    http_urlc.connect();
                    setPageThread spt = new setPageThread(jep, http_urlc.getURL());
                    new Thread(spt).start();
          getContentPane().add(button2, BorderLayout.SOUTH);
     public static void main(String[] args) {
        JFrame f = new Browser();
        f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        f.setSize(512, 342);
        f.show();
class HttpURLConnector extends HttpURLConnection {
     HttpURLConnector(URL url) {
          super(url);
     public void connect() {
     public void disconnect() {
     public boolean usingProxy() {
          return false;
class setPageThread implements Runnable {
    private JEditorPane pageEditorPane;
    private URL url;
    setPageThread(JEditorPane pageEditorPane, URL url) {
        this.pageEditorPane = pageEditorPane;
        this.url = url;
    public void run() {
        try {
            pageEditorPane.setPage(url);
        catch(IOException exc) {
            System.out.println(exc);
}

Similar Messages

Abstract Class HttpURLConnection

How do we instantiate the HttpURLConnection abstract class.
Any help would be great
Thanks

hi,
You would first require to create a URL object and then from that you would create an object of the HttpURLConnection.. for eg..
try
      URL url = new URL("http://.....");
HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
         httpConnection.setDoInput(true); //default is true
         //default for output is false, so if you want to send info you would have to explicitly set this flag..
         httpConnection.setDoOutput(true);
         httpConnection.setUseCaches(false);
         //// other code to come here ////
catch(Exception ex)
    System.out.println("Exception :" + ex);
}hope that helpz
cheerz
ynkrish

Can defualt inherited the Super Class constructor to sub class ?

Hi,
is it passible to inherit the super class constructor by defualt when extends the super class.
Thanks
MerlinRoshina

Constructor rules:
1) Every class has at least one ctor.
1.1) If you do not define an explicit constructor for your class, the compiler provides a implicit constructor that takes no args and simply calls super().
1.2) If you do define one or more explicit constructors, regardless of whether they take args, then the compiler no longer provides the implicit no-arg ctor. In this case, you must explicitly define a public MyClass() {...} if you want one.
1.3) Constructors are not inherited.
2) The first statement in the body of any ctor is either a call to a superclass ctor super(...) or a call to another ctor of this class this(...) 2.1) If you do not explicitly put a call to super(...) or this(...) as the first statement in a ctor that you define, then the compiler implicitly inserts a call to super's no-arg ctor super() as the first call. The implicitly called ctor is always super's no-arg ctor, regardless of whether the currently running ctor takes args.
2.2) There is always exactly one call to either super(...) or this(...) in each constructor, and it is always the first call. You can't put in more than one, and if you put one in, the compiler's implicitly provided one is removed.

How to implement the abstract classes MessageDigest and Signature?

Hi all,
I've recently started working on JCDK 2.2.1.
I have a problem to share and get suggestions from you!
My aim is to implement ECDSA on Java card
I have seen the Javacard API and tried to program using the classes
MessageDigest and Signature. They are abstract classes and except the
Method getInstance in them, the rest of all methods are declared abstract.
Does that mean we have to give definition for them or else can we use
them as they are?
I tried giving some definitions, but to my surprise there's no such
initiation of any variable to the algorithm we provide in the method
"getInstance"! Then, it's not possible to give defn,. for other
methods like getAlgorithm, reset, etc. How can we resolve this ?
Any ideas?
Regards,
Johnbuchk

try this...
http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode/java/p_java_0501.jsp
hope it can help u

Difference between inheritance and abstract class

difference between inheritance and abstract class

See this thread:
http://forum.java.sun.com/thread.jspa?forumID=24&threadID=663657
And before Post New Topic, just search in this forums. All most will get answers.

Abstract class Vs interface

Hi,
I have to buid a report in ECM with complete details of the engineering as well as production. This include workflow as well as various fucntionality depends upon the criterion and user's event.
I am implementating in OOPS and I Want to know that when I should use the Abstract class and when interface ?
Because as per me both serve the same purpose. Kindly send me the exact difference so that i can efficiently use the same.
Thanks
Prince

When inheriting A Interface We have to inherit all the methods of the Interface there's no other option whereas with abstract classes we can inherit the members that we are in need of.
Just the interface has to have body of the method and the method is to be used by the classes inheriting it. Whereas in the case of Abstract Class it can have declarations (Other than the abstract method) and it can be further extended in the classes inheriting the Abstract Class.
Interface contains all abstract methods,all methods compulsory implemented by particular class, interface does not contain Constructor
abstract classes are designed with implemantion gaps for sub-class to fill in.
interfaces are sintacticlly similar to classes but they lack insance variables & methods.
abstract classes can also have both abstract methods & non-abstract methods. where as in interface methods are abstract only, & variables are implicitly static&final
regards
Preetesh

Difference between abstract class and the normal class

Hi...........
can anyone tell me use of abstract class instead of normal class
The main doubt for me is...
1.why we are defining the abstract method in a abstract class and then implementing that in to the normal class.instead of that we can straight way create and implement the method in normal class right...../

Class vs. interface
Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.
For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.
With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.
This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.
Interface vs. abstract class
Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

Abstract classes and inheritance

I'm trying to do some simple inheritance but I'm a little stuck. Without giving too much away here's what I have (or am trying to have). I have an abstract "Test" class and a number of concrete classes that extend that abstract class. In my main method I have an array of Test objects. Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. At runtime shouldn't java figure out, OK this is TestA, so go to TestA's runTest method (polymorphism?). What should I put in my runTest method in the abstract class? I know I can put anything there but what is standard?

JFactor2004 wrote:
... Each object in the array is a certain kind of "Test" and each one has its own way of doing most things but it doesn't make sense to have just a plain Test object because it is an abstraction. In my code I go through the array and execute a method, runTest(), for each Test in the array. However, my abstract Test class doesn't have a runTest() method b/c it will never get used and java complains. If you want to instantiate the Test class
you need to provide an implementation for the runTest() method,
something like/*type*/ runTest() { throw new UnsupportedOperationException(); }

Concrete classes implement abstract class and implements the interface

I have one query..
In java collection framework, concrete classes extend the abstract classes and implement the interface. What is the reason behind extending the class and implementing the interface when the abstract class actually claims to implement that interface?
For example :
Class Vector extends AbstractList and implements List ,....
But the abstract class AbstractList implements List.. So the class Vector need not explicitly implement interface List.
So, what is the reason behind this explicit definition...?
If anybody knows please let me know..
Thanx
Rajendra.

Why do you post this question again? You already asked this once in another thread and it has been extensively debated in that thread: http://forum.java.sun.com/thread.jsp?forum=31&thread=347682

What is the benefit of abstract classes?

I am little bit confuse regarding the benefits of the abstract classes. Can anybody helps me in this regard. I just want to know when and what situation we may decide that particular class needs an abstract method.
Thanx

I am little bit confuse regarding the benefits of the
abstract classes. Can anybody helps me in this
regard. I just want to know when and what situation
we may decide that particular class needs an abstract
method.Sorry if I sound weary of this question, but it is asked about 3-4 times a week. Rather than have us go through this tired exercise again, please search the forum for previous threads on this subject. You'll find about a gazillion. In fact, it's often a good idea to search the forum before asking a question as very often it has been asked and answered before.

What's the difference between Abstract Class and Interface?

Dear all,
Can anyone give me some hints about this topic?
Thanks.
Leo

an abstract class may have some methods already implemented in the abstract class but an interface has no methods implemented
I think it's just that simple.
For your design needs, you just choose what you need : )
Cheers
Stephen

Modify Standard Abstract Classes.

I would like to know what is the approach to extend a
Standard Delivered Abstract Class.
I tried the following approach, but it doesnt seem to work.
I want to add some methods to the standard Abstract Class
CL_CRM_AUI_ENTITY. So i created a copy(not inheritance )
-> ZCL_CRM_AUI_ENTITY and added a new abstract method to this class.
The Class CL_CRM_AUI_ONEORDER implements the methods of the abstract class. I implemented the new method here.
Now in my Application :
The following code works - Reference to the standard delivered abstract class cl_crm_aui_entity.
data : lv_bol_entity type ref to cl_crm_bol_entity lv_aui_entity type ref to cl_crm_aui_entity.
IF lv_bol_entity is bound.
lv_aui_entity ?= lv_bol_entity.
ENDIF.
The following code does not work and gives me a CX_SY_MOVE_CAST_ERROR.
data : lv_bol_entity type ref to cl_crm_bol_entity,
lv_aui_entity type ref to zcl_crm_aui_entity.
IF lv_bol_entity is bound.
lv_aui_entity ?= lv_bol_entity.
CATCH...
ENDCATCH.
ENDIF.
Is the solution then to modify the standard delivered abstract class or can we work around this?
Thanks.

Decorators work well if a Class define an interface. Using decorators gives the power to add multiple features which can freely combined without creating all combinations of classes.
If e.g. you want to enable tracing of each method you implement a trace decorator and put in the original implementation. Another decorator may due additonal security checks. If you now want to combine both you just can put the original instance in the first decorator and then in the second. With single inheritance you may need much more classes.
But similar to inheritance, the instances of the base class wont be able to call instances of the encapsulation. The decorator can replace or enrich the base class only.
I wonder why you want to make the original class to use your changes. Is it not sufficient that all programs using your enriched instances work with your additions.
Kind Regards
Klaus

Abstract class methods

I'm confused. Is this true or false.
The great thing about polymorphism is that you can call one method. If the subclass inherited that method, it will be customized and perform a different duty. That way, the action it performs will depend on 1>whether or not it's a sub or super class and also 2>if the method was overridden if it was a subclass.
Now, my confusion. If an object reference is to a Super-abstract-class... how do the method calls and properties go?? well let me let you answer for me. Thanks so much in advance for this clarification.

Yes. You are - pretty much.
The abstract class, as such, can never be instantiated. BUT a class derived from the superclass IS an instance of the superclass.
Silly example:
abstract public class Animal {
 public Animal() {
 public abstract int getNumberOfLegs();
}That's our animal class, and we know that anything that's an animal has a number of legs - but we can't just create a "generic" animal.
public class Cat extends Animal {
 public Cat() {
 super();
 public int getNumberOfLegs() {
 return legCount;
 public void maim(int legsToRemove) {
 legCount -= legsToRemove;
 if(legCount < 0 ) legCount = 0;
 private int legCount = 4;
}A Cat is a specific type of animal, so we can find out how many legs it has (usually 4). Note again that a cat IS an animal, so Cat IS an instance of Animal.
Java even provides a special operator to test this:
Cat cat = new Cat();
System.out.println("A cat is a cat: " + (cat instanceof Cat));
System.out.println("A cat is an animal: " + (cat instanceof Animal));The term used to describe the "Guarantee" that a subclass of an abstract class (or an implementation of an interface) is usually and technically a "contract", but I prefer to think of it as a "Promise" since you can break the promise by messing with the bytecode - at which point the JVM will spot the lie and complain !
D.

Replacement for multiple inheritance in MovieClip class

Hello
I need your opinion about a problem.
Commonly, when you need to replace multiple inheritance, you do it by making an aggregation with one of the class involved.
But in case of MovieClip attached class, there is one more class involved in the process : the MovieClip class, and this class can't be the one aggregated because every class attached to a MovieClip need to inherits from it.
The problem is if the other class can't be also aggregated because it has some abstract class behaviour, for instance, call of a virtual function.
A solution could be making the abstract class inherit from the MovieClip class, but what if you want to reuse its behaviour in a class which have nothing to do with MovieClip ?

This is Not Supported in WebLogic that the Remote Interface extends other Interfaces. Because Annotation Processor just looks up inside the implemented interface methods. The actual interface which is Implemented by the Bean Class. So the Methods declared inside the Interface B and Interface C will be ignored and will not be available as part of the generated Stubs. Thats why u are getting NoSuchMethodError.
You can even contact Oracle Support on this...there are 3-4 Cases on it. And the Solution is Work As Designed.
Workaround is : edit your interface A as following
Declare all the Business Methods only in the Remote Interface and not inside it's Super Interfaces.
Example:
@Stateless(name="A")
@Remote({A.class})
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class AImpl implements A {
@Override
public void writeA() {
System.out.println("A");
@Override
public void writeB() {
System.out.println("B");
@Override
public void writeC() {
System.out.println("C");
@Remote
@JNDIName(A.JNDI_NAME)
public interface A extends B, C {
public static String JNDI_NAME = "A_JNDI_NAME";
void writeA();
void writeB();
void writeC();
Thanks
Jay SenSharma
http://jaysensharma.wordpress.com (WebLogic Wonders Are Here)

Abstract Classes versus Interfaces

Somebody at work has just made an interesting observation and its bugging me, comments please.
When I started Java I just used classes (and abstract classes), and didnt bother with Interfaces I understood them to be a way of getting round the lack of MultipleInheritance and it wasnt a problem that concerned me.
But as time went on I found that sometimes I did want classes that had little in common to provide some additional feature (such as logging), and interfaces were great for this.
..so I was happy ..
During all this time if I want a HashSet I would write code like this
HashSet dataSet = new HashSet();but then I read that HashSet was an implementation detail and we should be using Interfaces as follows:
Set dataSet = new HashSet();So whereas before I might have had a class hierachy with an Abstract class at the top , I started slotting in Interfaces above that and viewing the Abstract class as just a convenience to implementing the Interface.
So which is the right method , originally I saw subclassing object as an 'is a ' relationship and implementing an interface as a 'implements' relationship. But more recently it seems to be turned on its head and implementing an interface is an 'is a' relationship (but supports multiple inheritance)
Also it seems to be the trouble with this second approach is that anyone can implement an interface, for example I could implement Set,Map and List with one class, the class hierachy is not so helpful .

Thanks, but the question was alot wider than that,
the HashSet example was just one part of it.I think it is representative of all the situations that you talk about, which are whether an instantiator should handle the instantiated object by its interface or by its implementation.
I suppose the question is
"How do you code model "is a " relationship in java
through extending a class or creating an interface
and implementing it"
MySubClass extends MySuperClass implements MyInterface {}MySubClass is a MySuperClass and a MyInterface. The way that I view it, the "is a" relationship applies to all type inheritance, even for the multiple type inheritance that you can have with interfaces. The "is a" relationship doesn't doesn't have to be a 1:1 mapping. There's no point in thinking about it differently since that's how the language behaves.
an alternative question is
"is it correct to mix/match both methods I described
above"I thought I gave an answer. You said that my answer is not "broad enough." How so? My answer was that handling an object that you instantiate by its interface can reduce the amount of changes you have to make if you change the implementation. You will have to make one change (the line of code that instantiates the object) instead of many. Also, handling it by its interface makes it easier to switch from object A instantiating object B to object A being passed a reference to B and to object A getting its dependencies injected by XML configuration.
It seems weird to handle an object by its interface if you already know it's implementation, but it's commonly seen and this is why I think it must be used. As I said, it's a small benefit of abstraction.
The times when you may not want to do this is when the instantiator has to call methods from different interfaces of the object. You can handle it by its interface by casting between the different interfaces you have to work with, or you can just handle it by its implementation, gaining access to all of the object's interfaces.
Note that everything I explained concerns the type by which the instantiator handles an instantiated object. If a class does not instantiate a certain object, then it almost always should receive it by its interface, unless it's some really common implementation that's never going to change.
I use interface, abstract class, and base class interchangeably. It's up to you to decide which to use for type inheritance. It's good practice to favor interfaces.

Inheriting the abstract class HttpURLConnection

Similar Messages

Maybe you are looking for