I'm not sure why I can't process this right now, but I have four packages in one source folder:
./src/common
./src/server
./src/client
./src/unittest
Common uses no files from any of the others, but server and client use files from the common package. In each of the files in those packages I have import common.*. But when I run the compiler with javac ./src/server/*.java it can't find the common package.
The only info I can seem to find is for tree structured package hierarchies, but how do I reference something at the same folder height as me? Do I need to nest common inside both server and client? That seems likely to generate a lot of redundant code.
I'm sure this is probably a question someone has asked before, so I apologize, but I cannot find it anywhere.
If you want it to find those files automatically without having to specify them, you'll need to be in the package root, so run this from within src:
javac server/*.java
That would then work.
However, personally I would always specify all the code you want to build, rather than letting javac pick up extra bits. If you want to build the common code first, I'd do so and then add a classpath entry so that javac will pick up the compiled classes rather than the source code.
(Alternatively, I'd spend most of the time in an IDE where it's largely automatic, and then use a fuller build system such as Ant to do the actual building.)
Related
After developing a java app in Eclipse, I would like to deploy it by packaging it into a runnable .jar with only the minimum necessary by the main method and its dependencies.
I have several packages in my workspace I work with too, but do not need to be in the resulting .jar file.
When I try to export, it clearly says that the required libs will be there, but also the other independent packages are inside too. (With the Export option happen exactly the same)
I choose to export only the Main class of the com.project... package, but also the test.project... has been packaged.
In the project I have both com... and test... packages obviously.
How could I force it to truly package only the required ones?
Thanks in advance.
TEMPORARY ANSWER (2019-07-03):
Seems that, for now, there is no way to achieve this automatically, thus the answer from #arnonuem seems a good workaround.
If better news, please feel free to improve this thread.
Thank you all.
I would create an ANT file for this specific task. There you can freely customize which packages should be compiled into the jar and which not.
Please inspire yourself reading this example.
For a general overview what i am talking about you could take a quick look into this.
https://howtodoinjava.com/ant/ant-build-jar-file-example/
Please focus on
<javac srcdir="${src.dir}" destdir="${build.dir}" classpathref="classpath"
includes="src/path/to/TheClassToBeIncluded.java" />
For more detailed information on how to include or exclude files or packages you should refer to the documentation over here:
https://ant.apache.org/manual/Tasks/javac.html
At the bottom of this page there is a list with valid build parameters.
First of all, we have to distinguish build and export.
Build transfers .java source code into .class byte code and mostly copies other resources. While doing that it usually merges all source folders into a single bin folder.
Export runs a build (or relies on Build Automatically) and then modifies the resulting .class files and other resources. Usually it packages them into one or more .jar files.
Therefore, our solution includes two steps:
build everything that is unwanted for export into a separate folder (or more)
export from a specific folder (or more)
For step 1, refer to this answer on Stack Overflow.
In a nutshell: Go to Project Properties > Java Build Path > Source tab > Allow output folder for source folders. This enables you to configure a specific output folder for each source folder in the centered viewer.
For step 2, we need to understand that eclipse's Runnable Jar File Export relies on a Launch Configuration.
So before exporting, go to Run > Run Configurations..., select the Classpath tab, remove the default User Entries and hit Advanced.... Now you can Add Folders containing your built classes.
You might want to use separate Run Configurations for internal testing and exporting.
I have struggled with this problem on and off for years, supposing it was just me who was failing to find the right solution. Possible solutions always seem to involve detailed manual configuration e.g. configuration of the build path, or selection of the folders from which classes are exported into a jar, or learning ant, but which still requires manual configuration. The problem is that the inter-dependencies between classes (and packages) are complex - imagine drawing a network diagram from import statements. Manual configuration is time-consuming, error-prone and, I think, infeasible except in simple cases. I am a bit stunned. If there is no automatic solution for selecting necessary classes, I suppose people are regularly exporting their entire code base and that the world is full of bloated jars ... (and, incidentally, without obfuscation, the entire source code base is thereby made available through reverse engineering).
I'm working on some Java code in eclipse. Code is contained in a single class called Adder, which in Eclipse is in the package org.processing. The first thing in the class file is the line
package org.processing
Q1) What, exactly is this line doing? Why is there, what's it's role.
The code runs fine in eclipse, however, when I move into the workspace if I go to the src/org/processing/ folder in src, compile with javac Adder.class when I try and run using java Adder I get the following error
java.lang.NoClassDefFoundError: Adder (wrong name: org/processing/Adder)
On the other hand, if I compile from src using
javac org/processing/Adder.java
and I can run it from src using java org.processing.Adder but STILL not from within the processing directory.
Q2) Does this mean that compilation is always relative to directory structure?
Finally, if I remove the package org.processing line from the start are the .class file I can compile and run from within the .class file's directory.
Q3) Why is all this the way it is? I can fully understand enforcing a directory structure for code development, but once you're in bytecode this seems a bit over the top, because now I can (apparently) only run the bytecode from one director (src) using java org.processing.Adder. Now, I'm sure I'm missing the point here, so if someone could point out what it is, that would be great.
The compiler has to be able to find related source code files when compiling. This is why the package and directory structure must agree for source code. Similarly, the JVM must be able to find referenced .class files. So the same directory structure is required at runtime. It's no more complex than that.
Q1) The issue here is that once you got into the folders that represent your package hierarchy, you set that as the working directory. It's gonna look inside of org/processing/Adder for the path org/processing/Adder (essentially looking from the root for org/processing/Adder/org/processing/Adder). You need to call it from the root with the full path. The purpose of packages is A: to organize related classes into groups. And B: Along with A, classes in package Foo.bar can't view private classes in other packages, as they are like internal classes for that package, only the package they're in can use them
Q2) Yes
Q3) The paths are used as a basic structure for the JVM to know where exactly the class files (each containing their bytecode) are. If you change where you call it from, your basically trying to change the location for the JVM to look for the class files, but their true location hasn't changed.
The short answer - Packages help keep your project structure well-organized, allow you to reuse names (try having two classes named Account), and are a general convention for very large projects. They're nothing more than folder structures, but why they're used can burn beginners pretty badly. Funnily enough, with a project less than 5 classes, you probably won't need it.
What, exactly is this line doing? Why is there, what's it's role.
The line
package org.processing
is telling Java that this class file lives in a folder called /org/processing. This allows you to have a class which is fully defined as org.processing.Processor here, and in another folder - let's say /org/account/processing, you can have a class that's fully defined as org.account.processing.Processor. Yes, both use the same name, but they won't collide - they're in different packages. If you do decide to use them in the same class, you would have to be explicit about which one you want to use, either through the use of either import statements or the fully qualified object name.
Does this mean that compilation is always relative to directory structure?
Yes. Java and most other languages have a concept known as a classpath. Anything on this classpath can be compiled and run, and by default, the current directory you're in is on the classpath for compilation and execution. To place other files on the classpath, you would have to use another command-line invocation to your compilation:
javac -sourcepath /path/to/source MainClass.java
...and this would compile everything in your source path to your current directory, neatly organized in the folder structure specified by your package statements.
To run them, as you've already established, you would need to include the compiled source in your classpath, and then execute via the fully qualified object name:
java -cp /path/to/source org.main.MainClass
Why is all this the way it is?
Like I said before, this is mostly useful for very large projects, or projects that involve a lot of other classes and demand structure/organization, such as Android. It does a few things:
It keeps source organized in an easy-to-locate structure. You don't have objects scattered all over the place.
It keeps the scope of your objects clear. If I had a package named org.music.db, then it's pretty clear that I'm messing with objects that deal with the database and persistence. If I had a package named org.music.gui, then it's clear that this package deals with the presentation side. This can help when you want to create a new feature, or update/refactor an existing one; you can remember what it does, but you can't recall its name exactly.
It allows you to have objects with the same name. There is more than one type of Map out there, and if you're using projects that pull that in, you'd want to be able to specify which Map you get - again, accomplished through either imports or the fully qualified object name.
For Q1: The package declaration allows you to guarantee that your class will never be mistaken for another class with the same name. This is why most programmers put their company's name in the package; it's unlikely that there will be a conflict.
For Q2: There is a one-to-one correspondence between the package structure and the directory structure. The short of it is that directories and packages must be the same, excepting the package is usually rooted under a folder called src.
For Q3: Once it's compiled, the class files will probably be in the appropriate folders in a jar file. Your ant or maven tasks will build the jar file so you won't really have to bother with it beyond getting the ant task set up the first time.
I want to add some class files to rt.jar. How am I able to do that?
Your question indicates you have some misunderstanding of the java platform.
First of all you need to know what the rt.jar is and what it does:
rt.jar is the jar that contains all the classes necessary for the java runtime. Hence it's name rt.jar
Now that you know that, you need to know how your java program runs:
Your java program, all your jars and classes are executed by the java virtual machine.
So as you can see the code you write & the rt.jar which is used by the java run time are completely separate and should remain so.
If you need some functionality you should add it to your jar.
Do not update it. Why do you want to update it?
Well anyhow if you want to update it, I know one way, You can open jar file in winrar and paste updated .class files in archive. But your jar may get in inconsistent state. Do it at your own risk.
You can use this command:
jar uf jar-file input-file(s)
Refer the link for details:
java.sun.com/docs/books/tutorial/deployment/jar/update.html
The best way to update the rt.jar is to install a newer version for Java. ;)
If you want to add your own classes in new packages, you can add these to a jar which is in your class path. This is preferable to changing existing classes.
If the only option is to change existing classes, you can create a "patch" in a jar which you prepend to your boot class path, or you can add the jar to an lib/endorsed directory. I wouldn't do this for production code, only for your own testing.
I've tried jar.exe with the u and 0 (i.e. zero) options and that gets the closest to looking like the original rt.jar file but if I've updated the JDK's JRE's rt.jar I have problems with compiling and jarring after the update. No idea why! Simply running a program with the JRE seems to work.
I also tried -Xbootclasspath/p but couldn't get it to work.
Looking at Replace a class within the Java class library with a custom version I see that there are legal problems with distributing an altered rt.jar to your customers, even if you could figure out how to do it correctly. So I plan to take the advice in that page and create a java agent. That's apparently legal and works.
One reason a person might want to modify rt.jar is to add debugging information after compiling the source that comes with the JDK with the -g option. One may also want to patch something. These would be for one's own use, of course.
I'm writing a custom tool to build jar files from our build tree. We like to build "minimal" jar files that contain only the .class files actually referenced from the "root" class (where main() lives) -- and so on, recursively following dependencies.
Historically we have done this by getting javac to follow source dependencies, but that means recompiling common files many many times. (We build 60 or 70 distinct application jars from a single source tree.) I'm writing a new build system that compiles each source file only once, but that means we need to follow dependencies by parsing .class files.
The good news is, I've got working code that does what I want. But I need to be absolutely sure I didn't screw it up, i.e. I want to ensure that I'm building internally consistent jar files, where "consistent" means that all unresolved references can be resolved with one of our known third-party jars.
So ideally I want a MagicTool that I can run like
MagicTool \
--classpath commons-lang.jar:commons-collections.jar:[...etc...] \
myapp.jar
that will examine every unresolved reference inside myapp.jar and make sure that it can be resolved by one of the third-party jars passed to --classpath. If not, barf.
Better hope nothing in that path includes any sort of reflection, forName, etc.
I use depfind (if I'm not using my own Java spelunking tools) which may or may not provide output in a way that's helpful for you. jdepend is another option, although I've never used it for anything other than package-level dependencies.
Other tools like ProGuard will strip out unused classes (amongst other things), with the same reflective caveats.
I'm very wary of trying too hard to create minimal jar files; there's a point of diminishing returns/increased risk.
I am pretty sure that ProGuard is your magic tool, even if I don't now the exact call syntax.
At one stage some years ago, trying to index a JAR file with jar -i made it throw an exception if there were unresolved dependencies. I can't quickly test the current state of things.
we have downloaded jar files for lambdaj and its dependencies which are again jar files.
we do not know how to go about it. we have copied these files in the
C:\Program Files\Java\jre6\lib\ext
have set the class path in environment variales as:
variable: classpath
path: C:\Program Files\Java\jre6\lib\ext
but we do not know how to go further. we want to run some lambdaj programs.
can anyone suggest how to run lambdaj programs?
You would run a Java program that requires lambdaj in exactly the same way you'd run any other java program with an external dependency, i.e. by invoking the java executable passing in the fully-qualified name of the Main class, or the JAR with an appropriate manifest, or by deploying it in a servlet container, etc. Additionally you should be putting the LambdaJ JAR on the classpath for this invocation, not in the lib folder for your entire JVM.
What have you tried so far and why/how is it not working? Your question at the moment is a bit analogous to "I want to use Microsoft Word to view some Word documents, how do I do this?".
Update for comment 1: You said "it's not working". That doesn't help anyone address your problem as it gives no clue what you expected to happen and what you observed, only that they were different. As for where JAR files can be stored - you can put them in any directory, so long as that directory is on the classpath (or you add it to the classpath) of the Java application that runs. The canonical place to put external dependencies is in a folder called lib below the root of your project, but the important thing is that you choose somewhere consistent and sensible.
It sounds like you don't quite grok Java and classpaths yet. If you have followed some tutorials and are still stuck, ask for help to let you understand. Adding more detail to your question, including the layout of your files, the commands you issued, and the response that came back would be useful too.
If you are using Netbeans create a project and right click on the Libraries folder within the desired project. Click Add JAR/Folder...