Well, that is assuming pretty much, and is quite untimely

Step zero: settle on a project name (ecsJ? -- jdk/2 is probably too close to the openjdk and java 2 trademarks) and set up a repository os/2 users can access. Porting mercury isn't something to spend any effort on (if we have it already -- yay!).
The first step is porting the build system. This mostly involves copying and renaming files, and modifying make files. No Java/C++ knowledge is truly necessary, though knowing how to use a compiler is a big plus. Familiarity with (or willingness to learn) unix scripting and makefiles is a must though. I am assuming it's possible to modify the build system to use precompiled class files instead of a bootstrap jdk.
The next step is to try to build. And this is the step where unforeseen dependencies will hit, and hit hard. I know that to be able to build world, CUPS is required, though I hope it's not for Hotspot. Smedleys CUPS may or may not work; at least my /opt/csw/include/cups/cups.h wasn't sane enough, so I had to tell the build system to use my /usr/include/cups/cups.h. (I don't know why it found the former first). There will certainly be some gaps that must be filled in, by direct porting, and maybe some with additions to the Netlabs libc. It will take some time and effort to get everything to build. Then there are the issues when we try to link. I don't think that will be painless.
At this time, we can try to use the jvm, and will probably run into one segfault after another and/or even worse errors due to thread synchronization (those will be hard to debug). It is time to try and build javac and the related tools, if that wasn't attempted concurrently.
Independent of all this, is to convert man pages to help files (.inf isn't it?). Some kind soul with little or no technical background can do this -- particularly if she has translation experience.
By now, it's time to think about publishing, and seeing about java conformance testing. And of course, to tell the world.
Have fun