Jesper Söderlund wrote:
Interesting news putting, Grizzly into the JDK..
I just hope that putting Grizzly i the JDK doesn't cause the kinds of
problems we've seen with old versions of supporting libraries "frozen"
in the JDK and causing problems for applications, such as Glassfish,
wanting to use newer versions.
Note that I said "for internal use only". Grizzly is mature enough to
see use in parts of
the JDK implementation, but the Grizzly API is not mature enough to be
exposed as a
standard JDK API. Perhaps a JSR for some sort of scalable
communications framework could be attempted at some point, but it is
too early to do so
right now: at the very least, we need to get JSR 203 stabilized and
fully implemented first
(which provides among other things new async IO facilities).
Most likely, a Grizzly implementation in the JDK would be renamed so
that it would NOT
conflict with external use of Grizzly. We have lots of tools for
automatic renaming of
files in builds, so this is easy to do. Alternatively, it may be
possible to use the module
system in JDK 7 to prevent external access to the version of Grizzly in
the JDK.
Believe me, we are VERY aware of the problems of different versions of
code interfering
with each other. That's why the CORBA implementation classes in the
JDK are packaged
in the com.sun.corba.se package, and in GlassFish they are in
com.sun.corba.ee.
We have done similar things with other classes as well, such as renamed
copies of
ASM and BCEL. Sometimes this results in rather more copies of things
than we like:
at one point, GlassFish on Sun's JDK included at least 3 copies of
BCEL, all renamed
differently. This is less than optimal, but sometimes it's just too
hard to coordinate things
to do better.
Even this is not always enough: we really need to isolate EVERY aspect
of the namespace
for shared modules. For example, at one time all CORBA properties in
both the JDK and
GlassFish started with the prefix com.sun.CORBA. This caused problems
when the SAME
property name was used to give the name of a class that must implement
a particular ORB
interface in the com.sun.corba.(se|ee).spi package hierarchy. This
doesn't work very well
when the property gets picked up for initializing the other ORB,
resulting in a ClassCastException.
I fixed this by splitting the property name space in a similar fashion:
all Sun-specific
CORBA properties are now prefixed with com.sun.corba.(se|ee) as well as
packages.
Ken.
/Jesper
2008/6/5 Ken Cavanaugh <
Ken.Cavanaugh@sun.com>:
Ken--@newsgroupstats.hk wrote:
rmi is not non-blocking in standard jdk, right? any plan for implement a
non-blocking rmi by grizzly?
Since RMI is really a programming model (with two completely different
implementations:
RMI-IIOP and RMI-JRMP, each with a different protocol), it sits above
Grizzly, since Grizzly
really only provides transport services.
I doubt there are any plans to put RMI-JRMP on Grizzly. That would be
coming from the
Sun east coast RMI (JRMP) group in any case, and I don't know of any
communications
from them about Grizzly.
RMI-IIOP is another matter: the CORBA team is currently working on
moving all of the ORB
transport code to Grizzly. This also implies that Grizzly will need to
be in the JDK once
we put the ORB-on-Grizzly work into the JDK, but there are currently NO
plans
to expose Grizzly APIs for use outside of the JDK (and no JSRs or other
standards work
currently planned in that area).
An asynchronous RMI implementation is yet another issue, one that is
completely unrelated to the
RMI on Grizzly questions (since either flavor of RMI could be extended
to support
async behavior regardless of the underlying transport). I don't know
if there is
any consideration of this in the RMI-JRMP camp: they are not active on
the Grizzly mailing
lists.
For RMI-IIOP, there once was a plan to do something like what you are
asking (I talked to
an engineer from Borland about this many years ago), but that plan
never really went
anywhere. It might be possible to do something like this mostly
transparently, essentially
by returning a future implemented as a proxy to the return type for a
method invocation.
Other tricks would be needed in cases where the return type is not
suitable for this approach.
It could also be done more directly by mapping the remote interface
into an asynchronous
future-based interface with a bit of runtime support for async calls.
This second case would
be a significant extension to the RMI programming model. This second
case is essentially
what was done for the AMI async extensions to CORBA.
Do you have strong requirements for such a feature? I'd be interested
in knowing more
about any such requirements.
Thanks,
Ken Cavanaugh
(I'm the ORB tech lead, and also one of the engineers working on
Grizzly).