Well that's something. A good something! Fingers cross on the QA tests. I'm just about to sign off now, but please check the deletions into the trunk if/when you're happy with them and I'll create some new RCs.
If only all fixes were as simple. On Wed, Jun 29, 2011 at 9:56 PM, Patricia Shanahan <p...@acm.org> 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >