Partial Interface Implementation.....am I right?

Hi there everyone,
I am reading Ivor Hortons book, "Beginning Java 2 SDK 1.4 Edition". I have just got to the part where he talks about interfaces. I get interfaces, no problem.....but then he goes on about implementing some methods from an interface and not others. I quote: -
"You can omit the implementation of one or more of the methods from the interface in a class that implements the interface, but in this case the class inherits some abstract methods from the interface so we would need to declare the class itself as abstract"
This is what I think he means (from what I have learned so far)....
An abstract class is a class that that declares methods without actually "filling them in"....it is assumed that this will be done by a sub-class which inherits from this super-class.
Therefore, if you don't implement all the methods in the interface in a class, that class must also be declared as abstract, as you have methods left over that you have not implemented.
Is this right?
He goes on to say that because the class is an abstract class, you can't create instances of this class....unless a sub-class of this class is created that implements the remaining methods. Which seems logical, I guess.....but why would you do this? It seems to be a lot of trouble just to neglect a few methods...they have to be implemented in a sub-class anyway to "arrive at a useful class" as he puts it.
So whats the point?
Also (as an aside)....if you have a class that must enforce method formatting.....why would you use an interface instead of having your class inherit abstract methods from a super-class? Is is because you can only inherit from one super-class (which wouldn't be much use for sub-classes that needed to enforce certain other methods)? I understand that C++ can inherit from multiple super-classes, thus negating the need for interfaces. This seems right to me.
How did I do? :) Any comments?
Thank you.
Jon

An abstract class is a class that that declares
methods without actually "filling them in"....
etc....
Is this right?Pretty much, yep.
He goes on to say that because the class is an
abstract class, you can't create instances of this
class....unless a sub-class of this class is created
that implements the remaining methods. Which seems
logical, I guess.....but why would you do this? It
seems to be a lot of trouble just to neglect a few
methods...they have to be implemented in a sub-class
anyway to "arrive at a useful class" as he puts it.
So whats the point?When you specify the interace, let's call it Foo, you're saying what methods a class must provide if it's to call itself a Foo, but not how do provide that funcionality--that's left up to the actual implementation, as you've learned. For a given interface, there are many ways it could be implemented. However, there may be some common implementations for some of the methods that a family of implementing classes can share--a default implementation that isn't tuned and tweaked for any particular kind of use, but that does work. There may also be some methods for which no reasonable default exists, because it would be too closely tied to whatever your particular implementation is.
For a good example of this, look at the Collections Framework in the java.util package: List, AbstractList, AbstractSequentialList, LinkedList, ArrayList. By the time you get down to either LinkedList or ArrayList, there are only a couple of methods that are left unimplemented. Those methods interact directly with the backing store--i.e. that have to access "array[ix]" for ArrayList or the linked list nodes for LinkedList, so it doesn't make sense to provide a "common" or "default" implementation. The other methods use these methods to do their work, so they don't depend on the particulars of the backing store and hence a common/default implementation is provided for them.

Similar Messages

Component interface ( implementation ) is missing

Hello,
I had imported from NWDI one SWC that have some DC's. When I create a project in NWDS form one DC that have a dependence from another DC where the project has bveen already created in NWDS I have the following error message for this DC: "<error: missing compoent> component interface ( implementation ) is missisng". When I delete the referenced DCt from NWDS and sync used DC's from the DC with the error, the problem is solved.
But, when I create the refereced DC again, the DC that use this, the error missing component occurs again.
Anybody have any ideia about this?
thanks in advance.

You are absolute right in this, but this is not my problem. I will try to explain it once again. Currently I have the following configuration on my PE router
router ospf 5628 vrf INET
network 194.154.224.0 0.0.31.255 area 0
the f0/0 interface has this configuration
interface FastEthernet0/0
ip vrf forwarding INET
ip address 194.154.236.43 255.255.255.248
The problem is, that using this configuration, hello packets are send also through other interfaces of my PE router, which are part of the same ip address range specified under ospf process and are in the same vrf. In other words, hello packets are send to my Internet customers, which is not good. Because it is not possible to configure passive interface under ospf in the VRF, I decided to make the network statement more specific. I have changed the configuration to
router ospf 5628 vrf INET
network 194.154.236.40 0.0.0.7 area 0
and got the message
%OSPF: OSPF not enabled on FastEthernet0/0
The question is, why is OSPF not enabled on my f0/0, as the ip address of my f0/0 is part of a 194.154.236.40 0.0.0.7 network ?

Partial Driver Implementation

Hi All,
My application needs to connect to a sql database, which provides a partial driver implementation. Means to say that It does not implement either DataSource or XADataSource.
But for my enterprise application, deployed on Sun One Application Server 7, I need to create a pool name, for this database.
What should be done under these circumstances.
Thanks and Regards,
Ravi.
([email protected])

Unless writing a JDBC driver is the goal of this project, I don't see this as a particularly straightforward task. The network protocol Oracle uses is proprietary, so unless you want to invest a lot of effort in reverse engineering it, you'd have to write a driver that used OCI to communicate with the database. That would require that you install the Oracle client on the application server and delve pretty deeply into the OCI API-- not a trivial task on its own.
Additionally, I doubt that the internal logic required to be able to execute stored procedures is significantly smaller than the code to do both.
Justin
Distributed Database Consulting, Inc.
www.ddbcinc.com/askDDBC

How to register new interface implementation?

Hi,
I have the following problem:
There exists a self written webdynpro application. This application uses a Java Interface. The administrator of the application can add new functionality to the application by adding a new line to a table. He inserts the name of a class which implements that Java interface. This class has the new functionality.
For each interface implementation the user of the webdynpro gets a value into a list. He can select an entry from this list. This value tells to the application that it has to create an object from the related java interface implementation.
Now I wonder how I can tell to the webdynpro application that it knows all interface implementations which will come in the future? If I do not "register" or reference the new interface implementations, then I think the webdynpro application has ClassNotFound errors.
The developers should make there own projects for each interface implementation an deploy them. But what must be done, that the webdynpro application knows them?
Can you please give me some suggestions?
Thank you and best regards,
Marcus

You can register a Mac, but not an accessory like the Time Capsule. Keep a copy of your sales receipt.....just in case.

Designs for interface/implementation factory APIs

I've been building a complex data store for geographical information based on JNDI.
The store is basically working but I've been trying to make the API for programs accessing it more regular.
I'm dissatisfied with the way that new objects for addition to the store are instanciated. It's all a bit ad-hoc at the moment so I want to create a proper factory system, separating interface from implementation and allowing for the case where the interface has a different implentation for remote and local contexts.
I'm thinking the best approach would be to have a single create method, probably as a member of the extended context interface.
What I want to get is a sample of how programmers feal about different methods of passing creation parameters to such a factory method (or for that matter, to invite comments on the basic idea).
One possibility would be as a Hashtable or Hashmap. Generic keys (like datastore path) would be defined as constants in the context or factory interface, type specific keys in the interface which is used to access the object being created.
e.g.
Hashtable fsCreate = new Hashtable(5);
fgCreate.put(DataContext.PATH_KEY, "test.features");
fgCreate.put(DataContext.FORMAT_KEY, format);
fgCreate.put(DataContext.BOUNDS_KEY, boundaryRectangle);
FeatureSet fs = (FeatureSet)dataContext.create(FeatureSet.TYPE_VALUE,fsCreate);Another possibility would be some kind of parameter bean, with an fundamental parameter class and different extensions for each type of object to be created.
FeatureSetParams fsCreate = new fsCreate();
fsCreate.setPath("test.features");
fsCreate.setFormat(format);
fgCreate.setBounds(boundaryRectangle);
FeatureSet fs = (FeatureSet)dataContext.create(fgCreate);The Hashtable method has a slightly clumbsy feel, but it does avoid directly instanciating a whole bunch of new concrete classes (which seems to go against the spirit of interface/implementation separation).

If there's a create method in the interface, wouldn't
that make it accessible from anything that knows about
the interface? This would nullify the factory
pattern, wouldn't it?Not necesasrilly, that would depend how the create method was implemented. I already have a "retriever" object associated with each implentation class that can be retrieved from the data store. I can add a "create" method, effectively adding a factory class function to these. These retrievers are already registered with the concrete implentation of the JNDI Context.
Granted the implentations are in several different packages, so I can't restrict acces to these retriever objects to the package level.

Is the remote interface implemented by some class

Hi,
I have a simple question, googled, no help.
I am trying to udnerstand, where exactly is the remote interface implemented ?
I mean, i know that it contains all the business methods which have a body in the bean.
But is the remote interface implemented somewhere ? Is there any class which implements the Remote interface ?
thanks
S

Sarvananda wrote:
Hi,
I have a simple question, googled, no help.look better...
I am trying to udnerstand, where exactly is the remote interface implemented ?
I mean, i know that it contains all the business methods which have a body in the bean. so, that's what implements it :)
But is the remote interface implemented somewhere ? Is there any class which implements the Remote interface ?
the bean class :)
But the actual implementor is a class generated by the appserver that delegates to the bean class.

Use of DynamicProxies vs Interface/Implementation

hi all,
recently i came across DynamicProxies...i liked them and i wanted to apply them to my application, but i have a doubt.
In which cases it's worth using Dynamic Proxies instead of using an interface and different implementations?
In our app we have different Business Delegates, no common interface between, them.. If we could have one, then there will be no need to explicitly instantiate them in some, let's say, Action classes (struts..), but we could have a common factory which caches all the business delegates.
If we follow this approach of a common interface between business delegates, in which case it's better
to use DynamicProxies instead of writing different implementations of the same interface?
thanx in advance and regards
Marco

Its not clear to me exactly what you are trying to do.....
Are you just saying that you want a 'generic' factory which creates / caches business delegates?
If thats the case, Im not sure why you would need to use a dynamic proxy... This is because im assuming in your set up you would go to the factory each time you wanted a business delegate - so the caching is taken care of there for you.
One motivation for using dynamic proxies in this set up would be if you wanted to build the caching on top of the business delegate itself.
This would be useful in this sort of set up:
public class SomeBusinessDelegateClient {
    private SomeBusinessDelegate delegate;
    public void setDelegate(SomeBusinessDelegate delegate) {
      this.delegate = delegate;
    public void execute() {
      delegate.doSomething();
}Here, the business delegate you are using is being given to you. You just go ahead and use it whenever you need to.
But what if the 'real' business delegate had to be cached by some means?
Well, the factory which creates your delegates can wrap them in a dynamic proxy which validates its local cache before every invocation on the underlying delegate.
This removes a small bit on complexity (i.e knowing about the factory) from your client code.
In most cases, this is probably overkill, but it works well in some Inversion Of Control frameworks where the framework 'wires up' your collaborators at application start - and you just 'go use them' from then on without having to worry about factories / service locators etc etc

Anonymous class instantiation expression with interface implementation??

Is it possible to create an inline anonymous class instatiation expression that can implements an interface?
For example:
Frame myFrame = new Frame() implements WindowListner {
     public void WindowOpened(WindowEvent e) {}
         +other interface methods....+
}Apparently compiler doesn't like this code:(
I know that I can create an extra named class with the interface, then instantiate it instead. But this is not what I want.
(By the way, if someone wants to know why I want to do this, I say I think this may make my code simpler or look better, that's all:) )

abstract class ListenerFrame extends Frame implements WindowListener {} This look pretty neat:)
I guess I can rewrite my code then:
abstract class FrameWithListener extends Frame
         implements WindowListener{}      //local class
Frame myFrame = new FrameWithListener {
        public void WindowOpened {}
           blah, blah...
}Not sure I can use abstarct class as local class, but otherwise I'll use it as a class member or some sort..
Thank you for the reply
Edited by: JavaToTavaL on Nov 27, 2009 4:04 AM
Edited by: JavaToTavaL on Nov 27, 2009 4:04 AM

Listener Interface implementation questions

Dear all experts,
I am getting a bit confused of the "standard" way of implementing listener interfaces.
I found that there are 3 general methods:
1) create an extra class implementing the interface.
2) implement the interface as an inner class
3) using the existing class to implement the inferface :
eg:
public class oneofmyclass implement FocusListener
public oneofmyclass()
constructor....
all my other methods.........
the interface methods......
Why there are so many ways to do it?
what's the differences/benefits of each??
Thx

I am getting a bit confused of the "standard" way of implementing listener interfaces.
I found that there are 3 general methods:
1) create an extra class implementing the interface.
2) implement the interface as an inner class
3) using the existing class to implement the inferfaceThere isn't much difference between 1) and 2). The first alternative creates a named inner class
(that implements the listener interface) while the second creates an anonymous class using that
listener interface. Alternative 3) exposes the interface to the outer world, i.e. your class may be
attached to some listener list (in some observable) it really wasn't meant for.
I prefer 1) or 2) If the actual code for the listener is small I use 2), otherwise I use 1) but that's
just for readability reasons. I almost never use 3) because I don't want my class to be hooked
up to any observable it wasn't designed for.
kind regards,
Jos

Let JNDI use a own TrustManager interface implementation

morning,
i did now reach the point where my ldap enabled application is able to connect to a directory server over ssl.
i further figured out, that it is possible to tell jsse to use a own implementation of the TrustManager interface so that i would, e.g. be able to let my application talk to every directory server without any matter of being the certificate used by that server added to the keystore file used by the application.
now one of the last problems is, that i do not know how to tell the jndi to use my customized X509TrustManager implementation.
can anyone tell me how i can do that, please?
greez
dialsc

Hello.
Frist you create your own Trust manager, which looks something like:
package test;
import java.security.cert.X509Certificate;
import javax.net.ssl.X509TrustManager;
import java.security.cert.CertificateException;
public class TestX509TrustManager implements X509TrustManager {
    public TestX509TrustManager() {
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws
            CertificateException {
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    public void checkClientTrusted(X509Certificate[] chain, String authType) {
        return;
}Then you create your own Socket factory which looks something like:
package test;
import java.io.IOException;
import java.net.InetAddress;
import java.net.Socket;
import java.net.UnknownHostException;
import javax.net.SocketFactory;
import javax.net.ssl.SSLSocketFactory;
import java.security.KeyManagementException;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import java.security.NoSuchAlgorithmException;
public class TestSocketFactory extends SocketFactory {
    private static TestSocketFactory factory;
    private SSLSocketFactory sf=null;
    private TestSocketFactory() {
            createFactory();
    public static synchronized SocketFactory getDefault() {
        if(factory == null){
            factory = new TestSocketFactory();
        return factory;
    public void createFactory() {
        try {
            TrustManager[] tm = new TrustManager[] {new TestX509TrustManager()};
            SSLContext sc = SSLContext.getInstance("TLS");
            sc.init(null, tm, null);
            sf = sc.getSocketFactory();
        catch (KeyManagementException e) {}
        catch (NoSuchAlgorithmException e) {}
    public Socket createSocket(String host, int port) throws IOException, UnknownHostException {
        return sf.createSocket(host,port);
    public Socket createSocket(String host, int port, InetAddress localHost, int localPort)
            throws IOException, UnknownHostException {
        return sf.createSocket(host, port, localHost, localPort);
    public Socket createSocket(InetAddress host, int port) throws IOException {
        return sf.createSocket(host,port);
    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort)
            throws IOException {
        return sf.createSocket(address, port, localAddress, localPort);
}Finally, you'll have to tell the system to use your custom Socket factory:
    LdapContext ctx = null;
    public LdapTest() throws NamingException {
        Hashtable env = new Hashtable(11);
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, "ldap://myserver.com:636/dc=foo");
        env.put(Context.SECURITY_PROTOCOL, "SSL");
        env.put(Context.SECURITY_AUTHENTICATION, "none");
        env.put("java.naming.ldap.factory.socket", "test.TestSocketFactory");
        ctx = new InitialLdapContext(env, null);
    }The important statement above is: env.put("java.naming.ldap.factory.socket", "test.TestSocketFactory");

Q: DataWebBean interface implementation in DataWebBeanImpl

JDev Team,
Most DataWebBeanImpl classes (ie, RowSetBrowser for example) do not implement the render(PrintWriter) method of the WebBean interface. Why is this so? It seems that the DataWebBeanImpl relies upon the WebBeanImpl's implementation which is basically an empty method, which is as it should be...
Based on the WebBean interface, all DataWebBeanImpl's should both render() and render(PrintWriter), and output the same information independent of call. In fact, in the WebBeanImpl render(out) is called from the render() method!
Please respond. Thanks,
Joe

I never had a J series in my hands and I'm not sure that serie support vlan stacking and rewriting.
See on M series junos9.1 (pag 455):
http://www.juniper.net/techpubs/software/junos/junos91/swconfig-network-interfaces/swconfig-network-interfaces.pdf
Greetings
Riccardo

Two Interface implementation with different signatures

Hallo,
I'm searching a solution for the following problem:
I have an Interface which has to have the following methods names:
deleteObject()
moveObject()
and besides that I must have to classes which implements this interface, but because of the nature of the programm these classes have the following signatures:
class 1.
public static boolean deleteObject(File objectToDelete)
public static boolean moveObject(File srcObjectPath, File dstObjectPath, SVNRevision revision, boolean isRename)
class 2.
public void moveObject(Folder rFolder, FSObject rFSObject)
public void deleteObject(FSObject rFSObject) but unfortunately I cant see how to solve this problem, bearing in mind that that the signatures of the methods of the second class cant be manipulated, the signatures of the first one are flexible?
Thanks in advance
Christian Rosenfeld

well, the story is like that: I have finished my master thesis which includes programming. This thesis contributes to an already existing big project.
The original implementation of the integrated file browser has the follwoing methods:
public void moveObject(Folder rFolder, FSObject rFSObject)
public void deleteObject(FSObject rFSObject)My implementation which is a total new implementation of the file browser, which also has version control, must have same named methds (deleteObject, moveObject). Now because of the nature of the programm that I have implemented, these methods have the following signatures:
public static boolean deleteObject(File objectToDelete)
public static boolean moveObject(File srcObjectPath, File dstObjectPath, SVNRevision revision, boolean isRename)Now for some reason that I dont really understand, the subervisor is asking about an interface which will allow him to choose between the two implementations, like:
interface FileOperations{
moveObject(...);
deleteObject(...);
}but what shall the signatures of the interface be? supposing that the signatures of my methods can be manipulated, ist possible to find a suitable interface?
Christian
Edited by: ChristianRosenfeld on Sep 22, 2008 1:57 AM

Email interface implementation

Hello
i am now starting to implement my email interface using MHP. What do i need to know in order to implement this? I read in the MHP tutorial that there is an emailclient service.
What are the classes needed to use the STB modem? Or if just create an email client with the java.net package it will automatically use the modem to reach the internet? Or is it more complex than this?
any advises are welcome.
thanks a lot
sebastien

IRT (www.irt.de) offer a 'reference implementation' that runs on a Linux PC, as far as I know. Other posters will be able to comment more about this. Galaxis and Panasonic also offer development systems, but I know very little about them.
One option for development is the Osmosys MHP4Win product - a full MHP implementation that runs on a Windows PC. I've never played with it, but I've heard some positive feedback from people who have used it.
The IRT and Osmosys products will probably support Ethernet, but I'm not sure of any real STBs that do except for the one that Roger mentioned. (Was that the Philips 'Black Box' STB, Roger, or the 'Silver Box'? I was one of the guys who wrote the 'Black Box' middleware, so I know that product pretty well, and I had some contact with the guys who wrote the 'Silver Box' middleware). Both of the Philips boxes are no longer available, although some people are still using them for development.
Steve.

Ultra Simple WCF Interface implementation in Biztalk?

I have a series of WCF services that I need to emulate in BizTalk defined using a pattern like this:
[ServiceContract(Name = "AssignmentService", Namespace = "http://test.org/webservice")]
public interface IAssignmentNotification
[OperationContract(Action = "http://test.org/webservice/Assignment")]
string Assignment(string assignmentXml);
The strings (in and out) are well formed complex xml documents. The calling system currently is implemented using this type of interface because there were issues getting well-formed NIEM compliant WCF or Soap documents (I'll save that for a different
post later).
I have searched around, and I do not seem to be able to find any type of example showing how to receive a string, transform it into an Xml-based message (BTW, BizTalk does appear to consume the XML of the message fine to create an XSD that can be used for
mapping); do a bunch of processing, and then turn around and generate an XmlDocument (again, BizTalk can generate an XSD matching the Xml needed here) and finally transforming it into a string.
I have all of the moving parts working, exception for the pipelines to get the strings in/out in a way that conforms to the desired interface.
Does anyone have any pointers or sample code they could share that does this?
Thanks,
John

One of the way out is for you to create a service (pX). This service is what is exposed with your data contract (publish service as WCF).
This service will then get the string (if you use assignmentXml as distinguished) then in the orchestration you'd get receivedMessage.assignmentXml as a string.
You will then have a message type mXtyp (multi-part) in the orchestration where the message type is of the schema you expect to receive, it could be an XmlDocument also.
Now, on receipt of the message, you will utilize a orchestration variable (varXmlDocument of type XmlDocument) to load the entire string as an XmlDocument (use varXmlDocument.LoadXML(receivedMessage.assignmentXml)) and assign it to a Message (mX) of the
type mXtyp as mX.parameters = varXmlDocument [parameters is the name of the body part defined in multi-part message type (mXtyp).
Then you can use Direct Bound ports and publish this. The orchestration which needs to process this message type can similarly use a direct bound port (two-way) to receive and process the message.
The service orchestration (pX) will receive the response and using a similar assignment (reverse) create an XmlDocument and return the XmlDocument.OuterXML as part of its service response.
Regards.
NOTE: you can make pX a generic service where before publishing you can promote messageType on the message and use XmlDocument as the generic published message to direct bound ports. This way you can use the same endpoint to expose multiple service each
of which can consume a specialized XML request/response.

Annotation for interface implementation

I like the @Override annotation that you use when you're overriding a method from the parent's class.
It lets you know when you look at your code that it is overridden and that it is not just some local method.
Is there something similar for methods that implement different interfaces?
Like say you implement the Comparable interface.
Wouldn't it be nice to be able to look at your code and know why some method is there?
@ImplementedFor(interfaces={"Comparable","SomeOtherInterfaceThatRequiresCompareTo"})
    public int compareTo(Object o) {
        return new Random().nextInt();
    }Note: I'm not sure about syntax or if this is possible. I only use the annotations that Eclipse generates for me.
Please, just comment or let me know if anybody has other tricks to keep their stuff more organized.

nothing in the language, but you can create your own for this purpose (and enforce it at compile-time)

Partial Interface Implementation.....am I right?

Similar Messages

Maybe you are looking for