We Keep Coding

JAVA class implementation and extension issues

We have 2 JAVA classes related to a project, call them AGraph and CallGraph. We also have an interface named Graphism which is implemented by AGraph. There's one abstract class we have, named GraphSnippet, which basically creates a visualization of a ZEST graph.
Now, we want CallGraph to extend AGraph. My silly doubt here is, does CallGraph need to implement the interface Graphism as well?
Next, instead of making GraphSnippet an instance of the Graph class (Graph is a pre-defined class in the ZEST package), we want it to be an instance of CallGraph so that the functionalities of CallGraph and AGraph become a part of the implementation. And because we'll need the class AGraph during the later stages, we can't really knock this class out and get all its methods implemented in CallGraph.
Could someone help us with how to start with it? It's difficult for us, novice JAVA programmers, to figure out a way?
PS: We're working on Eclipse-JUNO.

Now, we want CallGraph to extend AGraph. My silly doubt here is, does
CallGraph need to implement the interface Graphism as well?
Yes, but you won't have to do anything. Because it extends from AGraph, it will already implement Graphism. You won't have to mark this anywhere in your code.

Java Object Oriented Design

I'm just starting to learn and the books say that I can use "pre-coded" classes and objects. How do I call these classes/objects in the beginning of my program? I understand basically what they are, and the idea that I can use these classes/objects in place of writing fresh code every time, but I cannot seem to figure out where I find these things and how I implement them.

You certainly talk about the Java classes that come in JRE/JDK.
Those are used by including the jar in your classpath and provides the "default" java classes.
Like String in java.util package.
If you want to look at them, in the JDK you'll find the sources of these class.

"Pre-coded", or pre-written Java classes, are pretty much the same concept as the Java API - someone has written the code for you, was kind enough to document how you can use the code, and you may create instances (as necessary) through the prescribed way.
Say, for instance, I want an ArrayList holding Strings. I would then code ArrayList<String> words = new ArrayList<String>(). You wouldn't have to go through the process of writing a dynamic self-expanding vector.

Extending GenericModel for Play Framework

I need to add some logic to GenericModel by means of extending it, but I understand that Play uses generics to enhance the GenericModel. What would be the right and most convenient way to extend this class?
I tried to do this, but some of the methods in GenericModel simply throw a UnsupportedOperationException exception, so this is clearly enhanced somewhere else.

Check out db.jpa.Model which also extends GenericModel.
If you intend to extends the GenericModel, I would do it in the models package. No need for an external module and it is best to avoid touching playframework core. You will have trouble updating it if you do.
But still, after a quick look at the source code, it seems that you are trying to modify JPA related code. What kind of logic are you talking about?

I've managed to get this working by means of reflection. Everything is now working 100%. :) Not really the best solution, but it works.

What is the optimal way to share code between Activities with different base classes?

I have the following problem:
I have an abstract Activity class, lets call it MyAbstractActivity, that contains some code I'd like to reuse (for example: a standard service binder, common menu items, common initialization code, etc. etc.). Normally I would just use it to subclass my concrete activities and be done with it.
However, I occasionally need to use another supertype, such as a ListActivity or a MapActivity.
So the question is: how do I avoid duplicating that support code within an Activity, if I have to use another base class?
I have thought up of a solution based on the decorator pattern, like this one:
.
However, I see a problem with this approach:
What to do with protected methods (like onCreate())? Should I introduce an additional "bridge" class that makes them public for the purpose of the decorator, similarly to the way presented below (starting to look a bit byzantine...)?
Any other way?
I hope I made myself relatively clear. Thanks in advance for any feedback!
PS. Using static utility classes is not a good solution in my opinion, since it introduces a possibility of hard-to-identify programming bugs.

If I understand correctly, neither Fragments nor the Decorator Pattern are clean or appropriate solutions for what you want to accomplish. They were designed to solve other problems.
I find myself moving "support" code, or "framework" code, or "all that verbose, repetitive, boilerplate crap" to static utility methods. This isn't necessarily the approach I'd take on a non-Android project, but in my Android projects, it works pretty darn well.
Also, know that you don't need to subclass ListActivity to have a ListView.

DLLs for a dynamic Java program?

I'm currently working on a Java project where I have a set of data which I wish to output in several custom formats. I have a class for each format, which takes the raw data and converts it accordingly. However, to begin with I am only implementing two or three of these formats, but wish to allow more formats to be added at a later date without having to do a massive rebuild of the application.
My idea was to create a DLL for each of the format classes, and have my application pass the data to be converted to each of these. This way, I can create a DLL later on and have my main application accessing it. (I would gladly listen to any alternative ways of doing this, as someone who has done this in C++/C# before this felt like the logical solution but it may not be applicable to Java)
My problem is that I have absolutely no idea how to do this - in C++/C# I could write this in a few lines of code but I'm not sure how it works with Java. At the risk of asking a terribly vague question, how can I do this?
Answers are greatly appreciated and cookies and tea will be offered. :)
Thanks in advance,
M
Edit: Sorry, just to add: I am also unsure how to create the DLL, which must be in Java for this project, to be read in the first place. Thanks. :)

Rather than using a DLL per se, it seems like what is wanted is a plugin architecture of some sort.
One reason why I wouldn't recommend using a DLL unless it is necessary is that linking Java code with native code will require using the Java Native Interface (JNI) which would probably require more effort than a pure Java solution.
One relatively simple way to do so is to use the reflection capabilities of Java.
From the information given, I would probably go along the lines of the following:
Define an interface for the output format.
Create a Java class implementing the interface.
Have the class available from the classpath.
Dynamically load the class using reflection. (Using the Class.newInstance method can instantiate objects from class files loaded by the ClassLoader.)
With these steps, it would be possible to implement a simplistic plugin which wouldn't require a full rebuild when support for a new format is required.
Step 1: Define the interface
Let's say we end up with an interface like the following:
public interface Outputter {
public void write(Data d);
}
Step 2: Make an implementation class
Then, we'll make an implementation class.
public class TextOutputter {
public void write(Data d) {
// ... output data to text
}
}
Then, compiling the above, we'll end up with a class file called TextOutputter.class.
Step 3: Make the class available from the classpath
When running the main application, we'll need to have the above TextOutputter.class in the classpath. Normally, one would tell the JVM a list of places to consider as the classpath, and that should include the above class file.
Once that is done, we should be able to load the above class using reflection.
Step 4: Dynamically load the class using reflection
Now, when we actually want to load the above class, we'd do something like the following:
// Note: We load the class by specifying the fully-qualified class name!
Class<?> clazz = Class.forName("TextOutputter");
// Then, we instantiate the class.
// Note that the following method will call the no-argument constructor.
Outputter outputter = clazz.newInstance();
// Now, we can give data to the TextOutputter object that we loaded dynamically.
outputter.write(...);
The Class.forName method is used to attempt to find the TextOutputter class from the default ClassLoader. Once we obtain the class as a Class representation, we can then instantiate an object of that class.
Instantiating the object can be performed by using the Class.newInstance method. If something other than the no-argument constructor should be used, the Constructor of the class would have to be obtained proceed to instantiate the object from there.
The object instantiates via reflection is then placed into a Outputter variable, so the write method can be called on the TextOutputter.
Adding more formats would entail the above process, but changing the fully-qualified class name (e.g. for String, the FQCN is java.lang.String) is all that is needed to load up a different class.
In a nutshell, that's what it will take to dynamically load class files and use it from your application.
(Just as a side note, I did not actually compile the above code, so there may be some errors here and there, but I hope I could illustrate the process it will take.)

I've made such things.
i created an open java based plugin architecture POJO based,that even did reload on the fly of updated plugin classes.
JNI is the interface for dealing with native code.
The only technical part was to rewrite a classloader that enabled DLL reloading dynamically at runtime.
But if you do only make "offline" updates, no such things are needed.

You can load a new DLL at any time with System.loadLibrary(). However you may need to load a java class for it to bind to.
You might find using an OSGi container helpful as this supports both load and unloading of modules (including shared libraries)
I would suggest using karaf with iPOJO but there are many others.

If you want write native codes (compiled to a DLL) to be used in java, you want to look at Java Native Interface (JNI).
Update you can use System.loadLibrary(String libName) (if you know the library name and the library path is set) or System.load(String filename) (library filename) to load library (DLL) in java.

I think you can ignore the JNI path. I have the impression you're using the term dll for lack of a better word, you don't really need a dll.
You could do the same thing in Java, but you'd put your filters in jar files instead of dll.
Define an interface for the file format filters to implement
Put each implementation into a jar, in a specific folder (like 'filters')
At one point in the app, iterate over the folder, generate classloader for the jars
Use reflection to find all implementations of your interface, and create a class for each
Call the methods to do their job
That's basically it.

Java SE 6 introduces the ServiceLoader class:
http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html
If you want a proper modular approach consider the NetBeans Platform (especially if it is a desktop application) or OSGi.