anyone have any experience using this?
if so, is it worth while?
I just used jdb for the first time yesterday and am really pleased with the results. You see, I program in Eclipse on my laptop, then deploy to a VM to make sure the whole shebang still works. Very occasionaly, I'll have to work on something that gets executed standalone, as a commandline. These things sometimes need debugging.
This has always been a problem, because I don't want to go to the trouble of installing Eclipse on the VM (it's slow enough already!), yet I don't know of an easy way to get it to connect to my commandline-running class before it finishes running.
jdb to the rescue! It works a treat - small and functional, almost to the point where it is bare... this forces you to apply your mind more than you apply the tool (like I said here).
Make sure to print out the reference (solaris, windows, java 1.5 - I think they're all about the same, really) and have your source code open and browsable on your second screen. I hope you have a second screen, or you'll be alt-tabbing a lot.
Assume your program is started by the following command:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>
You can attach to this process by jdb:
jdb -attach <port>
In some cases you need to use the following command .
jdb -sourcepath \.src -connect com.sun.jdi.SocketAttach:hostname=localhost,port= <port>
JDB is incredibly difficult to use. Placing System.outs or using an IDE debugger will produce better results. And for the more interesting features (e.g. tracking threads, heap size, etc.), you can get the information graphically with the JConsole tool.
Related
I try to run my JAVA application with JVM arguments in Eclipse.
I noticed that a "-noverify" String is appended each time at the end of the parameters, which makes them unusable because I need that as a patch to my config files. (And the program say: "/home/user/config.properties-noverify" isn't exists.)
The arguments are:
-Djava.security.egd=file:/dev/./urandom -Dspring.config.location="/home/sige/guezbin/application.properties" -DconfigPath="/home/sige/eclipse-workspace/ImgCompr/config-default.properties"
I develop under Ubuntu. With Eclipse version 4.8.
I Googled a lot but I didn't find any answers.
Can somebody explain to me what is this and how can I use it in a proper way?
The JVM checks the byte code of the compile classes it is about to load to see that it is well behaved. This is an essential step for executing untrusted code.
Unfortunately this takes time and for a very large application like Eclipse this may increase the startup time quite a bit. The "-noverify" flag turns this off.
It sounds like that you need a space after your own string so the "-noverify" flag is not concatenated. If you cannot do this, then make a work around like "-Dignore" which becomes -Dignore-noverify and then your code should work.
I have an obfuscated Java 8 program and I want to attach a Java agent to it. But when I start it with java -javaagent:intrace-agent.jar -jar program.jar it launches and disattaches from the console after a few seconds, my agent finishes. If I try to see program's command line args in Process Explorer, there's a -XX:+DisableAttachMechanism option (this program adds it during startup somehow). Are there any ways to bypass that?
Thanks in advance!
There's two approaches you can take to get around that:
Modify the program's bytecode to make it not relaunch itself like that.
Get the OpenJDK source, remove the check that makes that option do anything, and then run the program in that environment.
Note that with either of those approaches, the program might end up noticing that you did it and doing something else to foil you.
We have a Java application running on Solaris which makes a connection to Oracle and checks the database for work to perform, and it runs just fine. We tried running the same code on a standalone Fedora system, its performance is good too. However, when we move it to its home on a Fedora VMWare virtual machine, it can take upwards of five minutes for the application to make the connection to the database. It ultimately DOES make the connection - it's just snail-slow. We suspect it's a configuration issue somewhere but can't find it. So far as we can tell, the two Fedora boxes have nearly identical configurations. Has anyone run into this problem before? If so, how did you get around it?
Thanks in advance for your help.
Mike Preston
Found it! When we are running under Solaris, we are running a 32-bit JVM with 32-bit extensions. We are executing through a Korn shell script and had an added -d64 flag to coerce 64-bit processing. On the Linux boxes we removed the -d64 flag from the shell script and everybody's happy. Thanks Alex for your thoughts and assistance.
Here is the solution which settled the issue...our headless development server was only occasionally getting any keyboard activity to fill the entropy pool (please read the article - I won't try to explain it here) and I assume it was blocking until there was enough "noise" to generate the requisite random numbers.Since there is only one other developer working on the system, it might take a couple of minutes to fill the buffer. Once the buffer was full it went ahead and executed the connection as expected. That also explains why we sometimes would see crisp performance followed by slow. In a nutshell, we added the string "-Djava.security.egd=file:///dev/urandom" to the Korn shell script between the call to java and the jar file name and now it works like a champ. Here's the full command string:
/usr/bin/java -Xms64m -Xmx1024m -Djava.security.egd=file:///dev/urandom -jar $1 $2 $PID
If you DO read the article, be sure to read the comments below. One of them is really funny!
I've got a (fairly typical) setup at the moment of launching my Java application through a batch file calling the jar file with appropriate parameters, which most of the time works absolutely fine. However, I'd like to be able to deal with any errors that might occur nicely.
At the moment I've got something like
java -Xms1024m -Xmx1024m -jar Quelea.jar
IF NOT (%ERRORLEVEL% == 0) cscript MessageBox.vbs "Application failed to start."
The last line is basically the first answer on this question.
I'd like something a bit more fully featured though, even if it's a case of capturing the output from launching the process and then dumping it in the message box (ok, it's not pretty but it shouldn't appear to start with and when it does appear that then gives me some immediate debugging information without having to ask the user to grab out log files!) Or are there any other approaches that people use in similar situations?
I'm not talking about exceptions thrown in my code (which I deal with once the application starts) I'm talking about hard errors that prevent it starting such as using an old JRE version, not having enough memory to reserve for heap, that sort of thing.
I suggest using a Java executable wrapper. I like the following, but there are others.
http://launch4j.sourceforge.net/
I find java starts up and runs practically instantly for me - but javac takes a few seconds, and ant makes it slower again. It's only a few seconds, but my edit-compile-test loop would be smoother without it. :-)
BTW: I've already used vim's ":make" with ant.
Is there a way to speed up javac and/or ant? I'm thinking of special switches, or tricks? Or maybe an alternative java compiler (I'm using 1.6, in linux)
Eclipse does that for you ... but it's probably a bit big as a "patch" for your problem.
That aside, you can roll your own compiler plugin. There are two approaches:
Run the java compiler from within ant (instead of creating a new process). Not sure if ant already does that; if not, that will save you a bit of time. Look at the Java 6 compiler API for details.
Run javac in a server process which listens for options on a socket. In ant, send the process the command line and wait for the output to be sent back. Saves you starting a new process all the time.
Try to use the eclipse compiler. Unlike the original javac, the Eclipse compiler is pretty good at "ignoring" errors, so it can produce class files even when they contain errors. That doesn't seem to mean much but it allows you to compile all the time in the background. When you do your last save (wrapping everything up), the compiler will have been able to compile everything else and will just have to look at a single file.
Google found these two (I haven't tried either yet)
javac -J-client -J-Xms100m -J-Xmx100m <src>
JBrownie "monitors Java sourcecode and automatically recompiles any files found changed" along the lines of Aaron Digulla's (2)
I can strongly recommend using a suitable IDE with Java as the productivity increase with using an editor which knows about your program is immense. Think of "goto the line containing the defintion of the variable/class/field the cursor is on", "rename this class and all references to it", and all other kinds of nice things. If you are annoyed with the time it takes to invoke Java, you might be ready :)
You may want to have a look at JavaRebel
I point all of my output files to a ramdisk that I create with this utility. It speeds up builds a fair bit (Though not to a magical extent) since almost everything is in memory. It's most noticeable when doing a 'clean' build which becomes almost instant.