I am dealing with a peculiar issue.
After spying on a Java GUI that I have made (this might be important or it might not!), I am able to highlight correctly the components of the window.
But when I close the window and then open it again, it fails twice to highlight any component and then it highlights them correctly from that point on.
In order to spy on the elements I have used the Java Mode (I assume that this based on the Java Access Bridge).
Also, when I try to Open Application Navigator, but that also failed, although I have pasted the related files from the java access bridge.
It is really weird and there seems to be no easy answer for my problem.
This is not something specific to Java, and is observed for many applications. Check whether the application needs to load some data from a backend server to function properly. The UI elements of the application might get loaded quickly, however some their attributes might still be loading from a backend server, and until it is full loaded the attributes would not match with the values you captured.
Related
I want to display a HTML file in my java GUI.
Big problem: this java program has to run on Raspbian (Raspberry Pi).
I used the browser from eclipse swt which worked perfectly on my PC, but there is no swt build for the ARM processor on my RPI...
A JEditorPane is too weak, because I need to display some pages with CSS
Is there any other possibility?
The easiest solution is of course to see of JavaFX is supported on Raspbian. If it is, then you can use the WebView component (http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm) and most of your problems will be solved. As pointed out in the comments below by jewelsea, this is not a feasible solution yet. This might change with future builds of JavaFX for Raspbian though, so keep an eye on it.
If, for some reason, JavaFX won't work (due to display drivers etc.) then you might want to reconsider your application approach. If you just need to display the HTML file, then you can write it out to disk and display it in the default system browser. If you need to interact with it, it becomes a bit more complicated - you'd basically write a small web server and then respond to user interaction that way. The user will be using their browser of choice, and you'll send responses back to it.
Say that we are writing a Java Swing application and we use Eclipse or MyEclipse to develop it. In web applications, you make code changes, you save and your ant deployment file takes care of the deployment of the changed files. Then you just refresh or hard refresh the web page and the changes appear there. Can we do the same thing for a Swing applications so that we don't have to close and open the program from the beginning every time we make a change?
I don't think so because you need hot code replacement ! Maybee using another framework.
You can't simply do that because once JVM is started, it loads the class files once and will not reload it untill next loading request. But you can use ClassLoader to load modified class files dynamically.
The following two articles may help:
IBM article on "hot class swap"
"Who Said Runtime Class Reloading Is Hard in Java?"
The first one is in Chinese, but you can look at the code and the result. I think the second article is more helpful for a GUI application.
In MyEclipse you can start your application in debug mode instead of run mode and changes you make will be pushed to the target VM; if changes you make cannot be replaced you'll see a dialog informing you the replace failed and you will need to restart your application. You don't need to place any breakpoints in the application, just starting in debug mode is sufficient.
As Guillaume states above, changes to the class structure will typically not be hot-synched, but changes within existing methods should be fine.
Obviously, how successfully hot-synched changes affect your running application would depend on your application design.
I'm working with a legacy Java app that is new to me so one way to figure out how it works and find things easier, I have thought would be to be able to get the full stack trace after I perform actions, so as to be able to see which classes are being used based on a particular UI action. I had thought this was possible in the debugger but it seems that it only works if I insert a breakpoint and in this case part of the purpose of this is so that I don't have to know what's being called to be able to insert the breakpoint first (as this would help tell me that).
I apologize if this is a basic question, I have searched on this but I'm not finding the correct answer.
This doesn't directly answer your question, but maybe it will solve your problem better. Take a look at BTrace. It lets you instrument a running Java app and insert some basic code of your own. You could, for instance, have it write out entire method call chains to help you find your way through the app. It's somewhat similar to AspectJ, but with an entirely different purpose and requiring no change in the project source:
"BTrace is a safe, dynamic tracing tool for Java. BTrace works by dynamically (bytecode) instrumenting classes of a running Java program. BTrace inserts tracing actions into the classes of a running Java program and hotswaps the traced program classes."
A few suggestions:
Some profilers will allow you to walk from any particular method up (and sometimes down) to see what's calling and being called. I've found this surprising informative about flow, even in apps I thought I knew well.
For understanding the mainline flow, I don't think there's a better substitute for working interactively with a debugger. It will lead you into learning other important things. Not what you wanted to hear, I know. This presumes that you can rapidly restart the app when you miss a key off-ramp.
Reverse-designing large legacy apps is the one place where I use UML fairly regularly. There's too much to keep in my head to form a good big picture. If you have a UML tool that will do reverse-engineering, load it up with the app, then probably prune down hard on the classes you don't care about, because they are trivial or obvious. Arrange the diagrams in a way that helps you understand. I've used Together, Magic Draw, and Visual Paradigm in this way. Together worked the best - but it was a decade ago.
When you are in the debugger perspective, you will see a view showing the launched processes. In that view you can tell it to pause all threads of a process. Once stopped, you will be able to browse through threads to see what they are all doing. To try to catch what a particular action is doing, you would have to start the action and then quickly pause all threads.
You could always run the application with the VM arg of -verbose:class. You could then watch the console output and see what classes the VM is loading when you perform a particular action. This could possibly give you a starting place for where to place breakpoints. This won't always work depending on the scenario, but may be helpful.
Another trick you can use is to figure what classes you know that have to be involved in the code path you are trying to trap. For instance, you mentioned that it's a Java EE web app and therefore the action is likely some kind of a servlet interaction (at some level). I don't have the API in front of me, but you can place a breakpoint on the method in the response object where the output stream is retrieved. Once that breaks, you will know the code that's trying to service the request.
You can always see where a method is called by clicking "Open Call Hierarchy" from eclipse (left click on the selected method or CTRL+ALT+H ). Also, you always can inspect where a method/class is defined by clicking "Open Declaration" (left click on the selected method/class or F3).
I'm creating a Win32 application that controls another application which is coded in Java using AWT components. I figured that if I can retrieve the main List of the application and cast it with the JLIB library I'd be able to read its content.
First of all, am I right or I won't be able to get the real content of the List ? If I'm right I'd like to know how to achieve this since I didn't found any good spy software for Java and Spy++ only show a SunAwtComponent. Which I presume in the container for the whole Java application.
I'm not expecting someone to tell me how to do the whole thing but only a couple of direction would be really great since I've been looking for that for a while now.
Thanks for the replies !!!
Quite likely the Java application actually uses Swing, not AWT. Swing draws its own widgets on top of a single AWTComponent, so the list widget that you see doesn't exist from Windows point of view.
I assume you cannot modify this Java application so that it can be controlled over some reasonable API (e.g. JMX or REST)?
You can try running the JVM with JPDA debugging interface enabled. You can then use JPDA APIs to change data structures and directly call methods on any object in that program. Finding the right ones to call will be hard, though.
See http://download.oracle.com/javase/6/docs/jdk/api/jpda/jdi/index.html
Is there an equivalent for Spy++ for java swing applications?
I work with a third party application that contains a huge number of screens that get invoked via a reflection based mechanism.
Whenever an issue occurs the only way to locate the problem code is to search through the source (we have access to the source but cannot fix and deploy due to contractual obligations) for a specific string sequence that occurs on the window in question. eg if I see the string "XYZ" on the buggy window I have to search against the source for that string to locate the java file in which the bug exists.
Is there a tool that will let me, at runtime, point to a Swing screen and return the class from which the screen is generated?
Have you tried using Swing Explorer? It is more or less meant for similar tasks. I'm unaware of whether it will display the actual class that contains the component, but it certainly is capable of displaying the component hierarchy. You might want to check the ability to obtain the addition trace which contains the stack trace of the events leading to the component's addition to the tree.