Over 250 tests passed with no failures. Meanwhile, I've done some
grepping, and found one use, in a text file:
more
./qa/src/com/sun/jini/test/impl/reggie/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor
com.sun.jini.test.impl.reggie.NameServiceDescriptorImpl
The file has been around since the original Sun contribution, and the
log entries since then seem to be about the various reorganizations, so
I still don't know the purpose.
If this reminds anyone of any clues as to the purpose, please comment.
Patricia
On 6/29/2011 1:56 PM, Patricia Shanahan wrote:
I've done a clean build with the classes in question deleted. It got a
"BUILD SUCCESSFUL". I'll start the QA tests that way, but I suggest
making that change. (I'm not checking in anything to the trunk right
now, to avoid risk of tripping up your efforts).
Patricia
On 6/29/2011 1:07 PM, Tom Hobbs wrote:
I've just done a quick search for uses of NameServiceImpl and the only
thing I could find was in NameServiceDescriptorImpl. And I couldn't
find any references for that.
Given that the package is "com.sun.jini.test.impl.reggie" for both of
these classes, can I assume that they're for some test only? Does
anyone know what they're for? Can we just remove them? (I love
deleting code!)
I'm sure you guys are aware of the problem, but for anyone new to the
party; NameServiceImpl implements NameService which is an *internal*
Sun class, which by rights we shouldn't really be using anyway. The
return type of a the lookupAllHostAddr method differs from Java 5 to
6, so we're unable to build a release that satisfies both Java
versions.
If we can't get around this, it looks like we might be stuck at Java 5
and only 5 until we come up with something clever.
This is disappointing because I was hoping to build some new release
candidates tonight...
Thoughts?
Tom
On Wed, Jun 29, 2011 at 3:41 AM, Peter<j...@zeus.net.au> wrote:
We have a number of uses of internal sun impl classes, I'd agree they
should all be replaced so we can expand beyond the sun
implementation. Is there a related jira?
If you can see a simple fix eliminating the sun dependency, go for
it, otherwise I think just fix it enough to get our release out.
I hadn't given it further consideration last time I looked.
Cheers,
Peter.
----- Original message -----
I think the problem may go deeper. sun.net.spi.nameservice.NameService
is a sun.net interface that can change from version to version. Is it
essential that we have our own implementation?
Patricia
On 6/28/2011 12:18 AM, Peter wrote:
Oops, I fixed that but didn't commit, sorry Not near my dev box,
but the fix
is relatively simple, get byte array from each InetAddress, and return
byte[][] instead, can someone fix it?
----- Original message -----
I downloaded the source, and tried a naive build on Windows XP,
Cygwin.
I put a JDK 1.5 bin directory at the start of my path, and ran "ant
all.build". It failed with the following errors:
compile:
[javac] Compiling 1993 source files to C:\Documents and
Settings\Administrator\My
Documents\River_2.2\apache-river-2.2.0-src\apache-river-2.2.0\qa\build\classes
[javac] C:/Documents and Settings/Administrator/My
Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:29:
com.sun.jini.test.impl.reggie.NameServiceImpl is not abstract and
does
not override abstract method lookupAllHostAddr(java.lang.String) in
sun.net.spi.nameservice.NameService
[javac] public class NameServiceImpl implements NameService {
[javac] ^
[javac] C:/Documents and Settings/Administrator/My
Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:42:
lookupAllHostAddr(java.lang.String) in
com.sun.jini.test.impl.reggie.NameServiceImpl cannot implement
lookupAllHostAddr(java.lang.String) in
sun.net.spi.nameservice.NameService; attempting to use incompatible
return type
[javac] found : java.net.InetAddress[]
[javac] required: byte[][]
[javac] public InetAddress[] lookupAllHostAddr(String host)
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
(I'm not worried about the deprecated APIs, just the compile
failures.)
I next tried to find instructions. I looked at
src-doc/static/build.html. It says "The bin directory of the
Java(TM) 2
SDK, Standard Edition, v 1.4 (or later) must be in your executable
search path."
I believe we now need 1.5 or later.
Patricia
