The only two options I can think of, is to make a HTML5 cross-platform mobile app that will work across the spectrum, having said that, I can understand corporate environments wanting to cling on to IE to support ActiveX apps within the browser, which is leading you to think that the Java on the desktop is the same as on Android, which is not true.
For the most part, and the second option, the SDK covers a subset of Java 5, collections, apache, etc, syntax wise, are identical, so maybe a recompile on the business logic and a new User Interface for the front-end for Android platform. (Yes you can recompile that targetting the Android SDK...)
In short, no can do unless there is a motive and drive to re-build it to be compatible with devices now and in the future.
After comments left below, to recap:
The browser does not support the running of Java applets within in itself. JRE != Android's Java Runtime aka DalvikVM. Desktop Java uses JavaVM/JRE as endorsed by Sun/Oracle and the OpenJava JDK which is sanctioned by Oracle. JRE = Java Runtime Environment
Terminal IDE which does contain "a java compiler", chances are (I will install it and report feedback on this btw) it is a extremely limited cut down version of OpenJDK, it is the only one available natively for ARM, according to this blog which cannot do native Java Windowing apps such as Swing or JavaBeans due to the simple reason that the version of the Java Runtime Environment is very different for Android, and highly optimized for the native processor.
Also, DalvikVM knows zero about Swing, JavaBeans, etc hence why it goes some way in explaining that the Java on the desktop is not the same as the Java on Android.
As for having the view that Android is very much like Linux, that view I stand by, is this, it is not Linux, the kernel is linux itself, but user-land tools are supplied by busybox, furthermore, the native C run-time library under Android is called bionic, and is limited due to those wee processors like ARM. When compared to the desktop Linux version, there's the run-time library supplied by gcc - GNU C Library or more commonly known as glibc - which supports vast more C/C++ idiosyncratics such as STL, Boost, full exception handling. That is my view and is separate from the topic and straying off the beaten path here. :)