I am new to Java and might be asking a basic question which might sound silly to some.
After I compile my Main Java class most of the subclasses are displayed as $ in the folder. I copy the complied classes and put it on another location to execute. Everytime I make make a change to the main class or one of the sub classes do I need to copy all the associated subclasses? or just copying the changed ones will do?
Thanks.
Nick
Copying the changes will do.
Normally, you would let your IDE (e.g., Netbeans) / build system (e.g., Ant / Maven) do this for you. Alternatively you could create an executable jar-file, leaving you with only one file to copy.
Classnames containing $ are for nested/anonymous classes.
And see this Stackoverflow question.
But that's not the whole point. Quoting OP I copy the complied classes and put it on another location to execute. -- looks like you should automate this task and employ one of traditional Java build tools such as Ant or Maven.
Nick,
Are you referring to nested classes? If so, they will contain "$" in the compiled class file names. Assuming your code changes were only to the parent class, the nested class bytecode should not have changed during the recompilation. It should work to only copy the main .class file. However, it's obviously more of a guarantee to copy the everything.
Is this about subclassing (class Y extends X {}), or nested classes (class Y { class X {} })?
The $ that you mention seems to indicate the latter, in which case you should probably copy everything, but if you are only subclassing then just copying the compiled versions of the files you have changed is probably just fine.
Related
i want to compile child.java class an get child.class, child class extends parent class.
i want child.class include all necessary code from parent class, in fact i can use it independently.
is it possible?
second Question: suppose we have a .jar library containing a.class , b.class , c.class ... i have make an updated version of a.class, how can i replace the new one with the original a.class in jar? is it possible ?
sorry for bad English.
1) as Dmitry mentioned in the comment is impossible. Even if your parent class did absolutely nothing it's definition will still be checked, and if not found ClassNotFoundException (or similar) will be thrown
2) Is certainly possible and usefull in some situations (patching external library without recompiling everything from sources comes to mind) - see Is there are way to patch jar files?
Specifically the most usefull (IMO) is CoolBeans's answer:
jar uf test.jar com\test\Test.class
Note that you have to take care of correct packaging. And it will not work if the jar is signed.
Java class files inside jars can be easily replaced and modified. For instance, the following command can be used to replace a compiled class file within a jar:
jar uf JarFile.jar com\something\Class.class
If the class file was replaced with a file such that no dependencies were broken, then the code is still able to execute. The same happens with class files that are not inside jars.
Is there any way to validate a set of class files (whether inside a jar or not) to see if all their dependencies are present and not broken?
I do not want to prevent class files from being modified but rather to be able to verify that changes are valid (with respect to dependencies). The compiler does this check (dependency-check) at compile time, but once the classes are compiled, how can one verify the class files themselves?
You might have sealing and signing JARs in mind.
Update:
Apparently I've missed the mark with my first guess.
What do you plan to do if they're not? If they're a 3rd party, I'd say that you've got little choice besides reporting to the bug database that the download is bad.
If you mean "I want to make sure that all their 3rd party JAR dependencies are correct", you've got a much bigger problem. Most downloads that I know of (e.g. Spring) make dependencies available using Maven. That's the best you can do.
If you mean you want to check your own dependencies, I'd say that testing would reveal any errors you've made.
Just loading the class will ensure that.
no, you cannot.
at least: not really.
the problem is that java loads classes at runtime only when needed. so eventually it might be alright to remove a class from the jar file and as long as no code referencing that class is executed things run very smoothly.
consider this example:
class A{ public static void main( String args[] ){ out.println( "hello" ); } }
class B{}
compile this, put it in a jar, remove the B.class from it, no problem there :)
now you might think you can go through each .class file, check what classes it references and see if the files are all there. not only is this painful, it is also incomplete. you will never quite catch files loaded with reflection because their class names might be constructed just at runtime.
my advice: don't go there. if someone removes a class file it's their own fault.
the best thing you can do is (but only if this really really worries you) try to catch ClassNotFoundExceptions at runtime (look into thread.setUncaughtExceptionHandler)
Let's say that I have two classes (Bob and Tom) such that Bob uses Tom, but Tom does not require Bob. Both of these files are located in the same directory structure.
public class Bob {
public static void main(String[] args) {
System.out.println(Tom.MESSAGE);
}
}
public class Tom {
public static String MESSAGE = "Hello World";
}
If I attempt to compile Bob in the typical fashion, I can get it to implicitly compile Tom.java as well since it is recognized as a dependency of Bob.java. That works great.
But now let's say that I want to place Tom in a JAR file. So I build Tom.java and place the results into a JAR file: libTom.jar. I now compile with the classpath pointing at libTom.jar. Unfortunately, the compiler sees the Tom.java file and causes it to be compiled rather than using the class in libTom.jar. Is there a way to get the compiler to skip the implicit construction of Tom.java if the class is found in the classpath?
I recognize that this example is fairly contrived. Rest assured that there is a more complicated, less contrived use-case that surrounds this issue. Thanks.
If there are two classes with the same name and in the same package in the classpath, it is difficult to predict which one will get picked up when java compiles the code. In case the Tom class exists in the source itself, it will surely get picked up.
One way you can avoid it is to put one of the Toms in a different package. Another way is if you can move your current Tom to a separate project. I understand either of these might not be practical for you. If it is really necessary, you could experiment with writing your own ClassLoader. See this question for reference: Jar hell: how to use a classloader to replace one jar library version with another at runtime
It appears that this just isn't possible, which is what I feared from the beginning.
Yes, you could do that by typing the full name of a class, i.e. Typing
System.out.println(the.package.of.external.Tom.MESSAGE);
System.out.println(the.current.package.Tom.MESSAGE);
Can you split the java files into separate source directories?
This would make sense as you could build your jar from the contents of one source dir, then just include the other source dir when compiling all the other set of files.
This works well in Eclipse.
Even better would be to use two projects in Eclipse.
I would like to know What are the difference between folder-structure and package used in Eclipse IDE for Java EE development.
When do we use which one and why?.
Whats should be the practice
create a folder structure like src/com/utils and then create a class inside it
create a package like src.com.util and then create a class inside it
which option would be better and easy to deploy if i have to write a ant script later for deployment ?
if i go for the folder-structure will the deployment is as easy as copying files from development to deployment target ?
If you configured stuffs correctly. Adding a folder inside src, is same as adding a package from File > New Package.
So, it's up to you, whatever feels comfortable to you -- add a folder or create a package. Also, when you put stuffs under src the package name starts from subfolder. So, src/com/naishe/test will be package com.naishe.test.
Basically there is no difference, both are the same.
In both the cases, the folder structure will be src/com/utils.
and in both the cases, you will need to mention
package com.utils;
as first line in the class
Since it doesn't have any difference practically, it won't make any difference to ant script.
"Packaging helps us to avoid class name collision when we use the same class name as that of others. For example, if we have a class name called "Vector", its name would crash with the Vector class from JDK. However, this never happens because JDK use java.util as a package name for the Vector class (java.util.Vector). So our Vector class can be named as "Vector" or we can put it into another package like com.mycompany.Vector without fighting with anyone. The benefits of using package reflect the ease of maintenance, organization, and increase collaboration among developers. Understanding the concept of package will also help us manage and use files stored in jar files in more efficient ways."
check out http://www.jarticles.com/package/package_eng.html for more information on packages
create a package like 'src.com.util'
That sounds like a mistake. The package name should be 'com.util', and 'src' is the name of the source folder.
Other than that, I fail to see what the difference is between your two choices. The result is the same, right? Just different steps in the GUI to arrive at it. The wizard to create a new package in Eclipse is just a wrapper around creating the appropriate folder hierarchy within a source folder.
You don't need to create empty packages at all, you can directly create classes (the package will be created automatically if it does not already exist).
A package is automatically "source folder" where folder is just a normal folder.
When you compile an Eclipse project, all files in source folders are compiled but not in regular folders (unless those regular folders a)
folder structure or to be specific source folder in eclipse is meant just for eclipse but package is universal irrespective of any editor..
I have read the documentation and several websites on exactly how to do this, however Matlab does not seem to pick up the classes that I have added to the dynamic java class path. Nor do I use the right syntax to correctly construct the object.
I have an class HandDB and which to create an object of this type and invoke it's static methods to connect to a SQL database. The class has an empty constructor and takes no parameters. The class is part of a package 'nuffielddb' which I made in a project within Netbeans. All the files are on my usb stick which is my E:\ drive...
I would like to be able to use all the classes within the package. The package is contained at E:\nuffielddb.
I entered the following commands into Matlab:
javaaddpath('E:\');
javaclasspath; % Output from java class path includes E:\ within dynamic path
str = java.lang.String('Test'); % Works fine
db = nuffieldbd.HandDB(); % Does not work - undefined variable or class error
Interesting I typed 'import nuffielddb.*;' and received no error.
Just where am I going wrong?
Thanks for your help btw!
Ah problem solved! Well not solved in a sense! I found out it's actually a problem with my matlab installation and I have no idea how to fix it :-(
Never mind, it works on the computers at the office :-)
if your classes are in a .jar file, make sure your classpath includes the .jar file name itself (not just the directory it's in).
Also if the MATLAB JRE is Java 1.5 (R2006b is, whereas R2009a is Java 1.6, not sure when they switched), make sure your classes are compiled with 1.5 as a target, not 1.6, otherwise MATLAB will not be able to use them.
Minor note: .* imports will never error, so they're not diagnostic. They simply add a package to the list that Matlab searches through when trying to resolve a class name. Nonexistent packages are ignored.
>> import this.package.does.not.exist.*
>>