We Keep Coding

Assertions or Annotations for thread correctness

I am coding as part of a project which uses multithreading and I'm trying to find ways to detect thread mistakes in my code.
Are there some existing tools I could use to help me do this?
For example-
an assert that my method is being called by the correct thread
or
some kind of static checking with annotations, similar to #Nullable and #NotNull, to detect when my code calls a method from the wrong thread.
Although the project is multithreaded, there is almost no synchronisation required because the different threads don't access the same objects, they have their own instances.
Broadly speaking, there are four threads running at once
Server thread = maintains the state of the game for one or more
clients
Client thread = processes user input, maintains a local
copy/cache of server data for rendering
NetworkMessage thread = processes incoming/outgoing messages
between server and client
Render thread = processes the local data into rendering information for the
graphics card
The classes are sometimes intended for only one of the threads (for example user input polling is client-only), sometimes they are for multiple threads (eg the calculated movement of a projectile uses the same code on both client and server simultaneously to reduce perceived lag). Several times I've called a method from the wrong thread, leading to subtle and unrepeatable bugs and very nearly serious monitor screen damage (from my fist)
What I have thought of so far is something like this:
public void myMethodThatAssumesClientThreadOnly() {
assert checkThread(CLIENT);
// can now happily call other client-thread code without fear
}
but I would prefer something with static checking similar to #Nullable
eg
#Thread(CLIENT)
void myClientMethod() {
//client-only stuff here
}
#Thread(SERVER)
void myServerMethod() {
//server-only stuff here
}
#Thread(CLIENT + SERVER)
void myClientAndMethod() {
myClientMethod(); // error- server thread might call client method
}
Unfortunately, being an annotation noob, I have no clue whether this is easy or actually very hard.
Any pointers? I can't imagine I'm the first one to look for something like this.
TGG

The Checker Framework enables the creation of compile-time static checkers that verify program correctness. Its GUI Effect Checker is similar to what you want. Here is an abridged excerpt from its manual:
One of the most prevalent GUI-related bugs is invalid UI update or invalid thread access: accessing the UI directly from a background thread.
If a background thread accesses a UI element such as a JPanel (by calling a JPanel method or reading/writing a field of JPanel), the GUI framework raises an exception that terminates the program.
It is difficult for a programmer to remember which methods may be called on which thread(s). The GUI Effect Checker solves this problem. The programmer annotates each method to indicate whether:
It accesses no UI elements (and may run on any thread).
It may access UI elements (and must run on the UI thread).
The GUI Effect Checker statically enforces that UI methods are only called from the correct thread.
The GUI Effect Checker is tuned to detect and prevent GUI threading errors, whereas you are concerned about client-server threading errors. However, the principles are the same and you should be able to adapt the GUI Effect Checker to your needs with relatively few changes.
There is a paper that discusses case studies using the GUI Effect Checker.
An alternative is to adapt a bug finder for finding errors in multithreaded applications. Unlike the GUI Effect Checker, it does not give a guarantee that there are no threading bugs. However, it is effective in practice, and it does not require you to write any annotations in your program.
Finally, the Checker Framework also contains a Lock Checker that ensures correct synchronization. That helps to prevent concurrency errors, though it's orthogonal to your chief concerns about thread safety.

This will assert that method foobar() is called by the correct thread...
SomeType foobar(...) {
assert(Thread.currentThread() == theCorrectThread);
...
}
...If, somewhere in your code prior to the first foobar() call you have set
Thread theCorrectThread = new Thread(...);
but I would prefer something with static checking similar to #Nullable
I know very little about annotations myself. I know that they can be used to attach meta-information to compiled classes, and I know that the program can obtain that information at run-time by calling methods of the Class object, but if there's any way an annotation can define compile-time behavior, that's beyond my ken.
Probably a moot point anyway. When the compiler is processing a .java file, there is no way for it to tell what thread or threads might possibly execute the code that it contains.

Swing Worker Usage in mixed threads

I have a GUI which consists of a toolbar with each button invoking different classes. The class I invoke consist of UI components which are displayed in the Internal frame of the main GUI. The Invoked class works as a separate thread and has to perform the following functions.
Trigger a command to the client, so that the client starts sending
the contents of a file.
Receive the file contents here,filter it and add it to a JTable.
Progress bar has to be displayed during the file contents transfer.
Display the UI after adding it to the table.
I am new to Swing worker, so can some one help me to get how it works with my situation and the advantages of using Swing Worker and Invoke later function. I followed the examples in the oracle site and few other sites but I am not able to see how this works for my classes.

SwingWorker has...
Progress change functionality built in, via the PropertyChange support
Has helper methods that allow you to synchronise updates to the UI via the publish and process methods, making the process significantly easier...
A self contained workflow concept which makes it (generally) easier to use than rolling your own. There are exceptions to the rule, but your outline doesn't fit those exceptions (IMHO) - this is both and advantage and disadvantage...
For example...
java swingworker thread to update main Gui
JProgressBar won't update
Populating jTable using database data (relates to updating a JTable from a SQL source, but shows how a SwingWorker might be used to update a JTable)
One of the (possible) drawbacks to SwingWorker is it will only allow (I believe) 10 workers to be executed simultanously

Is Android API callback based?

Say I have a very simple Android app that has just one activity - the activity displays a plain screen. Lets say I have overridden the onCreate() method of the activity and it simply sets the screen as described in activity_main.xml and then returns as shown below:
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//boolean BT_success = turnBluetoothOn();
}
In a desktop Java (or C or Python) program, execution starts at the "main" method/function and the program finishes executing when main has finished executing (and once all the functions called by main have returned). In this simple app described above, when the common set of callback functions like onCreate(), onStart() and onResume() are finished executing, is there any part of my code that is executing?
In this sense, there is no "main" method, like in the case of desktop Java, C or Python, right? Even if we had a couple of buttons in this main screen, we would have callback functions for those buttons.
So is it fair to say that the Android API callback based in the sense that an app developer has to implement certain callback functions (and those can in turn call other functions)?

Not in the way Win32 is. For one thing, the Android flavor of Java doesn't readily accommodate the notion of a canned function; it has neither delegates (C#) nor functors (C++, Python) nor function pointers (C, C++).
The Android API is still event driven, like most GUI systems are; but the primary ways for you to provide hooks into your code to the framework are:
inheriting from library classes and then overriding functions that were meant to be overridden;
implementing abstract interfaces in your classes (possibly anonymous) and providing those objects to the framework.
This is, generally, the Java way.
EDIT: depends on your definition of callback :) Normally, when people say that, they mean a function. In this sense, it's not callback-based. But if you mean "the framework calls you whenever something interesting takes place", then yes, it is. Event-driven, like I said.
EDIT2: Preamble: C has function pointers. It's a datatype that you can initialize with a function name, pass around like a primitive value, and then call with arguments at some point down the road. The call will be received by the function that the pointer was initialized with originally.
Windows, like Android, is an event-driven GUI system. The event-driven nature of Windows is implemented mainly via said function pointers - you pass a pointer to your function to the framework, the framework calls it back when something interesting occurs. This was designed in mid-1980's, before the advent of object oriented languages.
Now, those functions that are meant to be called by the framework are referred to as "callback functions" or simply "callbacks". I come from the Windows background, so for me, "callback" primarily means "callback function". As opposed to Android-style callback objects (is that even a term?).

This is not dissimilar to the way any GUI application/framework is designed. Even Java Swing works in a similar fashion. You implement the "callbacks" that are hooked to UI control events, and your "main" function usually only serves to kick off the main event loop and exit. Note that here, when main() exits, the program itself does not exit.

To simply answer your question, yes it is based on callbacks. You specify which activity should be the starting point for your application in your androidmanifest.xml. This activity's onCreate() is called to initialize the layout. Every interaction that you perform on the screen triggers a callback (which you will override to implement what you need). But just because the main activity exits does not mean that the application will exit.
This is where you go into the activity lifecycle. All activities sit on the main thread in a stack like manner. When one activity is killed, you go to the next activity in the thread and so on. The application itself exits when all it's activities in this stack have been killed or Android decides to terminate it. Keep in mind that you might normally expect onDestroy() to be called when Android terminates the application but this is not the case - Android may or may not call onDestroy(). In this case, there was no callback for the exit.

I would say the Android API is heavily based on Extension. You almost always have to extend their Classes and override their methods.
super.onCreate(savedInstanceState);
Is a call to the Super Class method that would normally be hidden by you override. You are, however, free to call back to classes that provide the logic you need but you are not forced to. I recommend that you do, and that you put those Classes under UnitTest.

What is the correct way to use v8::Locker, and why must I use it?

I'm trying to embed v8 in an Android application using NDK.
I have a JNI module that looks something like this (JNI mapping code not shown):
#include <jni.h>
#include <android/log.h>
#include <v8.h>
using namespace v8;
static jlong getMagicNumber() {
HandleScope handle_scope;
Persistent<Context> context = Context::New();
Context::Scope context_scope(context);
Handle<String> source = String::New("40 + 2");
Handle<Script> script = Script::Compile(source);
Handle<Value> result = script->Run();
context.Dispose();
return result->NumberValue();
}
The first time I run getMagicNumber, it correctly runs and returns 42. The second time I try to run it, it crashes.
Specifically, this ASSERT seen in v8's isolate.h fails:
// Returns the isolate inside which the current thread is running.
INLINE(static Isolate* Current()) {
Isolate* isolate = reinterpret_cast<Isolate*>(
Thread::GetExistingThreadLocal(isolate_key_));
ASSERT(isolate != NULL);
return isolate;
}
It sounds a lot like this problem, which suggests using v8::Locker to obtain "exclusive access to the isolate".
By adding a simple Locker l; to the top of getMagicNumber, the crash no longer occurs. Problems that fix themselves that easily tend to break themselves when I'm not paying attention.
I only have the most tenuous understanding of why this fixes my problem, and I'm getting compiler warnings that I'm using v8::Locker in a deprecated fashion. The recommended method is to provide it with a v8::Isolate as an argument to v8::Locker's constructor, but I have no idea how I'm supposed to "obtain" an isolate.
Ultimately: What is the proper way to solve this problem according to the current state of v8, and why?

As I understand it, a V8 isolate is an instance of the V8 runtime, complete with a heap, a garbage collector, and zero or more V8 contexts. Isolates are not thread-safe and must be protected via v8::Locker.
In general, to use V8 you must first create an isolate:
v8::Isolate* isolate = v8::Isolate::New();
Then, to use the isolate from any thread:
v8::Locker locker(isolate);
v8::Isolate::Scope isolateScope(isolate);
At this point the thread owns the isolate and is free to create contexts, execute scripts, etc.
Now, for the benefit of very simple applications, V8 provides a default isolate and relaxes the locking requirement, but you can only use these crutches if you always access V8 from the same thread. My guess is that your application failed because the second call was made from a different thread.

I am just learning V8 now, but I think you need to call:
v8::Locker locker(isolate);
This will create a stack allocated Locker object which will block the Isolate from being used on another thread. When the current function returns this stack object's destructor will be called automatically causing the Isolate to be unlocked.
The you need to call:
v8::Isolate::Scope isolateScope(isolate);
This sets the current thread to run this Isolate. Isolates can only be used on one thread. The Locker enforces this, but the Isolate itself needs to be configured for the current thread. This creates a stack allocated object which specifies which Isolate is associated with the current thread. Just like the Locker, when this variable goes out of scope (when the current function returns) the Scope destructor gets called to un-set the Isolate as the default. I believe this is needed because many of the V8 API calls need a reference to an Isolate, but don't take one as a parameter. Therefore they need one they can access directly (probably through per-thread variables).
All the Isolate::Scope class does is call isolate::Enter() in the constructor and isolate::Exit() in the destructor. Therefore if you want more control you can call Enter()/Exit() yourself.

multithreading for java graphics

I have a java application that streams raw data and draws real time plots accordingly. this is handled by calling methods from a class i wrote that uses the Graphics object. i implemented algorithms in an overridden paintComponent method to generate all the plots from the most recent data. i have other methods in my class to update variables used in the paintComponent method to draw the graphs.
in my main class, i update my graphs periodically in a timer event handler. in the event handler i call methods from my graphs class that update certain variables, do a few calculations, and then call repaint() (which apparently is the correct way to call the paintComponent method).
my problem is, the algorithms i use in the paintComponent method can take a (relatively) long time to complete depending on the amount and resolution of my plots. (i haven't exactly run into this problem yet, but i'm trying to address it now). of course i wouldn't want all this graphing to hog all the processing time of my application, so i was wondering if it's possible to have "paintComponent" execute in a separate thread.
what would happen if i created a subclass in my main to run in a separate thread and simply called the graph methods i described? would that automatically make all of those methods (including paintComponent) execute in the new thread? or would i have to modify my graph class itself for this to work? ideally i would like to avoid modifying my graphs class because i have already designed it to work within the NetBeans GUI builder as a JPanel, and i'd like to avoid breaking that functionality.

There's a couple options.
One method is to use two BufferedImages, where you draw on one in separate thread, and paint from the other one, and switch as drawing completes (for what I assume is a snapshot every so often.)
A much better solution is to have a model of directly renderable data (as in the data it holds can be drawn without performing any further algorithmic work on it).
This means you will perform your alogirthms on a separate thread, calculate the values that will be used to paint, call SwingUtilities.invokeLater to update the model. The model will then only get updated on the Swing thread, and when you repaint, you have access to exactly the data you need to draw (and no extraneous data).
If this data is still so much that painting takes a long time (ie: if you're drawing charts with tons of data points), you'll send to calculate which parts of your window need repainting and fire repaint() on just that. This piece should be a lat resort however. 99% of your performance will come from moving the algorithms into a separate thread, and giving the painter access to directly renderable data.
If you look at best practices on updating a TableModel with external data, what you have is the work that gets the data occurring in a background thread (typically SwingWorker) and then posted to the actual model via invokeLater() (This is so the data doesn't get modified while your paint() is trying to read it.) and then firing appropriate events from within the model update that tell the table what cells changed. The table then knows what part of its viewport needs repainting and fires the appropriate repaint() method. During this time the background thread can continue retrieving data and adding new updates to the event queue via invokeLater.

you have to redirect paint methods to the SwingWorker or Runnable#Thread (all output to the GUI must be wrapped into invokeLater), example here or here

Well, if you want to improve the responsiveness of the GUI you could do the lengthy work in a SwingWorker, although I don't know that doing so will speed up your application any more.

I have a java application that streams raw data and draws real time
plots accordingly. this is handled by calling methods from a class i
wrote that uses the Graphics object.
To complete other's answer:
you should really consider to use JFreeChart. It's a good library for drawing charts and you can modify dynamically the displayed dataset (and do a lot of more things).