Develop Reference

is there a way to make changes in jar which doesnot have source code in it and rebuild it as a jar in eclipse?

Is there a way to make changes in jar which doesnot have source code in it and rebuild it with this change as a jar in eclipse.

You can look into using Java decompilers; in order to turn the .class files within the JAR archive back into .java source code. The process and some tools for that are outlined here.
But: understand that *decompiling" can be a tough business! Plus: there is always the question if the licence terms of the library you are using allows you to do that. Being able to do something isn't the same as being allowed to do that!
Finally: keep in mind that a JAR is just a deployment artifact. A lot of libraries are open source, and you can most often download that source and build the corresponding JARs completely on your own.

how to get java source code from war file?

I do not have the latest source code but have the war(up to date) file deployed on server.
Please suggest the best ways to
1) Retrieve source code from war/ear
2) Compare & Merge/update the available source code with the code present in war/ear but missing in available source code(I am using ECLIPSE IDE)
Thanks in advance

War files are basically zip files, so they are easy to extract. (using unzip or just renaming the file)
Next you could use a Java decompiler like JD.
But you won't get the original Java code as the compiler does a lot of optimization.
But it should give you a good starting point

Once you've extracted the classes from the EAR/WAR/Jars, use JAD to decompile the code you're interested in to get back to the source: http://varaneckas.com/jad/
I'm not sure there's any out-of-the-box tool that is going to compare/diff your original source with the decompiled source produced from something like JAD though. Also bear in mind, decompiling classes back to source is not going to produce source that looks identical to the original source - code style is going to be different, maybe even some structure of the code. It's going to be difficult to do a diff between the original source and decompiled source.
If you have the original source but not the source for the code that is currently deployed, maybe a better question is to ask 'why not'? If there's something missing in your build process where you are not tracking what source is being used for each build, maybe this is an easier issue to address moving forward, rather than trying to do something clumsy and error prone like a diff between some other source and decompiled source?

The exact answer: it is not possible to get the original source code (.java files) from a war as opposed to a jar (java archive). When you create a jar file, you can decide if you want to include the .java files. Only a java decompiler can help, see the other answers.

Using JD GUI you can the source code with java code, but you'll need to

Inside the war folder, under specific module - Based on your project hierarchy (if maven project -these config will be available in Pom.xml - it will define which path and what jar name)
you will have the Core JAR files of each module.
Open those jar files using any decompiler , you will be able to find the class/java files in it..

Here is your complete solution.
If while creating war file, you have to make sure that you have added the code.
Otherwise, do one thing.
Deploy the war file in your server, may be on tomcat server.
To deploy the war file, you need to put that war file in webapps folder (C:\ASHIS_CODE\apache-tomcat-9.0.65\webapps).
enter image description here
After putting, you need to restart your tomcat server.
Then one folder with same name as of your war file name, will be created in side webapps folder.
Open that folder in your eclipse or any other ide, that folder contains your project code.
** Hope this clears your issue.

Location of generated source files for maven directory structure

Besides src/main/java folder, we have one folder that contains some generated java sources that are required for the main sources. Code generation is invoked manually, when needed. Generated source is checked into the source repo. Everything will be built and packed together.
What would be the best location for generated java sources that are going to be compiled together with main sources? Should it be:
/src/generated/java (following the same naming logic for src/testInt/java for integration tests)
/generated-src/main/java (in collision with "The src directory contains all of the source material for building the project")
/src/main/generated-java (well... generated-java is not a type)
...?
The first option seems like the most appropriate one for this case. What do you think? Is there anything in Maven docs that describes this situation (that I have overlooked)? Do you know any repo with similar structure?
Thank you.
Answer
As suggested by #Absurd-Mind, direction we are thinking about is to split the source into the submodules (which works nice in gradle). So, the generated source and some other related source will go into its own submodule (they will produce the separate artifact) and the rest will go in other submodule, that uses this one. Thank you.

I think the location depends on how the source is generated and handled.
The source code is generated automatically during the build process: Then i would use target/main/java/, target/test/java/ and so on. This code is not checked in into CVS since you can rebuild it fairly easy. In case you clean your project the target directory will be removed and the source will be rebuild.
The source code is generated manually by an external tool or similar: I would use generated/src/main/java/, generated/src/test/java/, generated/src/main/resources/ and so on. This code should be checked in. A benefit is, as soon you see that the top-level directory name is generated you know that all files/directories below are also generated. Also you have the standard maven directory structure under the top-level directory. Another point is that clean-up is easy, just delete generated and recreate it, without looking through many other directories (like in your example: src/main/generated-java and src/test/generated-java).
EDIT: Another nice solution would be to create a maven project which only contains the generated source like myproject-generated-1.0.3.jar. This project would be a dependency in your real application. Then you would just put your generated source int src/main/java.

As much as i know there is no standard folder structure for generated sources. In my projects, i prefer src/gen/java kind of notation.

I totally agree with the accepted answer. I just want to offer a slightly different suggestion for naming the directory that contains code generated by third-party tools:
src-gen/main/java
Background: In the Eclipse/Maven Tycho world (where code/resource generation often plays a large role) there is the src-gen directory for generated code, which has been established as some kind of standard convention. (the default project layout is a bit different compared to Maven, as all source files are directly in src and src-gen).
In a Maven project that could be translated for example to src-gen/main/java, src-gen/main/resources, src-gen/test/java, src-gen/test/resources. I like that more than moving everything into a "generated" directory, because
Sources in src/main/javaand src-gen/main/java are on the same depth in the directory tree
It's more clear that src-gen contains generated sources/resources that contribute to the build. On the other hand a folder just named "generated" dosn't tell you much about its content. It could contain anything, like generated documentation or generated test data or it could be just a temporary folder.
All the mentioned advantages of generated/src/main/java still apply (e.g. easy cleanup)
After a quick google search it looks like there are already projects on Github that use this pattern
Some thoughts/opinions about the other suggestions from the question:
Instead of /src/main/generated-java I would probably rather go with something like /src/main/java-gen which, when sorting directories alphabetically, keeps generated and regular code next to each other (<lang>-gen is also another pattern already used in Eclipse projects)
In my opinion gen fits in with the brief official names like src, it etc. more than generated. I've already seen src/gen/java a few times in the wild and have the feeling it is a more common than /src/generated/java. On the other hand some Maven plugins use the quite verbose target/generated-sources/<lang> directory, so generated-sources/main/java could also be an option if your not into short names...
Ultimately I think the naming doesn't matter that much and it is up to your preference since none of this is "official" convention.

NetBeans adopted <project>/target/generated-sources/<tool> as the location for generated code. As a result you would see an extra leaf appear in your project tree named as Generated Sources (<tool>), and source code will be navigable and not show up with compiler errors in the markup.
So if you commit your code, it will not be under the /target directory, and you will have to setup your maven project for the additional Source Code locations. Otherwise, I will suggest to keep with that adopted standard and put things under <project>/target/generated-sources/<tool>.

In Maven project source file store inside src/main/java , src/main/resources and test class store inside src/test/java.
In Maven generated code (Compile code) stored into target/ folder.
When you build your Maven project, all generated code to be updated in target folder.

Usage of a Diff library

I need a diff library for my project. This is exactly what i need: http://code.google.com/p/google-diff-match-patch/
But when i download the file it doesnt come with a jar file. There are source codes in it and i'm not quite sure how to add this into my application. Anyone knows how to use this in an application? I really appreciate an answer.

The only thing you need to add to your application is the diff_match_patch.java file. (Make sure its license is appropriate for your code.)
It doesn't have any dependencies so you can simply compile it with javac diff_match_path.java.
The diff_match_patch_test.java uses the API (obviously) so you can look in there to see examples of how to use it/what to expect. (The test class depends on jUnit.)

If you want to separate it and put under your lib/ folder, then create a new Eclipse project, copy diff_match_patch.java to src folder (with package name of course), then use
File->Export->JAR
feature of Eclipse. By this way you can have this file as a JAR archive. This will provide a neat way to keep dependencies organized.

Java Class file from SVN to Tomcat on server: How to compile automatically?

I'm currently fixing a JSP project and it currently has a seemingly random collection of .class files in it's Tomcat's WEB-INF folder. As a way of simplifying this, I was planning to get .java files from these classes straight from SVN to WEB-INF folder on server and I got that to work but what would be the simplest way of compiling these? Of course I could create a cronjob which would compile all the classes during the night but it seems like a bit of hassle.
I know that our project management is a bit f*cked up and the correct of deploying applications on to a server would probably be to use WAR files. I'm trying to fix this in small incremental steps because the project is quite large and in use all the time.

Tomcat only compiles the .jsp files, so you'll have to do the compile the .java files yourself, one way or another.
Most robust solution would be to create an ant task that built a .war file for the entire project and then pushed that to Tomcat (or use Maven2 to achieve same). While that will require some work now, it will save you a ton of effort in the long run.

You might consider building a jar file from the *.java files on your build/dev box, then pushing that jar file to the server. Storing class files in VCS is a really bad idea.
Another approach might be to do the following
Assuming:
/opt/apache-tomcat/
Holds your app server, create something like this:
/opt/build/
Check out your files into the build directory then use one or more scripts to copy
/opt/build/my-app/ -->
/opt/apache-tomcat/webapps/my-app/
Once you have that kind of working, try to get a repeatable (and verifiable) build working. Ideally a war file.