Develop Reference

Using jdb to step inside object construction during execution

I use jdb for my Java development. For my application I have two classes: WordUniverseTest and WordUniverse, and the main method is contained in WordUniverseTest. When I execute WordUniverseTest inside of jdb, I construct a WordUniverse object called obj inside of the main method.
But I do not know how to have jdb leave the WordUniverseTest class and step inside WordUniverse while obj is being constructed. How do I do this?

You can put a regular breakpoint there stop at and then when you are actually on the line (call list to verify), you can call step into.
As long as all your classes are known to jdb, it is going to work, I tested it.

I found the answer, and although Gergely Bacso didn't give the full answer, he did lead me to find the full answer.
jdb uses a different procedure for stepping into methods versus stepping into constructors. To step into a method, you have to do what Gergely Basco said, which is set a breakpoint at where the method is called and then step into. But for stepping into a constructor you must say stop in ClassName.<init> (with brackets). Saying that command will take you inside of the constructor.

Switching to fullscreen crashes application

Introduction
I’m attempting to switch my application from windowed to fullscreen. Earlier this would have been as easy as making use of LibGDX’s setDisplayMode(Display), as well as the same library’s getDesktopDisplayMode(). Unfortunately, some things have changed.
Research
As of LibGDX 1.8.0—inside the Graphics—what was previously known as setDisplayMode(DisplayMode) has been renamed to setFullScreenMode(DisplayMode), as well as what was previously known as getDesktopDisplayMode() has been renamed to getDisplayMode().
By then, one might think, that using the renamed methods in the same way as one previously would to switch from windowed to fullscreen would work just as fine:
// Tabulator key triggers change from windowed to fullscreen
// The application works fine until that of pressing the tabulator key
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
This doesn’t work fine by any means. As a matter of fact, the application hangs followed by crashing upon pressing the tabulator key.
It’s worth to notice that the setFullscreenMode(Display)—according to the documentation—returns a boolean depending on whether or not the operation was successful. In this case, if you were to put it inside a print statement, you can clearly tell it never returns: even should you let the application be for a while.
Moreover
I took a good look around the web—in vain—searching for possible causes of as to why this might be happening. Looking at the release notes of 1.8.0, it truly seems as though all that needs be done is switch from using the previous methods contained by the library to the new ones.
Question
Does anyone have any insight on as to why the application crashes upon pressing the tabulator key—granted the code following it as shown above is present? Perhas someone could at the very least point me in the right direction?
There’s a fair chance what I’ve concluded is missing out on some important facts.

Solution
It turns out I’ve managed to be slightly silly!
Background
Whenever I create applications—especially games—even though I use libraries such as LibGDX, I like to go ahead and create myself a separate thread for handling the game logic. This yields me more control over the application as a whole—whether it be tick extremely frequently whilst rendering more seldom, or the other way around.
By the way of my logic, the provided code from the question...
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
... I decided to put inside the tick method. Since that’s inside a separate thread, LibGDX probably felt a little left out.
Moreover
From my understanding, LibGDX handles all its logic inside the ApplicationAdapter’s render method. That’s where it evaluates all of the user’s actions and makes sure they don’t collide with other things taking place to its own various different components.
For the aforementioned reasons—when I decided to put the “fullscreen logic” inside a separate thread, LibGDX crashed. Oh well, at least it works now—That is, by putting the aforementioned code inside the LibGDX’s ApplicationHandler’s render method!

Eclipse debugging getting full stack

I just have a simple question, consider the following method
public void do_something(long arg){
//some work
}
and in eclipse, I added a break point for the above method and run the program, everything is fine, but I cannot find out the stack of current point?! for example
call do_something
push id
call previous_method
call xyz
pop z
call useZ
push z
I mean this method is called by 10 different methods and different stack, how would I find out the full stack of the thread(including methods) with eclipse?! should I change some default property or what?!

To put an image, I repeat my comment as an answer.
In the Debug View you can find the call stack and in the Variables View you can find the actual parameters and values of the local variables:
To get the actual parameters and values of local variables of an other method in the call stack just click in the Debug View on a method above the current method.
This isn't working for a multi-threaded application. You can only see the call stack for the current thread where the method is running in it. Look at:
In the method foo a thread is created by creating a timer. If the jvm suspend on bar, it only sees the call stack of TimerTask.run -> bar but not main -> foo -> run -> bar.

What you've described isn't a stack.
It's a history.
Eclipse isn't designed to give you a history. However, there are other tools that can show you the history, such as Chronon. However, that might be too expensive for you! It also might use too much memory if your application is very complex.
The simplest way to get a history, however, is to put System.out.println("some message") in lots of places.
It can be inconvenient to use System.out.println everywhere, so a couple of other ideas have been developed to improve on this:
Logging frameworks handle common tasks such as printing the time when something happened, rotating big log files etc.
Aspect-oriented programming allows you to inject logging in lots of places at once.

Android Programming and Java syntax

This is a question regarding the syntax used in Eclipse SDK while programming some JAVA code for an Android App.
I am an embedded microcontroller engineer that's mainly used to programming in Assembler (a long time ago) and C. I am a newbie when it comes C++ and JAVA and to help me write my code I have been using a mix of the developer.android.com for background info and stackoverflow.com for real world examples and have found them very useful.
So, I have no problem writing code to do what I want to do because I've always done it, but I am finding it very difficult getting my head around the syntax used in writing Android Apps.
For example to access the GPS one of my lines of code read thus:
LocationManager locationManager = (LocationManager)
this.getSystemService(Context.LOCATION_SERVICE);
but can be shortened to this:
LocationManager locationManager = (LocationManager)getSystemService(LOCATION_SERVICE);
I prefer the second version, but why were some examples written like the first example? Both seem to work fine. I've seen other examples that look even more complicated using "Class".
Secondly, is this not a complicated way to do a really simple thing:
Toast.makeText(getBaseContext(),"Hello World",Toast.LENGTH_SHORT).show();
Why not:
Toast("Hello world");
It now takes me four times as long as it use to write code.

The line break after the cast there is just to keep the lines from getting too long.
On this:
Toast.makeText(getBaseContext(),"Hello World",Toast.LENGTH_SHORT).show();
... it would be simple to write it as you say, aexcept that doesn't do the same things. Basically, that line is
Finding the outermost enclosing place to put graphics
Setting the text you want to show, and setting some formatting or some such
and then showing it.
You want to split those up because you don't always write to the outermost world, and you may want to, for example, make several different chunks of text and show90 or hide() them later. (Think an error message and a success message, for example. You like to build them once and then show/hide the ones you don't need.)
Now, if you can define what context you want and never want to mess with the visibillty, you can make a function that does just that.

It is kind of beginner OOP-ish style to put this everywhere. It is implied in your second example, and the second example is the more common style.
Now this one has to do with a bit of engineering. Yes, your second short example could have been implemented (except that Toast is a class, not a function, but a similar thing would work), but it would preclude a lot of important things you may want to do. A Toast may not be all that lightweight of an object; you may want to cache it. That's why you first get an instance with makeText and only then call show on it. The Toast instance will also have a complete lifecycle that you need to control, but won't be able to with your simple example. The instance can probably undergo further configuration, etc. etc. In short, there's a reason for it which is not obvious from a Hello, world piece of code.

Welcome to the world of Android and Java programming. Since you come from an assembly language background, my advice is: Get used to more typing. :)
Regarding the first code fragment: First, the qualifier this. on the call to getSystemService() is redundant; you can just drop it. Secondly, you can eliminate the qualifier on LOCATION_SERVICE by statically importing the name. Add something like this to the imports for the compilation unit:
import static android.content.Context.LOCATION_SERVICE;
or, if you don't mind the namespace pollution:
import static android.content.Context.*;
Regarding the second fragment: for architectural reasons, Toast eventually needs to associate the popup window to some application context. The first argument to the factory method makeToast is what makes this possible. (By the way, you just need getContext(), not getBaseContext(). You could also stash the context in a field.) As far as the third argument to makeText—arguably, a version of the factory method could have been provided that has a default display time, but Android doesn't provide that, so you're stuck with the third argument as well. You can again avoid the qualifier by statically importing LENGTH_SHORT. Finally, the factory method just returns a Toast object. You aren't required to show() it just yet; it could be stashed and shown at a future time. It's good design to separate creating the Toast object from the action of putting it on the screen.

I will try to explain the things in the easiest way and to the best of my ability.
1. ".this" refers to the current object in Java. ".this" specifically points to the current object accessing its own instance variable members of that class.
2. Using "this" is just being more specific.
3. Now in the case of Toast, It requires the "context" parameter to point to the Activity
where it will display the Toast.(ie on which activity)
4. You can use "this" if you are not inside an Anonymous class, or if you are in an Anonymouse class then use "Your_Activity_Name.this" in place of context.
5. getBaseContext, getApplicationContext are like global access to the parts of the Application.
6. I always prefer Your_Activity_Name.this in context place. Context means the Activity, on which the Toast is going to be displayed. And yes there is No Toast(String s) method in activity.

Replacing a running program with an fresh instance of itself

I am attempting to setup a reset method within a program that essentially creates a replacement of itself and then closes itself down leaving the replacement running. I know that normally to do this I could use some outside driver class and have no issue, but I am seeing if it is possible to create a completely independent instance of a class with itself.
If I create a new instance and then exit the existing instance, the newly created instance exits as well. I would imagine that this is possible but I can not find any way to go about it at this point.
The particular program I am working on is a Swing GUI and I have set the default close operation to EXIT_ON_CLOSE.
The reason that I wish to do this is that it would be more simple to just replace the current window with a new one than it would be to go all the way through and reset everything back to default.
Also on a purely theoretical note I would like to find out i this is possible.

Quick Solution: don't use EXIT_ON_CLOSE as your default window close option. Check the API and choose a better one such as JFrame.DISPOSE_ON_CLOSE.
You state:
The reason that I wish to do this is that it would be more simple to just replace the current window with a new one than it would be to go all the way through and reset everything back to default.
Which leads to a longer potential discussion: you probably don't want to do this, to exit one window and pop up another. Besides being annoying, there are probably much better ways to achieve this end. For one, your GUI should be based on a model, and resetting the model should be fairly easy if it is well written. If not, then consider refactoring it so it is easy. We can help you with this.