Develop Reference

IntelliJ IDEA - Decompiling/Editing/Recompiling JAR

I realize this may seem like a completely stupid question and this question is a "wall of text", but I'm feeling like I've gotten way out of my depth here and need some guidance. I've read several SO questions on this topic, but still can't seem to find one that addresses this particular situation. (please reference update(s) at the end of this post)
BACKGROUND
Our company has an application that was built in Java and released as an executable JAR package by a developer who passed away a couple of years ago. Since then, there has been minimal need for even looking at that code, let alone making any changes. That's been really good because I do my programming in VB.NET (Visual Studio) and, while I can read and make sense of Java code, I'm not proficient in actually writing/debugging that code.
However, a recent issue has come up that forced me to try to take a look at this Java code due to some internal changes in organization and data structure. I've looked in his "src\" directory and found older versions of his original code but wasn't able to find the most recent version anywhere. I found some code that made it possible for me to extract the JAR that's currently being used to a local directory on CodeProject (JarsVB), so I've been able to look over some of the .java files when trying to figure out what query is being used for some random operation. I don't know what tool(s) the original developer used to create the project/JAR, so I've installed the IntelliJ IDEA Community Edition 2018 as an IDE, and it's worked for me so far to simply view the code so I can understand a bit about what it's doing.
PROBLEM/GOALS
Unfortunately, now there is a need for me to make a change to the Java code and update the JAR, and this is where I can't seem to make heads or tails of what I need to do. I have my local copy of the code from the "unzipped" JAR containing all the .java and .class files (along with all the other resources), but I'm not sure how to go from that to modifying the code and recompiling the executable JAR.
So, my goals here are as follows:
(properly) Decompile the existing executable JAR. (If the JarsVB solution I mentioned above did what it was supposed to do, I should already have this part handled, but if there's a better, more "integrated" way of doing it, I'd be open to that as well.)
Modify one or more .java files. (I believe I can figure out the syntax well enough to get this part done.)
Debug/test my changes.
Recompile the changes into an updated executable JAR for release. (THIS is where I'm experiencing the most confusion.)
WHAT I'VE DONE
I've been looking at the documentation for IntelliJ to try to figure out how to make this all happen, but I feel like I'm missing stuff. I set my "Project Structure" settings to point to a specific folder, but I can't seem to get it to actually build anything in my specified path.
I went into one of the .java files and made/saved a small change to test, then went to the Build menu and tried all the building options available to me: "Build Project", "Build Module", and "Rebuild Project". Each time, the event log shows that "All files are up-to-date" (even though I changed one), so I go to my output directory to see what it built, but the folder is empty.
I looked at the IntelliJ documentation for Packaging a Module into a JAR File, which says to
On the main menu, choose Build | Build Artifact
But that option is disabled in my Build menu, and when I look in the Project Structure dialog, the Artifacts section is empty, so I try to add a new setting (Add -> JAR -> From modules with dependencies...), but I'm not sure how to properly set that up either.
I tried to select a Main Class from my classes/ directory, but it wouldn't actually accept any of the .class files I selected, so I just left it blank. Then, I did a search for a MANIFEST file, but couldn't find one anywhere so I left that blank as well. The Build menu option is enabled now, but when I tried to Build Artifact, again, I get nothing in my output directory. In fact, the only files I can find that have changed are in my local working directory. I'm just dumbfounded at this point.
FINAL THOUGHTS/QUESTIONS
I've tried to provide as much detail here as I could think of about all the things I've tried and gone through to get this JAR updated, but if there's a question about anything, please let me know. I'm not looking for a "handout" and I don't expect anyone to do this for me, but I'm also not wanting to become a Java developer just for the sake of making some minor changes to an application that will eventually be replaced by a .NET application. I simply am not familiar enough with the tools or Java development in general to know how to get to where I want to be from where I am.
My decompiled source files are in a totally separate directory from the original, production JAR file because, when I recompile this time, I want to completely recreate the JAR. Am I understanding the Java development process correctly in editing one of the .java files I got from decompiling with the JarsVB and then recompiling the JAR?
Thanks in advance for any assistance in finding the resources I need to accomplish these goals.
EDIT/UPDATE
So, looking at the link in the accepted answer in another SO question, How to build jars from IntelliJ properly?, I figured out at least one part of my issue: Leaving the Main Class setting of my Artifacts configuration blank was a problem. Since I hadn't been able to select a .class file and I wasn't sure how to correctly populate that field, I hadn't given the IDE enough information to operate correctly. I entered the namespace and class (namespace.class) I found in the class file that apparently defines the main method for the application, then set the path for the MANIFISET.MF file to my output directory and tried again to Build Artifact.
This time, at least, it DID produce a JAR in my defined output directory, but it's only 1KB in size. As stated above, the source files are in a completely separate directory from the original JAR file from which they were decompiled. The output directory, too, is completely separate from the location of the original JAR file. Do I need a copy of the original JAR file in the output path for recompiling to work correctly?
I'm making progress, but I'm sure I'm overlooking something "stupid" at this point that's primarily due to my unfamiliarity with the IDE and developing Java applications in general.
UPDATE 2
Looking at another SO question - how to create jar of java package in intelliJ idea - I learned that I have to individually add the necessary files for repackaging into the JAR. However, this brings up the question, what files do I add? The linked question identifies the .class files, but when I go look at the .class files in my working directory, none of those have been updated recently, so it looks like I'm still missing a step somewhere.
Another question this brings up is, are there certain conventions for Java development of which I need to be aware when preparing my environment? I have my output path set to a completely separate folder than any working or production code, so I'm wondering if something in that setup might potentially cause issues.
As I said before, I made a small change to one of the .java files, then tried both the Build Module and Rebuild Project options, but those are still telling me that "All files are up-to-date". Even so, I tried adding just the .class files from under my classes\ directory to my Artifact configuration and tried again to Build Artifact. I got a bit larger file (approx. 5MB), but when I try to execute the JAR, it just doesn't appear to do anything, let alone actually launch the application.
I tried again by adding the root folder of my local copy of the source adding everything the root folder contains. (yes, the directory probably needs some "spring cleaning", but that's for another day)
This time, I got a much larger file this time (approx. 21MB), so I thought I might have fixed the problem. Unfortunately, no such luck. The JAR still doesn't appear to execute.
For reference, the original JAR file from which the code was decompiled is approx. 59MB in size so, either IntelliJ is doing an incredible job with compression, or there's yet another step I haven't yet found. I'm sure this is all a matter of getting my IDE configured correctly, but I just can't seem to find the right combination of settings.

How to step onto/debug imported java code in netbeans

I have been searching for a long time on how to step through imported code classes in netbeans with no solution.
When debugging or stepping into the code, netbeans does not highlight and stop at the imported code classes being used. This is extremely inconvenient since the code I am working on is complex and stepping through is the only way to fully understand it.
I created a new project with existing sources. I have made sure that under window>debugging>sources I have added my working folders.
I also made sure the sources were added in the "runtime" classpath.
The compile classpath appears to be empty, I'm not sure whether that has something to do with it.
MORE INFO: In the debugging window while the program is paused, the main method profile from my imported class says it is reading from "Hidden source calls", but it is really just the normal imported code.
Why is this happening? Can anyone please help?

Folks,
One of the reasons you can get Hidden Source calls is adding in existing packages and java source code at the wrong directory level. You MUST add in the parent directory of the package not the child directory that represent the package name,
example if you have /home/torsi/java/src/torsipackage/com/main.java, you need to add in src, not torsipackage, you will now you made this mistake if you see listed in the top-level package name for your package.
Tom

Well I've not heard the term "Hidden source calls" before but I wonder if you're trying to step into third party code? If you want to step into compiled code it must have source associated I believe. I think it's possible to step into native code because they include the source somehow in the distribution for that exact reason. If you want to step into a library that's been developed by some other private entity you will likely not be afforded that luxury unless it's open source, and even then you may have to retrieve the source first.
Ultimately my point is that there is a difference between a .java file and a .class file. I believe it's possible to reverse engineer .class files but haven't done research on the topic.
If you want to step into code you didn't write odds are you'll need to change your code to work with the imported library or alternatively file a bug report with the developer.

Create sources jar for shrunk classes in a module via proguard

There is a business module - say kilo-business in one of the applications. Now there are some APIs in this module that is to be used by another application (locally within the organization - say kilo-client1). I have used Proguard (via its maven plugin) to only extract the classes relevant to the API and make a JAR out of it - the shrunk API JAR called kilo-business-apis. kilo-client1 uses this kilo-business-apis dependency and invokes the service. As a policy, we always include sources along with any artifact that we share between applications (for debugging ease and additional documentation).
In this case, is there a way that one can have Proguard also give out the (probable) source files (belonging to kilo-business module) from where it has sourced the classes for the kilo-business-apis using which a sources JAR can be conjured? Actually, we don't shrink the JAR to the extent of removing unused methods/variables from the class, so giving out the source java files would also suffice.
I understand that one can use jd-eclipse or some other decompiler in eclipse to aid debugging even if we don't publish it, but wanted to check if we can generate the sources first class whereby documentation needs are also addressed.
One thought is to break up kilo-business itself into a separate module for kilo-business-apis where only the API definitions reside and both kilo-business and kilo-client1 can use it, but unfortunately I can't do it for legacy reasons.
Thanks in advance!

ProGuard optionally writes out information about kept entry points (-printseeds), unused code (-printusage), and obfuscation mapping (-printmapping), but nothing related to source files. If you don't obfuscate the code, you can simply list the .class names in the processed output, and find the corresponding .java files.

How to purge unused source/class files from Directory tree

We have about 280 Java source code spread over 10 packages, and a bunch of txt and image files for a software project. Quite a few of them are not being used currently. They do not break the system, since we can just do a "javac //*.java" and "jar cmf metafile " to build up the executable jar which works. The question:
How do we find the class files never accessed, or image/txt files never used as resources in the jar?

It would be very hard to determine which image/txt files are never used, as they can be loaded in a variety of manners. A good bet for the image/txt files is to search for the name of each file in your code; if it is not there, it might not be being used; remember, the name of the file could be being generated programmatically and then loaded.
I recently had to do something similar for a game project. Because content could be brought in via a variety of means, removing unused content took a lot of trial and error.
There are plugins for eclipse that can find unused code.

Use the Unused Code detector: http://www.ucdetector.org/

It has been answered in How to find unused/dead code in java projects.
For the images, I would write a small program, pseudocode would look like:
//list image names
//for each image name
//find ocurrences in other files

Easiest way to manage my CLASSPATH?

I'm beginning to play with Clojure a bit and my Java experience is pretty limited. I'm coming from the dynamic world of Ruby and OO, so the functional side of things is very interesting!
Anyway, as I discover libraries and various tools for use (and the tutorial files for the Pragmatic Clojure Book), everything typically calls for placing files in the CLASSPATH in order for Clojure to see the library for use.
Is there such thing as good CLASSPATH practice? Would I ever want to only have a CLASSPATH with just the external libraries of files I need or can I go ahead toss any library or file I would ever need in a directory and simply define it as my CLASSPATH and only require what's needed?
If it helps, I'm an OSX and Emacs user (Using slime and swank-clojure).

I recommend using leiningen and lein-swank to manage this. You can start a REPL in the directory and connect to it from Emacs.

Personally, I'm using a variant of a clojure-project elisp function by Phil Hagelberg, see source in this post to the Clojure group. It sets up the classpath appropriately for the project you'll be working on, then launches SLIME. (EDIT: You'll need to change the value which gets assigned to swank-clojure-jar-path to point to clojure.jar. I'm using (expand-file-name "~/.clojure/clojure.jar") as the default.)
To answer the question about having everything on the classpath all the time vs only throwing in what's needed: to the best of my knowledge, nothing will actually break if you take the first approach (I know I do that for experimental purposes), but apparently things might break with the first approach (see cjstehno's comment below) and in a proper project I find the second to be cleaner. At some point it'll be necessary to determine what libs are being used (and which versions of them), if only to tell leiningen (or maven) about it -- why not keep tabs on it as you go.

We are using Clojure and use a number of infrastructure tools, especially Eclipse (IDE) (http://en.wikipedia.org/wiki/Eclipse_%28software%29) and maven (http://en.wikipedia.org/wiki/Apache_Maven). maven manages libraries and jar dependencies so if you have a number of these and they are likely to grow start using maven.
In answer to your original question you can just put your jars in one directory and you can access them by name every time you run. But you will benefit from the tools...
If you are just exploring then Eclipse will probably manage your jar files fairly painlessly. You can add these to the project as required through the Build Path -> Configure Build Path option.
As your work progresses you will possibly wish to split it into Projects which Eclipse supports so you can add your (or other projects) to your Build Path.
If you use external Clojure libraries look to see if they have been packaged as maven projects (they will have a pom.xml file). The POM will give a list of dependencies.
#

The usual CLASSPATH practice for Java is to put only the jar files needed for a project into this projects class path, which means to have potentially different class paths for diffent projects. This is usually managed by the IDE as part of it's project properties.
Since you are using Emacs and thus probably don't have or use something like projects it might be more convinient for you to set up and use a single global class path for all your clojure related stuff or maybe even simply put all the needed jar files into the java2se/jre/lib/ext directory of your java installation.
The two main problems that could arise from having unneded jar files in your class path are: 1. it has a minor negative impact on the start up time of the JVM and 2. it becomes more difficult to make sure that you are not having classes with different versions in the same class path (i.e. different classes with the same package and name in different jar files).

Since Java SE 1.6 (or JDK 1.6) you can include class path entries by wildcard. If your class files live in .\bin, and your library jar files live in .\lib, then on Windows you could define your class path like this:
set CLASSPATH=bin;lib\*;
This will let you add jar files into the .\lib directory and they will automatically be added to the class path for new instances of the JRE.
See this link for details: Setting the class path
Prior to JDK 1.6 you had to add each jar file onto the ClassPath individually.

I just discovered this bit which I need to give a shot:
(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))

clojure-contrib/launchers/bash/clj-env-dir has an interesting property that you can point it at a directory and it will basically include anything in there. In the past I've had a ~/classpath directory which I would dump any jars into and link any commonly used directories and it worked great. Very simple way to dump and use. Now I tend to use Maven clojure-maven-plugin and that works well also though can be a bit tedious when you just want to muck around with some ideas.