We Keep Coding

What's the point of using .class objects?

In the past few weeks, I've run into several different peoples' code using .class objects. For example, ArrayList of classes : ArrayList<Class> but how to force those classes to extend some super class?.
I looked them up: http://docs.oracle.com/javase/tutorial/reflect/class/index.html
I'm just wondering why you'd want to use .class objects. I can see getDeclaredFields() and getDeclaredMethods() being potentially useful, but I can't really think of concrete examples as to why I'd actually want to use the .class objects in lieu of something else. Could anyone shed some light on this topic?
Thanks in advance.

I think you misunderstood the concept. Class class has nothing to do with compiled classes (.class).
Class is a class that represents a Java class internal structure, such as fields, methods, etc... This is a compile-time entity, which you can use in your code (even before compiling).
.class is a compiled Java class file, which is Java bytecode. This is not a "code" entity (you cannot use it as a class or object in your code -besides as any file-) and it is not available before compilation.
Reflection (Class is part of the reflection package) is useful when you want to do advanced stuff with the code, like manipulating it, accessing its members, getting information from it, etc...
A typical example where you want to use reflection is making a Java debugger. Since any code can be run on the debugger, you need reflection to get information about the object instances and their structure and show this to the user.

Reflection is one reason to use it. Another good example is dynamically constructing objects at runtime.
For example, the Spring framework uses configuration files that contain the names of Java classes. Somewhere in that code, Spring needs to build object instances of those classes. In this way, the objects are created without the compiler needing to know anything about the Java classes at compile time.

This can be useful when developing an interpreter of a scripting language running on JVM, which has an ability to call Java methods.
Also, might be useful in a system allowing for plugin extensions.

Another use case:
InputStream is = MyClass.class.getResourceAsStream("/some/resource/in/the/jar");

Plug-in are a big use for this.
Dynamically load .class files which are in say, your plugins folder and execute some specified function from said files. Then, you can have 0 or more plug-ins and any combination of them installed for your application at a time.

Scala cannot reference Java classes

I have a Java framework for a chess AI server. I'm planning on using Scala to write the logic for my chess AI. So I need to edit the "AI" class of the framework to call my Scala code.
My problem occurs when I try to reference a class from the java framework in Scala and I get an error that follows this pattern:
class * in package * cannot be accessed in package *
the most relevant thing I could find was this:
What are the guarantees for scala access qualifiers? , however that doesn't help me at all.
next I found this: is it possible to have a circular dependency between .java and .scala classes?
I'll try setting up a maven solution, but eventually I'll need to compile it using make, and run it using a shell script
Creating dummy classes seems like a poor solution. I don't want to keep editing the framework, recompiling it, and fixing any complaints it has about calling my Scala classes.
I'm a bit confused as to why this is a problem. I can call any native Java function using Java syntax, no problem. Why does this happen, even when I've put the framework in a jar and referenced it that way?

It appears the particular class(es) are package private. Please make them public and then report back.

Creating a new Java application using the compiled class files

I have an application that is developed in Java that has nice GUI and all. I don't have the source code and also the dll's of that. But I have the compiled classes of that application (.jar files).
Now, I want to automate that application. I mean the application needs manual intervention.
Can I use that compiled classes so that I can use its functions to automate the functionality of that application?
If so, how would this be done?

You shouldn't have to "got the compiled classes out of that application (.jar)". A better idea would be to treat it just like any other 3rd party JAR and add it to your CLASSPATH when you compile and run.
You'll write your own class that instantiates an instance of that 3rd party class and calls its methods, just like any class you get from the JDK.
You may not be able to alter that class; you might not want to even if you could.
If you must have new functionality, the OO way would suggest that you should extend that class, if you can, and override its method according to your needs.

Put that .jar into your classpath and use what ever you want from that application. If you need to use private fields or methods also you can use Reflection API for that. There is no restrictions of using objects from .jar file.

You should beware of infringing on any copyrights if the application you are referring to is proprietary. Otherwise, any java decompiler will get you the source code from those class files.

dynamic creation of class at runtime from file

I'm looking for a possibility to load the Java code dynamically into a
class at the run time. The Java Code should be readed from an
XML-file. There are just some "If-Then" expressions and should be
added into one class and use it like any other class in my project.
Actually my file contains some rule codes which i want to load like cache and use
this class further
Does someone know if it is possible in java?
best regards
Abhij

I believe you can do this with CGLib, but I haven't done more than use it to mock classes at runtime. If dynamic code is a major aspect of your application you should consider using a language like Ruby which has much better support for running code read in at runtime.

Class Loading to an interface

I'm quite restricted in the platform I'm currently working on (JDK 1.3, BD-J). One JAR file I would like to use attempts to perform a self-integrity check on load and if it fails it goes into an inoperable state. It's quite difficult to find out why this is happening but most sources point to that it cannot find/access it self through the BD-J structure, so it dies.
This rules out using it at load time and instead to load it in the application itself. This is quite a large library so I have to create quite an amount of interfaces so I can cast a loaded object to it and potentially use it. This is where my problem lies.
The interfaces are loaded on normal load time and the library is then loaded during run time and casted to the previously loaded interfaces, is this a problem? I'm receiving ClassCastException
I've based the interfaces off the libraries public methods as best I can, but when I attempt to cast to an interface I receive the ClassCastException. Note: It all loads fine, I can access constructors and read the method names. Just when casting it for it to be useable it fails.
The interface packages are different in my project to that of the toolkit, does this matter?
I'm running out of ideas, is there something I have overlooked?
Thanks.

I'm not sure I fully grok what your problem is - maybe some more details about what the class hierarchy looks like would help in figuring out the situation. From what you wrote I can guess two possible scenarios:
.1. The classes you want to use do not implement any interface.
In this case no matter what you name your interfaces, it will not work, since the classes you're loading do not implement them. You're stuck with using reflection if you can't load that jar as part of the boot classpath.
.2. The classes you want implement some interface that you're trying to replicate.
In this case you interface implementation must match the exact qualified name of the interface the classes are implementing. Normally, when loading the classes from the jar, the class loader will pick up the interfaces from the system class loader first, thus loading your interfaces, and everything should work.
If they use some crazy internal class loader, though, they might still try to load their own interfaces. You could try to figure out if that's the case by using "-XX:+TraceClassLoading", although I don't know if the 1.3 jre will understand that option.
Now if you're willing to experiment more, you could also try another approach. Write your own class loader that loads both the classes from that jar and the code you want to run. That way, your code would be able to directly refer to the classes in that jar, but to start your application the "main" method will have to be one that initializes this classloader, loads the "real" main class using reflection, and executes its main() method also via reflection.

Most probably the classes are loaded by different class loaders. http://mindprod.com/jgloss/classloader.html may give some idea.