You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/02/04 00:50:36 UTC
Implementing means to allow NAT-ed clients to provide services [was
roadmap]
Hi Sim & Gregg,
I just wanted to break this issue out of the original thread and
summarise our findings to provide a way forward, for solving one of the
original questions posed.
I want the implementation to be invisible to existing client and service
implementation and to just work.
I would like to start by implementing the Natblaster technique of
traversing NAT's with TCP, using JAVA. I'm not 100% how to fit this in
with JERI, however the following classes appear relevant.
* net.jini.jeri.connection.ServerConnectionManager
* net.jini.jeri.connection.ConnectionManager
I will need new ServerEndpoint and Endpoint implementations, some
observations:
* The Server will need to be aware of the Client's Public NAT IP
Address and recieve port.
* The Client will need to be aware of the Server's Public NAT IP
Address and recieve port.
* A public service will need to be provided - Initial Connection
Mediator Service (ICMS)?
* The Client will need to contact the Initial Connection Mediator
Service and request a connection to a Nat-ed Service. This would
need to be performed as an implementation detail of the
Endpoint.newRequest() method.
* The NAT-ed Service would need to be listening using the
ServerEndpoint implementation, which would be polling the ICMS to
maintain a connection.
* The ServerEndpoint implementation would listen for and intercept
connection negotiation requests.
* The ServerEndpoint implementation would pass the communication
through to the callback object once the connection is established.
* Once a connection session was negotiated successfully, the client
Endpoint.newRequest() method would return.
* TLS will need to be utilised.
Any helpful advise would be much appreciated, this should allow the
marshalled object to find it's way home.
BR,
Peter.
Resources:
* http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html --
Multi Platform Java library for reading and writing packets, java
equivalent of libpcap and libnet.
* http://natblaster.sourceforge.net/paper/natblaster.pdf --
Techniques for traversing NAT with TCP peer to peer, includes a
implementation in C.
Re: sketches
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Patrick Wright wrote:
> I personally think that the concurrency libraries in 1.5 are a good
> reason to move to 1.5 as a minimum. And personally I'm in favor of 1.6
> now that 1.5 has been EOL'd.
+1
Gr. Sim
Re: sketches
Posted by Patrick Wright <pd...@gmail.com>.
On Sat, Feb 6, 2010 at 4:10 PM, Christopher Dolan
<ch...@avid.com> wrote:
> Honest question: considering that Sun end-of-lifed Java 1.5 back in
> October 2009, what's the value in continuing to support the Java 1.4
> platform in River?
We discussed this on the list awhile back. I was of the opinion that
in Jini was oriented towards communication between all sorts of
Java-enabled devices, including high-end servers on the one end and
mobile and embedded devices on the other. Hence if it were important
to the community to support the SDK on devices that didn't include 1.5
features, we should continue to support 1.4.
However, the discussion on that thread indicated there weren't really
strong advocates for keeping 1.4 support. I was raising it more as an
item to discuss and make a decision about, specifically regarding Jini
compatibility across the wider Java VM landscape; we ourselves use
Jini in a server environment, already 1.6 across the board for several
years now and low-end devices aren't in our game plan at all.
I personally think that the concurrency libraries in 1.5 are a good
reason to move to 1.5 as a minimum. And personally I'm in favor of 1.6
now that 1.5 has been EOL'd.
Patrick
Re: River Core Platform [was: Re: sketches]
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> Christopher Dolan wrote:
>>> Honest question: considering that Sun end-of-lifed Java 1.5 back in
>>> October 2009, what's the value in continuing to support the Java 1.4
>>> platform in River?
>>>
>> Honest Answer: Just a few billion blue ray players, set top boxes and
>> multifunction network printers and any other device that run Java cdc.
>
> Shall we go for a full use of JDK6 facilities, with a pre-processor to
> create a (or multiple) minimal version?
Might as well, you might want to consider supporting 1.4 with any proxy
code, your choice though. Feel free to use generics. You can still use
@Override too. In other words, the server side service is free to use
those features.
We need to consider what the minimum requirements are to consume or
export a Jini service. (Protocols, classes) and make that the core
platform, that has to support Java 1.4.
From there it would be recommended to make smart proxy classes and
Service Interfaces Java 1.4 compliant, however use later Language
classes where it makes sense to do so. We need to annotate the class
version (bytecode) and Package version into MarshalledInstance to ensure
non compatible clients and servers aren't mixed.
Cheers,
Peter.
>
> We can prototype this with a ant/sed/awk script, We could strip the
> @overrides, selectively include JDK6 dependend facilities, etc.
>
Wouldn't worry about it just yet, lets see how we go first.
Retrotanslator can convert Java 5 Bytecode, however it needs custom
Object Marshallers Input Output Streams written for serialization
support. It does support Annotations, Generics and the Concurrent
Utilities.
JSR14 seems are more sensible option to begin with.
> Really, i do sometimes miss something like the C preprocessor, in
> order to postprocess for different deployment scenarios. A //#ifdef
> maybe?
>
> Gr. Sim
>
Re: River Core Platform [was: Re: sketches]
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Peter Firmstone wrote:
> Christopher Dolan wrote:
>> Honest question: considering that Sun end-of-lifed Java 1.5 back in
>> October 2009, what's the value in continuing to support the Java 1.4
>> platform in River?
>>
> Honest Answer: Just a few billion blue ray players, set top boxes and
> multifunction network printers and any other device that run Java cdc.
Shall we go for a full use of JDK6 facilities, with a pre-processor to
create a (or multiple) minimal version?
We can prototype this with a ant/sed/awk script, We could strip the
@overrides, selectively include JDK6 dependend facilities, etc.
Really, i do sometimes miss something like the C preprocessor, in order
to postprocess for different deployment scenarios. A //#ifdef maybe?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: River Core Platform [was: Re: sketches]
Posted by Peter Firmstone <ji...@zeus.net.au>.
That's good news Bob, heartwarming news actually. I truly hope both of
you are able to participate.
Thank you & Welcome to Apache River,
Peter.
Bob Craig wrote:
> Peter,
>
> I just wanted to chime in privately to pass on two things. 1) I and Chris are both grateful to see the leadership you are providing to River after a long period after Sun dropped active involvement. We are both heavily committed to Jini within our Corporate environment and appreciate the fact that the "community" is coming alive with your leadership.
>
> 2) Chris is a solid "open-source" citizen (he is active in several other open-source projects) and sincerely wants to contribute back to River in whatever way he can (he has discussed it with me personally). The work we've done on the Jini codestream internally is something that Chris wants to contribute back - I am working through the Corporate hoops that we need to jump through here at Avid to get official sign-off to make that happen (and have our asses covered).
>
> Bob Craig
> Avid Technology
>
>
>
> ________________________________
>
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Sat 2/6/2010 5:19 PM
> To: river-dev@incubator.apache.org
> Subject: River Core Platform [was: Re: sketches]
>
>
>
> Christopher Dolan wrote:
>
>> Honest question: considering that Sun end-of-lifed Java 1.5 back in
>> October 2009, what's the value in continuing to support the Java 1.4
>> platform in River?
>>
>>
> Honest Answer: Just a few billion blue ray players, set top boxes and
> multifunction network printers and any other device that run Java cdc.
>
> Let me make one thing very clear: No code will be rejected because it
> uses a later JAVA version.
>
> What we do need to define is what constitutes the core platform, so that
> when I want to run River on a cdc device, that provides or consumes a
> simple service, I can. Which again highlights another problem,
> modularity, the Jini Specification is supposed to be able to have
> multiple implementations.
>
> I receive an endless stream of resistance about modularity, or
> versioning, every time I try to get the blessing of the River dev list
> to start working towards something, so here I sit doing the menial
> tasks, getting out the new release, posting discussions to river-dev,
> hesitant to make changes in case it turns out to be a wast of my
> valuable time. I have children and have paid work to do also. This
> isn't directed at you Chris, I want to see you participate, I just
> happened to pick up your thread response, it's directed at the list in
> general.
>
> Modularity allows us to have multiple implementations, if we provide a
> Service that uses Java 5 language features and if it's proxy is a smart
> proxy then if that smart proxy also uses Java 5 or later then it isn't
> available to Java 1.4 J2SE or cdc.
>
> However if it is a simple reflective proxy with typical classes it's
> bytecode is generated dynamically at runtime.
>
> We need a way to annotate what Java Version a Service provides, well
> that's what you call modularity, it should be handled for you
> automatically by the River platform, it can be annotated in
> MarshalledObject.
>
>
> Compatibility Checkers
>
> Some tools used by Apache projects:
>
> * Java
> o Clirr <http://clirr.sourceforge.net//> works on binaries
> o JDiff <http://jdiff.sourceforge.net/> uses sources
>
>
> Once a core platform has been decided upon, then that is all we check
> for Java 1.4 compatibility and those that want the Java 1.4 platform
> support are obliged to maintain that compatibility, namely me, but it
> was me that pushed later Java language feature support in the first
> place and still support it, I want as large an adoption and user pool as
> possible.
>
> So if we put the effort into defining just what the minimum requirements
> are for producing or consuming a basic service, we have the core
> platform, this can then be a small download.
>
> Eg, the JERI Relay service that Sim is working on is not part of the
> core platform, why not take advantage of the Concurrency libraries?
> Reggie Services shouldn't be restricted either, you wouldn't provide a
> Reggie service with java cdc, however it's proxy stub would need to be
> compiled with the -jsr1.4 option. (Actually Reggie still uses rmic, we
> need to convert to JERI)
>
> NO CODE WILL BE REJECTED BECAUSE IT USES LATER JAVA LANGUAGE FEATURES
>
> If you want to prove to yourself the -jsr14 compiler option works, edit
> build.xml, add the option, use JDK1.6 to compile the current codebase
> and specify source=5 instead of 1.4.
>
> I'm actually starting to wonder if we need two Releases of Apache River:
>
> 1. River for Trusted Intranet Networks
> 2. River for Untrusted Networks
>
> Both could use the same core platform, one would be secure by default
> and require more configuration, the other simple, with few concerns
> about security, or codebase evolution (Preffered Class loading
> mechanisms will suffice).
>
> BR Peter.
>
>> I've found it to be tricky to avoid using new methods when striving for
>> backward runtime compatibility. Extensive unit testing or static
>> analysis are the only ways to ensure you've found all the problems,
>> since the compiler won't help you.
>>
>> Googling for "-target jsr14" revealed this less-than-inspiring quote:
>> "It is convenient, if unsupported, and the compiler generates mostly
>> compatible bytecode in a single pass."
>> http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>>
>>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au]
>> Sent: Friday, February 05, 2010 5:16 PM
>> To: river-dev@incubator.apache.org
>> Subject: Re: sketches
>>
>> Yes, Java 5 language features next release.
>>
>> Although I'd like to find just what our core jini platform should be and
>>
>> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>>
>> In that core platform, we couldn't use any new methods or libraries not
>> in Java 1.4, however we could use generics.
>>
>> So for instance the Java cdc platform can consume and provide simple
>> services.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>>
>
>
>
>
>
RE: River Core Platform [was: Re: sketches]
Posted by Bob Craig <bo...@avid.com>.
Peter,
I just wanted to chime in privately to pass on two things. 1) I and Chris are both grateful to see the leadership you are providing to River after a long period after Sun dropped active involvement. We are both heavily committed to Jini within our Corporate environment and appreciate the fact that the "community" is coming alive with your leadership.
2) Chris is a solid "open-source" citizen (he is active in several other open-source projects) and sincerely wants to contribute back to River in whatever way he can (he has discussed it with me personally). The work we've done on the Jini codestream internally is something that Chris wants to contribute back - I am working through the Corporate hoops that we need to jump through here at Avid to get official sign-off to make that happen (and have our asses covered).
Bob Craig
Avid Technology
________________________________
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Sat 2/6/2010 5:19 PM
To: river-dev@incubator.apache.org
Subject: River Core Platform [was: Re: sketches]
Christopher Dolan wrote:
> Honest question: considering that Sun end-of-lifed Java 1.5 back in
> October 2009, what's the value in continuing to support the Java 1.4
> platform in River?
>
Honest Answer: Just a few billion blue ray players, set top boxes and
multifunction network printers and any other device that run Java cdc.
Let me make one thing very clear: No code will be rejected because it
uses a later JAVA version.
What we do need to define is what constitutes the core platform, so that
when I want to run River on a cdc device, that provides or consumes a
simple service, I can. Which again highlights another problem,
modularity, the Jini Specification is supposed to be able to have
multiple implementations.
I receive an endless stream of resistance about modularity, or
versioning, every time I try to get the blessing of the River dev list
to start working towards something, so here I sit doing the menial
tasks, getting out the new release, posting discussions to river-dev,
hesitant to make changes in case it turns out to be a wast of my
valuable time. I have children and have paid work to do also. This
isn't directed at you Chris, I want to see you participate, I just
happened to pick up your thread response, it's directed at the list in
general.
Modularity allows us to have multiple implementations, if we provide a
Service that uses Java 5 language features and if it's proxy is a smart
proxy then if that smart proxy also uses Java 5 or later then it isn't
available to Java 1.4 J2SE or cdc.
However if it is a simple reflective proxy with typical classes it's
bytecode is generated dynamically at runtime.
We need a way to annotate what Java Version a Service provides, well
that's what you call modularity, it should be handled for you
automatically by the River platform, it can be annotated in
MarshalledObject.
Compatibility Checkers
Some tools used by Apache projects:
* Java
o Clirr <http://clirr.sourceforge.net//> works on binaries
o JDiff <http://jdiff.sourceforge.net/> uses sources
Once a core platform has been decided upon, then that is all we check
for Java 1.4 compatibility and those that want the Java 1.4 platform
support are obliged to maintain that compatibility, namely me, but it
was me that pushed later Java language feature support in the first
place and still support it, I want as large an adoption and user pool as
possible.
So if we put the effort into defining just what the minimum requirements
are for producing or consuming a basic service, we have the core
platform, this can then be a small download.
Eg, the JERI Relay service that Sim is working on is not part of the
core platform, why not take advantage of the Concurrency libraries?
Reggie Services shouldn't be restricted either, you wouldn't provide a
Reggie service with java cdc, however it's proxy stub would need to be
compiled with the -jsr1.4 option. (Actually Reggie still uses rmic, we
need to convert to JERI)
NO CODE WILL BE REJECTED BECAUSE IT USES LATER JAVA LANGUAGE FEATURES
If you want to prove to yourself the -jsr14 compiler option works, edit
build.xml, add the option, use JDK1.6 to compile the current codebase
and specify source=5 instead of 1.4.
I'm actually starting to wonder if we need two Releases of Apache River:
1. River for Trusted Intranet Networks
2. River for Untrusted Networks
Both could use the same core platform, one would be secure by default
and require more configuration, the other simple, with few concerns
about security, or codebase evolution (Preffered Class loading
mechanisms will suffice).
BR Peter.
> I've found it to be tricky to avoid using new methods when striving for
> backward runtime compatibility. Extensive unit testing or static
> analysis are the only ways to ensure you've found all the problems,
> since the compiler won't help you.
>
> Googling for "-target jsr14" revealed this less-than-inspiring quote:
> "It is convenient, if unsupported, and the compiler generates mostly
> compatible bytecode in a single pass."
> http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>
>
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Friday, February 05, 2010 5:16 PM
> To: river-dev@incubator.apache.org
> Subject: Re: sketches
>
> Yes, Java 5 language features next release.
>
> Although I'd like to find just what our core jini platform should be and
>
> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>
> In that core platform, we couldn't use any new methods or libraries not
> in Java 1.4, however we could use generics.
>
> So for instance the Java cdc platform can consume and provide simple
> services.
>
> Cheers,
>
> Peter.
>
>
River Core Platform [was: Re: sketches]
Posted by Peter Firmstone <ji...@zeus.net.au>.
Christopher Dolan wrote:
> Honest question: considering that Sun end-of-lifed Java 1.5 back in
> October 2009, what's the value in continuing to support the Java 1.4
> platform in River?
>
Honest Answer: Just a few billion blue ray players, set top boxes and
multifunction network printers and any other device that run Java cdc.
Let me make one thing very clear: No code will be rejected because it
uses a later JAVA version.
What we do need to define is what constitutes the core platform, so that
when I want to run River on a cdc device, that provides or consumes a
simple service, I can. Which again highlights another problem,
modularity, the Jini Specification is supposed to be able to have
multiple implementations.
I receive an endless stream of resistance about modularity, or
versioning, every time I try to get the blessing of the River dev list
to start working towards something, so here I sit doing the menial
tasks, getting out the new release, posting discussions to river-dev,
hesitant to make changes in case it turns out to be a wast of my
valuable time. I have children and have paid work to do also. This
isn't directed at you Chris, I want to see you participate, I just
happened to pick up your thread response, it's directed at the list in
general.
Modularity allows us to have multiple implementations, if we provide a
Service that uses Java 5 language features and if it's proxy is a smart
proxy then if that smart proxy also uses Java 5 or later then it isn't
available to Java 1.4 J2SE or cdc.
However if it is a simple reflective proxy with typical classes it's
bytecode is generated dynamically at runtime.
We need a way to annotate what Java Version a Service provides, well
that's what you call modularity, it should be handled for you
automatically by the River platform, it can be annotated in
MarshalledObject.
Compatibility Checkers
Some tools used by Apache projects:
* Java
o Clirr <http://clirr.sourceforge.net//> works on binaries
o JDiff <http://jdiff.sourceforge.net/> uses sources
Once a core platform has been decided upon, then that is all we check
for Java 1.4 compatibility and those that want the Java 1.4 platform
support are obliged to maintain that compatibility, namely me, but it
was me that pushed later Java language feature support in the first
place and still support it, I want as large an adoption and user pool as
possible.
So if we put the effort into defining just what the minimum requirements
are for producing or consuming a basic service, we have the core
platform, this can then be a small download.
Eg, the JERI Relay service that Sim is working on is not part of the
core platform, why not take advantage of the Concurrency libraries?
Reggie Services shouldn't be restricted either, you wouldn't provide a
Reggie service with java cdc, however it's proxy stub would need to be
compiled with the -jsr1.4 option. (Actually Reggie still uses rmic, we
need to convert to JERI)
NO CODE WILL BE REJECTED BECAUSE IT USES LATER JAVA LANGUAGE FEATURES
If you want to prove to yourself the -jsr14 compiler option works, edit
build.xml, add the option, use JDK1.6 to compile the current codebase
and specify source=5 instead of 1.4.
I'm actually starting to wonder if we need two Releases of Apache River:
1. River for Trusted Intranet Networks
2. River for Untrusted Networks
Both could use the same core platform, one would be secure by default
and require more configuration, the other simple, with few concerns
about security, or codebase evolution (Preffered Class loading
mechanisms will suffice).
BR Peter.
> I've found it to be tricky to avoid using new methods when striving for
> backward runtime compatibility. Extensive unit testing or static
> analysis are the only ways to ensure you've found all the problems,
> since the compiler won't help you.
>
> Googling for "-target jsr14" revealed this less-than-inspiring quote:
> "It is convenient, if unsupported, and the compiler generates mostly
> compatible bytecode in a single pass."
> http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>
>
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Friday, February 05, 2010 5:16 PM
> To: river-dev@incubator.apache.org
> Subject: Re: sketches
>
> Yes, Java 5 language features next release.
>
> Although I'd like to find just what our core jini platform should be and
>
> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>
> In that core platform, we couldn't use any new methods or libraries not
> in Java 1.4, however we could use generics.
>
> So for instance the Java cdc platform can consume and provide simple
> services.
>
> Cheers,
>
> Peter.
>
>
Re: sketches
Posted by Peter Firmstone <ji...@zeus.net.au>.
The converse is, that we just have a copy of the complete API for the
Java CDC foundation profile, collected using static analysis and compare
against it. That copy might just be the serialised form of the
dependency analysis results.
As per your suggestion, Static analysis is the way to go, might also
need to copy a subset of the qa tests for testing the core river
platform on Java CDC.
Cheers,
Peter.
Peter Firmstone wrote:
> Christopher Dolan wrote:
>> Honest question: considering that Sun end-of-lifed Java 1.5 back in
>> October 2009, what's the value in continuing to support the Java 1.4
>> platform in River?
>>
>> I've found it to be tricky to avoid using new methods when striving for
>> backward runtime compatibility. Extensive unit testing or static
>> analysis are the only ways to ensure you've found all the problems,
>> since the compiler won't help you.
>>
> Hi Chris,
>
> I've been considering the above, we have a tool called ClassDep,
> (ClassDepend - the implementation) that uses the ASM bytecode library
> to perform dependency analysis. One of the options -edges picks up
> dependencies between packages. Now we currently don't have a way of
> showing all the methods etc, however every static dependency link is
> analyzed, I have thought about recording all the API signatures from
> the dependencies. We can perform an analysis using clrr to find the
> unsupported methods in Java Foundation Profile, in comparison to Java
> 1.6 (I thought about J2SE 1.4.2, but I think 6 is more appropriate).
> The results of this analysis can be stored in the trunk on svn.
>
> Once we have a baseline on what classes or methods cannot be used,
> we'll want to provide an ant build task that finds any illegal API
> with ClassDepend, only the River core component that supports the Java
> Foundation Profile, will be checked, we can still utilise generics and
> some other Java 5 Language features in this core component.
>
> We can then make our ClassDepend tool available for checking Service
> Interfaces and Smart Proxy compatibility with Foundation Profile.
> This would only apply to the client side.
>
> People wishing to create a service for Foundation Profile would need
> to use the Java ME SDK
>
> People that don't want to support Foundation Profile, need not concern
> themselves.
>
> As I said this would only apply to the very core of Apache River, the
> absolute minimum requirement to produce and consume a service, that
> would of course include some parts of JERI. We'll need ways of
> managing compatibility information at runtime, by annotating the
> bytecode version and package metadata into our MarshalledObjInstance.
> So services aren't matched by platforms that cannot support them.
>
> More investigation is required, will keep you posted.
>
> Cheers,
>
> Peter.
>
>
>
>
>> Googling for "-target jsr14" revealed this less-than-inspiring quote:
>> "It is convenient, if unsupported, and the compiler generates mostly
>> compatible bytecode in a single pass."
>> http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>>
>>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Friday,
>> February 05, 2010 5:16 PM
>> To: river-dev@incubator.apache.org
>> Subject: Re: sketches
>>
>> Yes, Java 5 language features next release.
>>
>> Although I'd like to find just what our core jini platform should be and
>>
>> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>>
>> In that core platform, we couldn't use any new methods or libraries
>> not in Java 1.4, however we could use generics.
>>
>> So for instance the Java cdc platform can consume and provide simple
>> services.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
>
Re: sketches
Posted by Peter Firmstone <ji...@zeus.net.au>.
Christopher Dolan wrote:
> Honest question: considering that Sun end-of-lifed Java 1.5 back in
> October 2009, what's the value in continuing to support the Java 1.4
> platform in River?
>
> I've found it to be tricky to avoid using new methods when striving for
> backward runtime compatibility. Extensive unit testing or static
> analysis are the only ways to ensure you've found all the problems,
> since the compiler won't help you.
>
Hi Chris,
I've been considering the above, we have a tool called ClassDep,
(ClassDepend - the implementation) that uses the ASM bytecode library to
perform dependency analysis. One of the options -edges picks up
dependencies between packages. Now we currently don't have a way of
showing all the methods etc, however every static dependency link is
analyzed, I have thought about recording all the API signatures from the
dependencies. We can perform an analysis using clrr to find the
unsupported methods in Java Foundation Profile, in comparison to Java
1.6 (I thought about J2SE 1.4.2, but I think 6 is more appropriate).
The results of this analysis can be stored in the trunk on svn.
Once we have a baseline on what classes or methods cannot be used, we'll
want to provide an ant build task that finds any illegal API with
ClassDepend, only the River core component that supports the Java
Foundation Profile, will be checked, we can still utilise generics and
some other Java 5 Language features in this core component.
We can then make our ClassDepend tool available for checking Service
Interfaces and Smart Proxy compatibility with Foundation Profile. This
would only apply to the client side.
People wishing to create a service for Foundation Profile would need to
use the Java ME SDK
People that don't want to support Foundation Profile, need not concern
themselves.
As I said this would only apply to the very core of Apache River, the
absolute minimum requirement to produce and consume a service, that
would of course include some parts of JERI. We'll need ways of managing
compatibility information at runtime, by annotating the bytecode version
and package metadata into our MarshalledObjInstance. So services aren't
matched by platforms that cannot support them.
More investigation is required, will keep you posted.
Cheers,
Peter.
> Googling for "-target jsr14" revealed this less-than-inspiring quote:
> "It is convenient, if unsupported, and the compiler generates mostly
> compatible bytecode in a single pass."
> http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
>
>
> Chris
>
> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au]
> Sent: Friday, February 05, 2010 5:16 PM
> To: river-dev@incubator.apache.org
> Subject: Re: sketches
>
> Yes, Java 5 language features next release.
>
> Although I'd like to find just what our core jini platform should be and
>
> compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
>
> In that core platform, we couldn't use any new methods or libraries not
> in Java 1.4, however we could use generics.
>
> So for instance the Java cdc platform can consume and provide simple
> services.
>
> Cheers,
>
> Peter.
>
>
RE: sketches
Posted by Christopher Dolan <ch...@avid.com>.
Honest question: considering that Sun end-of-lifed Java 1.5 back in
October 2009, what's the value in continuing to support the Java 1.4
platform in River?
I've found it to be tricky to avoid using new methods when striving for
backward runtime compatibility. Extensive unit testing or static
analysis are the only ways to ensure you've found all the problems,
since the compiler won't help you.
Googling for "-target jsr14" revealed this less-than-inspiring quote:
"It is convenient, if unsupported, and the compiler generates mostly
compatible bytecode in a single pass."
http://twit88.com/blog/2008/08/26/java-understanding-jsr14/
Chris
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: Friday, February 05, 2010 5:16 PM
To: river-dev@incubator.apache.org
Subject: Re: sketches
Yes, Java 5 language features next release.
Although I'd like to find just what our core jini platform should be and
compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
In that core platform, we couldn't use any new methods or libraries not
in Java 1.4, however we could use generics.
So for instance the Java cdc platform can consume and provide simple
services.
Cheers,
Peter.
Re: sketches
Posted by Peter Firmstone <ji...@zeus.net.au>.
Yes, Java 5 language features next release.
Although I'd like to find just what our core jini platform should be and
compile it with -jsr14 to produce Java 1.4 bytecode from Java 5 source.
In that core platform, we couldn't use any new methods or libraries not
in Java 1.4, however we could use generics.
So for instance the Java cdc platform can consume and provide simple
services.
Cheers,
Peter.
> Did I hear Peter say that Java 1.5 is a goal for post-River 2.1.2? If
> so, it's a fairly simple chore to change 1.6 code to work with 1.5. The
> biggest changes that get me in trouble when I switch between the two
> versions are @Override, String.isEmpty(), and a few Swing changes
> (JTable, etc).
>
> Chris
>
> -----Original Message-----
> From: Sim IJskes - QCG [mailto:sim@qcg.nl]
> Sent: Friday, February 05, 2010 2:24 AM
> To: river-dev@incubator.apache.org
> Subject: Re: sketches
>
> Can i use @override and the collections framework? At least for the
> prototyping stage? If it works out, i can donate the code to the ASF and
>
> the committers can put it in a contrib directory, with the specific
> remark that it only compiles with jdk6.
>
>
RE: sketches
Posted by Christopher Dolan <ch...@avid.com>.
If you use @Override only on methods that overload superclass methods
and not on methods that implement interface methods, then it will likely
work on JDK5, and the JDK6 dependency will not be needed. The java.util
collections API barely changed at all between 5 and 6.
Did I hear Peter say that Java 1.5 is a goal for post-River 2.1.2? If
so, it's a fairly simple chore to change 1.6 code to work with 1.5. The
biggest changes that get me in trouble when I switch between the two
versions are @Override, String.isEmpty(), and a few Swing changes
(JTable, etc).
Chris
-----Original Message-----
From: Sim IJskes - QCG [mailto:sim@qcg.nl]
Sent: Friday, February 05, 2010 2:24 AM
To: river-dev@incubator.apache.org
Subject: Re: sketches
Can i use @override and the collections framework? At least for the
prototyping stage? If it works out, i can donate the code to the ASF and
the committers can put it in a contrib directory, with the specific
remark that it only compiles with jdk6.
Re: sketches
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Peter Firmstone wrote:
> Cool, once you've got your ProxiedEndpoint, can I do the Serialized form
> for you?
>
> Cheers,
>
> Peter.
Sorry, but i'm ahead of you! :-) No, just kidding!
I've prefixed everything with Relay. Right now i've got.
MsgConnection.java
MsgOutboundRequest.java
RelayConnectionManager.java
RelayEndpointImpl.java
RelayEndpoint.java
RelayServiceImpl.java
RelayService.java
I've delegated the functionality from RelayEndpoint to
RelayEndpointImpl. Generalized the OutboundRequest function to
MsgOutboundRequest, Which is generic byte array oriented. It works
together with an interface MsgConnection wich is the base for the
RelayConnectionManager.
Can i use @override and the collections framework? At least for the
prototyping stage? If it works out, i can donate the code to the ASF and
the committers can put it in a contrib directory, with the specific
remark that it only compiles with jdk6.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: sketches
Posted by Peter Firmstone <ji...@zeus.net.au>.
Cool, once you've got your ProxiedEndpoint, can I do the Serialized form
for you?
Cheers,
Peter.
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> Ok sounds interesting, lets work together, we need both types of
>> functionality, one for scalibility and the other for reliability, if
>> NAT p2p TCP fails we need to fall back on a routing service.
>
> I've a few notes:
>
> interface TransportService
> extends Remote
> {
> MsgBlock poll();
>
> void send( MsgBlock mb );
> }
>
> This is to support bidirectional message flow. (think bosh).
>
> class ProxiedEndpoint
> implements Serializable
> {
> private SomeId id ;
>
> private Endpoint transportEndpoint ;
>
> ProxyEndpoint( SomeId id, Endpoint transportEndpoint )
> {
> ...
> }
> }
>
> This is for the implementation and registration.
>
> interface ProxyServer
> extends Remote
> {
> ProxiedEndpoint createEndpoint();
> }
>
> Gr. Sim
>
sketches
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Peter Firmstone wrote:
> Ok sounds interesting, lets work together, we need both types of
> functionality, one for scalibility and the other for reliability, if NAT
> p2p TCP fails we need to fall back on a routing service.
I've a few notes:
interface TransportService
extends Remote
{
MsgBlock poll();
void send( MsgBlock mb );
}
This is to support bidirectional message flow. (think bosh).
class ProxiedEndpoint
implements Serializable
{
private SomeId id ;
private Endpoint transportEndpoint ;
ProxyEndpoint( SomeId id, Endpoint transportEndpoint )
{
...
}
}
This is for the implementation and registration.
interface ProxyServer
extends Remote
{
ProxiedEndpoint createEndpoint();
}
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: Implementing means to allow NAT-ed clients to provide services
[was roadmap]
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok sounds interesting, lets work together, we need both types of
functionality, one for scalibility and the other for reliability, if NAT
p2p TCP fails we need to fall back on a routing service.
As soon as the latest release is approved, we're free to work on the
codebase again. I've got Concurrent library replacements for Policy,
Permissions, including a wrapper object for a PermissionCollection that
allows multi reads, but locks on write (ReentrantReadWriteLock) that I'd
like to add to the codebase to fix some of the problems Gregg has been
experiencing with the single thread synchronization of the JAVA platform
implementations.
In my library, it is advantageous not to add any synchronization code to
a PermissionCollection (unless it mutates on read), the JAVA
implementation of Permissions uses synchronisation anyway (albeit
poorly) so PermissionCollection should have never been required to be
synchronized. A Parallel to Vector, ArrayList and the Collections
libraries.
I also have a Concurrent Weak Hash map utility library.
Cheers,
Peter.
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> I would like to start by implementing the Natblaster technique of
>> traversing NAT's with TCP, using JAVA. I'm not 100% how to fit this
>> in with JERI, however the following classes appear relevant.
>
> For my deployment i'm going to prototype a (Server)Endpoint factory as
> a jini service. clients behind NAT can expose their services within
> the scope of this factory. I'm not so worried about the performance.
>
> For me it's the shortest path to fullfill my requirements.
>
> Maybe it works... :-)
>
> Gr. Sim
>
Re: Implementing means to allow NAT-ed clients to provide services
[was roadmap]
Posted by Sim IJskes - QCG <si...@qcg.nl>.
Peter Firmstone wrote:
> I would like to start by implementing the Natblaster technique of
> traversing NAT's with TCP, using JAVA. I'm not 100% how to fit this in
> with JERI, however the following classes appear relevant.
For my deployment i'm going to prototype a (Server)Endpoint factory as a
jini service. clients behind NAT can expose their services within the
scope of this factory. I'm not so worried about the performance.
For me it's the shortest path to fullfill my requirements.
Maybe it works... :-)
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: Implementing means to allow NAT-ed clients to provide services
[was roadmap]
Posted by Peter Firmstone <ji...@zeus.net.au>.
The initial implementation will include the URL of the relevant ICMS,
however I'd like to make the location of the ICMS discoverable using
lookup so the ICMS location can change over time.
Peter Firmstone wrote:
> Hi Sim & Gregg,
>
> I just wanted to break this issue out of the original thread and
> summarise our findings to provide a way forward, for solving one of
> the original questions posed.
>
> I want the implementation to be invisible to existing client and
> service implementation and to just work.
>
> I would like to start by implementing the Natblaster technique of
> traversing NAT's with TCP, using JAVA. I'm not 100% how to fit this
> in with JERI, however the following classes appear relevant.
>
> * net.jini.jeri.connection.ServerConnectionManager
> * net.jini.jeri.connection.ConnectionManager
>
>
> I will need new ServerEndpoint and Endpoint implementations, some
> observations:
>
> * The Server will need to be aware of the Client's Public NAT IP
> Address and recieve port.
> * The Client will need to be aware of the Server's Public NAT IP
> Address and recieve port.
> * A public service will need to be provided - Initial Connection
> Mediator Service (ICMS)?
> * The Client will need to contact the Initial Connection Mediator
> Service and request a connection to a Nat-ed Service. This would
> need to be performed as an implementation detail of the
> Endpoint.newRequest() method.
> * The NAT-ed Service would need to be listening using the
> ServerEndpoint implementation, which would be polling the ICMS to
> maintain a connection.
> * The ServerEndpoint implementation would listen for and intercept
> connection negotiation requests.
> * The ServerEndpoint implementation would pass the communication
> through to the callback object once the connection is established.
> * Once a connection session was negotiated successfully, the client
> Endpoint.newRequest() method would return.
> * TLS will need to be utilised.
>
>
> Any helpful advise would be much appreciated, this should allow the
> marshalled object to find it's way home.
>
> BR,
>
> Peter.
>
> Resources:
>
> * http://netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html --
> Multi Platform Java library for reading and writing packets, java
> equivalent of libpcap and libnet.
> * http://natblaster.sourceforge.net/paper/natblaster.pdf --
> Techniques for traversing NAT with TCP peer to peer, includes a
> implementation in C.
>
>
>
>