Posts Tagged ‘java’
If you have not yet read it, lets go and check the piece of code causing a deadlock.
In order to not spoling the fun, I’m providing the answer in the full post.
Suppose you have this class:
public class Singleton implements Runnable {
public static final String A_STRING = "Hello World".toLowerCase();
public static final Singleton INSTANCE = new Singleton();
public static Singleton getInstance() {
return INSTANCE;
}
private Singleton() {
super();
launchThread();
}
public void launchThread() {
synchronized (this) {
Thread t = new Thread(this);
t.start();
while (t.isAlive()) {
try {
wait(100);
} catch (InterruptedException e) {
// Interrupted.
}
}
}
}
public void run() {
System.out.println(A_STRING);
}
public static void main(String[] args) {
Singleton.getInstance();
}
}
If you run the main method, it hangs in a deadlock. Can you see the reason?
Wayne Beaton has made some great articles about using adapters in Eclipse to reduce coupling.
In Adapting, the last post of the series, he shows some code to check if an object is or adapts to a given interface. This code has the problem that it needs to be repeated for every interface you need to check against.
The process is:
- Check if the object already implements the interface.
- If it doesn’t, check if it implements
IAdaptableand can adapt to the interface. - If it doesn’t, check if an adapter can be found through the
Platform.getAdapterManager().loadAdapter(…)
My solution to avoid repeating code and leverage Java5 generics is this:
private <T> T adaptAs( Class<T> clazz, Object object )
{
if ( object == null )
{
return null;
}
if ( clazz.isAssignableFrom( object.getClass() ) )
{
return (T) object;
}
if ( object instanceof IAdaptable )
{
return (T) ( (IAdaptable) object ).getAdapter( clazz );
}
else
{
return (T) Platform.getAdapterManager().getAdapter( object, clazz );
}
}
More solutions, all of them Java 1.4 compatible, are listed in the eclipse bug 118560.
Today I discovered the Violet UML Editor.
Besides of having a nice looking page and user interface, it takes UML into a new level. The level of simplicity.
When using UML I just want to get my thoughts into an easy to read diagram which you can use in any kind of internal or external documents. That’s usually word or the web.
Violet allows me to forget about all those features in other editors that are related to layout, positioning, scaling, zooming… I’m not tempted to loose a second playing with fonts or trying to attach lines to the right connection points. It just works.
As a plus, it is free, it can be launched via Web Start and it is an Eclipse Plug-in. What else can you ask for?
Try it!
Traces allows an Eclipse plug-in developer to display information useful during the development and debugging stages. The information in a trace is certainly not useful for the end-user, so it should not be displayed by other means (like… in the eclipse error log view).
In a sense, trace information can be seen as println 2.0… it is usually ad-hoc information that is useful for reporting important events in a plug-in. measure execution times and/or can help in finding problems in the code like thread deadlocks.
Eclipse provides good support for tracing, including elements on the user interface to enable/disable and set the trace options. The mechanism is somewhat documented in the eclipse help, but I’ll try to provide some extra information on setting up tracing for your plug-in.
The first thing is getting to know the eclipse UI facilities. When testing a new plug-in, I assume that you’re launching a runtime eclipse application. It is not important if you’re debugging or running the application, it will print the trace either way… if enabled.
In the Run/Debug dialog, there are two things we care about:
- Passing the -debug command line argument to the launched eclipse application (using the Arguments tab).
- Selecting the traces we want to see using the Tracing tab.
Because your plug-in is not able to trace (yet), you can try enabling trace information for other plug-ins. One very verbose plug-in which is useful to check our set-up is org.eclipse.core.jobs.
Next, we want to define the tracing options for our plug-in. That is easily done by creating a file called .options in the plug-in project’s root.
The options file is a properties file where we can define the tracing options and their initial value. By convention, the options start with the plug-in id and the different options are separated by slashes.
#This is my comment com.example.core/myoption=false
Also by convention, there is a global switch for the plug-in, called debug. Unless this option is set to true, no trace should be printed. Any other trace option should (by convention) have “debug/” prepended. So a typical options file might be like this:
#master switch com.example.core/debug=false # switch for tracing products added to/removed from the shopping cart com.example.core/debug/shopping-cart=false
Remember, this is all by convention. If you look at eclipse plug-ins you’ll quickly realize that this is not mandatory… and rarely followed.
One final note on the options file. Why are all options set to false? The reason is that the file will be included with your plug-in, so you want to make the default tracing level to be quite limited… or non existant, just in case the end-user will pass the -debug flag to the application.
Now that everything is in place, you can launch the application again. In the Tracing tab you should now be able to modify the just defined flags in your options file.
Obviously, the changes in the launch options didn’t change a thing… our plug-in does not yet show any message. We need to provide the code for that.
The basic idea is very similar to logging, but we’ll use System.out instead of any logging framework (it is possible to use one, if you so desire). The first thing is to find a central place to trace. I tend to use an static method in the plug-in Activator to do so.
Before tracing, three things must be checked:
- The global debug switch has been enabled (-debug). This is accomplished with a call to
Platform.inDebugMode(). - The plug-in switch has been enabled in the .options file (PLUGIN_ID/debug=true). A call to
Platform.getDebugOption("PLUGIN_ID/debug")will tell you that. - The switch to the specific trace has been enabled. Use the same call described above (with the specific trace option) to check that.
If everything is ok, then the trace message is echoed to standard out by using System.out.
Before closing… and advice on performance. It is important to avoid doing expensive job (or, if possible, any work at all) for tracing before checking if the trace is enabled. One of such expensive jobs is building the string to display (concatenating, calling toString()…). If you’re using Java 5 (or greater) you’re lucky, because you can use the varargs feature to avoid creating the message too early.
For example:
/**
* Sends trace messages to stdout if the specified trace option is enabled.
*
* This is intended only for developing and debugging. The use of variable
* number of parameters avoids the cost of building the message when the
* debug option is not enabled.
*
* @param traceOption
* the trace option enabling the message trace.
* @param messageParts
* a variable number of objects with each part of the message to
* display.
*/
public static void trace( String traceOption, Object… messageParts )
{
if ( !Platform.inDebugMode() )
{
return;
}
String globalTraceValue = Platform.getDebugOption( PLUGIN_GLOBAL_TRACE_OPTION );
String value = Platform.getDebugOption( traceOption );
if ( null != globalTraceValue && globalTraceValue.equals( “true” )
&& null != value && value.equals( “true” ) )
{
for ( int i = 0; i < messageParts.length; i++ )
{
System.out.print( messageParts[i] );
}
System.out.println();
}
}[/sourcecode]
This little help should let you start tracing your plug-ins and you can collect some timing information, visualize the execution flow, look out for race conditions…
My profile
amuino on Twitter
My projects
My Open Source
Rambling about... 