This is a bit technical, and follows on from Using Nailgun in Eclipse for Java and Jython.
I have found out how to get Nailgun to work OK in on a Windows OS in Eclipse, using Jython. And using the unittest module.
What is baffling is that sometimes I make a change to a .py file, and sometimes (not always), an older version of this file continues to be run. This can even persist when I close down the Nailgun server, close its window, and start it up again: an old version of a file is being run, which no longer exists.
This feels very much like a cache problem. My understanding is that Jython does not generate .class files usually (although sometimes it does if you import a module??).
But perhaps this is indeed what Nailgun is doing. I have done some searching on my C: drive to see whether this cache location might be easy to locate: no luck.
Essentially I need the ability to tell Nailgun, between app runs, to delete a given .class file from whatever cache arrangement it maintains.
Incidentally, it doesn't matter whether the CLASSPATH elements in question are stipulated in the server's "SET CLASSPATH=..." or using the "ng-cp" option in the ng command line (i.e. in the client).
If all else fails I shall probably have to look into the NG source for inspiration. Gulp.
Related
I'm editing the bytecode in one of my old projects to fix a bug, because I no longer have the source code. Everything was fine and dandy until I went to re-insert the modified class.
The code was obfuscated when we released it, so I have two files: hl.class and hL.class. hl.class is the one I'm re-inserting, but using WinRAR causes hl.class to just replace hL.class and delete the old hl.class! It's annoying and I can't figure out how to just re-insert the damn file.
Does anyone have any insight? Are there programs that won't be such a diva about this?
Thanks!
In short, use a better zip tool. I'm assuming that you're stuck on Windows, with its case insensitive file system. Even if none of the GUI zip tools work, you can always open up a Python command prompt, which allows programmatic access to zip files, including specifying the exact filename of the content to be inserted.
If you have access to a Linux or Mac machine, it's much simpler. Just edit the file as normal and put it back into the zip. Since hl.class and hL.class have different filenames, there won't be any problem.
P.S. One other option - the Krakatau assembler has an option to output classfiles directly to a jar, allowing you to correctly handle case sensitive filenames even on Windows. Krakatau is also a great tool in general for low level modification of classfiles. (Disclosure, I wrote it)
I actually found the solution the day I posted this, I'm sorry I forgot to respond and post it!
If you're on a Windows machine like me, I found a handy program called muCommander that's a cross platform file manager that isn't case sensitive. I managed to get the file in with it.
There's also some registry values you can tweak to get Windows to recognize case sensitive files, but I'd recommend the program I posted above to keep it simpler.
Thanks everyone!
I made a simple command-line based game in java, only two classes (using Eclipse). But I was wondering how I can make this into a usable application for anyone, without running it through eclipse (ie send it to someone who knows nothing about java but would still be able to play the game)? Thanks!
You want to create a runnable jar file.
Eclipse has an option for this in the "Export" menu. For more options, search for "executable jar file" here or on Google.
You want to make sure that you also include any jar files your code depends on as well (Eclipse can also do that for you).
Users will be able to start this by double-clicking on the file on most platforms. If you need better integration (such as a custom icon), you will need to bundle it up further into an OS-specific executable. But for starters, a simple runnable jar works fine.
send it to someone who knows nothing about java
You need to get them to at least install the Java runtime on their machine (if it is not already there).
Just to be clear, "command-line" and "knows nothing about java" are probably not going to work very well for you given that:
java is OS agnostic, therefore, if you send (presumably) a jar file to say...your grandma and she has a mac and you have a PC chances are her getting it to work is not going to be "out of the box easy" so to speak.
Left with this, I think you have a couple choices...first off, you do need to package your classes - a runnable jar will work fine. Aside from that, you will most likely have to build OS specific scripts (batch scripts for Windows, shell scripts for unix, etc.) and you will have to hand these out with your jar file. That being said, the intended user will still need to have java installed, and the batch scripts themselves are not likely to be trivial endeavors.
Your next option would be to use JNLP. However, I don't think JNLP has a command line mode, so you will likely have to simulate a console with something like a JTextArea.
As far as I see it, your last option it to use one of the many products (not sure if there are any free ones) that package java into native code. I think Exe4j is one such example - but, like I said, I am not sure if there are any free ones and I am not sure how hard they are to use.
Best of luck, and if you can't get your jar to work you should probably move that to its own question.
Please, excuse my complete lack of experience with ANT.
I am looking for a script that basically compares the modification date of every .class file in a given local build, with that of its corresponding copy in a remote directory (server or sth). If a local file has recently been modifed, it just replaces the remote .class file with the local one.
I know that there are a lot of scripts for building war files and redeploying the whole application, and this is clearly what I don't want. Going through that every time for just a few lines of code being changed doesn't make any sense
Even if you can't point out a whole script, please give me some directions to look at. I know that ANT is pretty powerful so something like that should be a piece of cake, for even a newbie to write, right ?
The copy task does exactly that.
I have a jar. I want the jar to be able to make a copy of itself while running. I understand windows may have problems with this. How would I do this, or am I over thinking it?
Edit: To explain a bit more....
I'm writing a repackagable firmware deployment system... http://code.google.com/p/heimdall-one-click/ The idea is that a ROM developer from XDA can make his own, then pack it up in a cross-platform deployable one-click packaging nearly as easily as it is to deploy the firmware.
My program takes alot of the work out by automating the tasks... I'm trying to automate packaging of the one-click deployable packaging system.... give the developers a form to fill out which will change the header information, then they select their firmware files to be deployed. I'm trying to keep it all in one jar.
As josh says, it would be nice if you tell why do you want to do this in order to help.
Answering only what have you post, copying the jar is just copying another file. There is the issue that it might be blocked by the OS (Windows); another issue is how do you locate it in the machine and if the user running the process has the permissions needed.
Once those two issues are solved, it is just a copy operation, the OS could not care less that if the order to copy comes from the process run from the file or from another one.
EDIT to asnwer changes in the first post.
As I told before, in the end copying a file is a OS issue. If you want to copy the current jar in Windows, then the jar must not be locked by other process so it becomes an OS question rather than a Java one.
Possible workarounds:
The faster (but dirtiest) is to launch a .bat that does a sleep of a few seconds and then does the copy. Immediately after launching it, your close your java app. If you need to continue doing things in Java, after copying the file, the .bat launches the java app again (with the appropiate parameters).
A variant of the previous is slightly sleazier... launch your java app from a .bat, and the first thing that .bat does is copying your jar to the PC temp directory. Be sure to document it well so your users do not get scared!
JNI library to unlock a file. There are several programs that (Unlocker) that try to unlock files; do not know to which point it is effective or how will it affect the JVM.
I believe you can use:
File file = new File(MyClass.class.getProtectionDomain().getCodeSource().getLocation().getPath());
to get a reference to the path to the .JAR file.
Then you just make a copy of it:
http://download.oracle.com/javase/tutorial/essential/io/copy.html
Your operating system might not allow this, but I think it should.
This is really driving me crazy. No matter what I do, it seems that Mirth (1.8.2) is running an older version of my JAR file; I know because of various signs, like:
I can't call any functions
Information logged is not showing up in the logs
Changed log messages are not changed in the log files
Files that were once created and written to in code, but no longer touched by code, are still being created and written
I've tried everything I can think of to make this work. It was working at one point, but now it seems like it's no longer being updated. My process to integrate my changes into Mirth are:
Run an ant script to build the JAR file
Copy the JAR file to \lib\custom
Restart the Mirth service (via Mirth administrator)
I've tried restarting (Mirth service via Services, Java, computer) -- to no avail. I know my JAR file is correct, because I've decompiled it (to make sure it has the latest code) and hashed it (to compare to the hash of the ant-built JAR) -- it is correct and the code is there; it's just not being run.
I'm at wit's end; this occurs infrequently but completely blocks me from developing.
Edit: I also know that my code is correct, because when I run unit tests, it generates the right files and calls the right functions and logs the right information. Only Mirth seems to "not get it."
And my classes are very simple; simple one-argument constructors and a few public methods that return various data. Nothing complex, no nested classes/JARs/dependencies.
Edit: I even deleted my custom JAR file and restarted Mirth, and it's still running my code. Awesome :/ I've added a bounty for this question. I suspect the JAR is cached somewhere (even though they deny it on the Mirth forums) and that cache needs to be cleaned out somehow (although why restarting the Mirth service and my PC doesn't do it is beyond me).
I've also killed all instances of Java (and rebooted my computer), so that makes it highly unlikely that the JVM is caching the JAR somewhere.
I tried reinstalling Mirth. For some reason, it had my custom channel when I booted the administrator for the first time; and infuriatingly, it's still running the old JAR, even though I've updated it with the new one in lib\custom.
I ended up solving this with a combination of actions:
Uninstalling Mirth and Java, and then reinstalling.
I also removed all Java installations except one (one JDK and one JRE).
I stopped Mirth when you copying my JAR. Stop Mirth, copy, and restart; don't try to copy on a live installation. It may or may not pick up your updated JAR depending on if it's loaded into a JVM or not.
This combination of steps seemed to work. Prior to this, I had 3-4 JREs installed (and two JDKs) and I was copying (successfully, according to Windows 7) the JARs while Mirth was running. It's working now!
Mirth is a J2EE application running on a plain old JVM; you have options for debugging it.
You could follow the instructions here for running Mirth Connect via Eclipse. You could then see the JVM classpath, you could set breakpoints and use the debugger.
Mirth is based on the Mule ESB. Mule has its own way of class-loading. You could research it.
If Mirth is really using an old version of your JAR, maybe it's got a cached version around somewhere. Or maybe you made some configuration changes you've forgotten about - perhaps you added a new directory for jars. (Not sure how you do that.)
Mule pays attention to an environment variable named MULE_LIB; maybe that's relevant.
It looks like Mirth Connect 1.8 and Mirth Connect 2.0 have different places for jars (lib/custom and custom-lib, respectively). Which version are you using?