While on it also added keyboard shortcut so you can switch on-off the wrapping using Ctrl+Alt+W (M1,M3+W in “Eclipse Language”).

Trust me, it’s a useful plugin : )

Latest version can be installed from the update site: http://ahtik.com/eclipse-update/

Word Wrap project site

Thanks to the shortcut I’m not even waiting anymore to have it fixed in the very deep core of the Eclipse platform as the changes would be massive and simply switching it off before launching a debugger is good enough for now.

For a quick background, BPMN (Business Process Modeling Notation) is the leading standard for business process modeling managed by the OMG. A new version called BPMN2.0 (released January 2011) brings numerous changes to the table, most importantly increasing the consistency and integrating orchestration and choreography in a way that makes BPMN 2.0 a great choice for business process engines.

Over the past few months we‘ve been very excited to work on a new BPMN2.0 Visual Editor for Eclipse. It is free and open source, hosted at github. This github repo is a temporary place and will find a new home soon.

BPMN2 Editor is built on top of the awesome Graphiti modeling framework and behind the scenes uses BPMN2 EMF metamodel.

For more details check out the more detailed post about the BPMN2.0 visual editor by Kris from jBPM.

Check it out, have fun, contribute, report issues and bear in mind that it’s still beta and actively developed ; )

Java JRE in itself supports proxies for HTTPS but it does NOT support SSL connections over proxy. For that you’ll need to create a separate proxy tunneling socket and layer it on top of the actual SSL connection. So far so good but there’s a nasty exception that can take you ages to figure out:

Caused by: javax.net.ssl.SSLException: Received fatal alert: unexpected_message
	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1682)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:932)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)

There can be many reasons but one of the unexpected ones — make sure to add

Pragma: no-cache

to your http proxy CONNECT request header! Otherwise you’ll get this exception.

To find out we (me and Ivar) did a little test-drive using recently announced Glassfish Eclipse Bundle that contains Eclipse IDE with bundled Glassfish J2EE server, optionally JDK and a lot of integrated plugins to get you started quickly.

After cutting out all the downloading, startup etc delays we ended up with a surprisingly short 10min demonstration! It was interesting that we barely wrote any code or XML — see for yourself! Tricky part was initial setup to get all the jars and configurations right — must be followed pretty much the same sequence as in the video!

Ok, here it comes, have fun Probably adding a few annotations and audio would help?

Any feedback is more than welcome!

The relation to Eclipse is simply the fact that big part of eclipse.org is a great example of good test coverage built on top of jUnit. Plus, it was literally pulling my hair out in one of the eclipse-related testing-suites.

I stepped into this a few years ago while bug-fighting a test class that had unexpected initialization.

Pretty sure that many of you know the answer but definitely fun outcome!

As everyone can simply run this snippet yourself I won’t delay approving comments, I’ll just accept them whenever I get a free moment. This comment system here has captcha but additionally all comments must be approved manually.

import junit.framework.TestCase;
public class MyTest extends TestCase {
private static int count = 0;

{ count++; }

public MyTest() {count++;}

public void test1() { System.out.print(count); }
public void test2() { System.out.print(count); }
public void test3() { System.out.print(count); }

}

I’m sure some of us don’t always take this behavior into account

After figuring this out, SPECIAL fun is a bit modified case:

import junit.framework.TestCase;
public class MyTest extends TestCase {
private static int count = 0;

{ count=count*2; }

public MyTest() { count++; }

public void test1() { System.out.print(count); }
public void test2() { System.out.print(count); }
public void test3() { System.out.print(count); }
}

For this last snippet I think without running it you won’t figure it out At least I didn’t..

UPDATE: Decent in-depth hi-tech doc about java init http://www.artima.com/designtechniques/initialization7.html

UPDATE2: Correct answers were 666 and 777.

You are allowed to change ONLY the main method! Of course changing sysout line is out of question.

You can leave your answer in comments and I’ll publish/approve them together with the solution.

[java]
public class InstanceDemo {

public static void main(String[] args){
MyClass cl1 = new MyClass();
MyClass cl2 = new MyClass();
System.out.println(cl1.ocl==cl2.ocl && cl1!=cl2);
}

private static class MyClass extends java.util.ArrayList {
private final Object ocl = new Object();
}

}
[/java]

I’ll post the correct answer in 24h

UPDATE: Was not that hard afterall! ~45 correct answers.

Yes, clone() was the answer I was looking for:
[java]MyClass cl2 = (MyClass) cl1.clone();[/java]

Ed Merks surprised with a nice solution:
[java]
//Add this line as the first line of main.
class MyClass extends InstanceDemo.MyClass {
Object ocl = null;
}
[/java]

And a lot of people took the hard-core way:
[java]
Field field = cl1.getClass().getDeclaredField(“ocl”);
field.setAccessible(true);
field.set(cl2,cl1.ocl);
[/java]

I have seen this to be pretty standard practice (and have done this myself too).

Be aware that SimpleDateFormat#format(..) is not thread-safe and thereby for most of the cases you should not use this as a static field in server, Eclipse RPC or any other multi-threaded environment.

SimpleDateFormat is internally using field “calendar” that is set with each #format(…) method call so that pretty much breaks the thread-safety.

Bytes in java are always signed and are quite horrible to use because of the casting and weird side-effects (or I’m just stupid enough to call it weird).

But we need unsigned bytes quite a lot. Most of the time for reading various streams (networks, 8bit strings etc) some text stream you still end up with byte streams.

There is a nice trick converting them from signed to unsigned in case you want to get normal 0..255 range for the chars.

byte mybyte = -104;
long mynewint = mybyte & 0xFF;

Hope it helps!

I had quite a nice puzzling while trying to find some easier way. Is there?

Consider a code like this:

if (isConfigurable()) {
  Bundle bundleCopy = bundle;
  Preferences[] preferencesCopy = new Preferences[1];
  preferencesCopy[0] = new org.eclipse.core.internal.
			preferences.legacy.PreferenceForwarder(
			this, bundleCopy.getSymbolicName());
  return preferencesCopy;
}
return null;

Do you see what’s wrong there?

The problem is that if your #isConfigurable is always FALSE then your code still:

1. loads PreferencesForwarder class
2. initializes all PreferencesForwarder’s static variables
3. forces Preferences plugin to load

Always, if possible and makes sense, isolate your class loading into a simple Runnable inner class if there is some static init or plugin activation trigger involved!

Then the code would become:

if (isConfigurable()) {
  final Bundle bundleCopy = bundle;
  final Preferences[] preferencesCopy = new Preferences[1];
  Runnable innerCall = new Runnable() {
    public void run() {
      preferencesCopy[0] = new org.eclipse.core.internal.
			       preferences.legacy.PreferenceForwarder(
				 this, bundleCopy.getSymbolicName());
    }
  };
  innerCall.run();
}
return null;

When you think of it – this pattern is somewhat similar to the singleton pattern implementation – the one of the very few thread-safe and fast singleton patterns that is bugfree and truly lazy!

Quoting wonderful singleton impl from wikipedia:

public class Singleton {
   private Singleton() {}
   private static class SingletonHolder {
     private final static Singleton INSTANCE = new Singleton();
   }
   public static Singleton getInstance() {
     return SingletonHolder.INSTANCE;
   }
 }

(OK, to be fully honest, since java1.5 you can also trust volatile flags but – trust noone, use the old stuff:P)

For the reference, the PreferencesForwarder example was taken from the org.eclipse.core.runtime.Plugin#getPluginPreferences class and modified a bit.

UPDATE: This post is not fully correct! Never assume something to be true even if it comes from a trustworthy source like eclipse core runtime source. Please see the comments for explanation!

My question is: can there be an audit to automatically detect source files where you explicitly defined serialVersionUID that is out of date? A nice-to-have addition would be a quick-fix for repairing serialVersionUID. Current eclipse quick-fix supports only generating serialVersionUID from scratch.