Now I get that warm and fuzzy feeling :)
2008/6/9 Ken Cavanaugh <Ken.Cavanaugh_at_sun.com>:
> 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_at_sun.com>:
>
>> Ken--_at_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).
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net For additional
> commands, e-mail: users-help_at_grizzly.dev.java.net