Modular InetAddress
Hi,
here is a quick patch to be able to have a modular getHostByName and a
getHostByAddr.
To change implementation the user has just to provide a property
gnu.java.net.dns
containing the full class name of an implementation.
I hope that it's fine for you even though I introduce a slight overhead when
solving because I don't use static method anymore for getHostByName and
getHostByAddr.
Cheers,
Guilhem.
P.S.: This is against classpath 2003-10-26.
ChangeLog entry:
2003-10-26 Guilhem Lavaux [EMAIL PROTECTED]
* java/net/InetAddress.java:
(clinit) check the system property gnu.java.net.dns and change
implementation accordingly
(getHostName, getAllByName) use the implementation to solve
name and address.
* gnu/java/net/InetAddressImpl.java:
new interface for modular DNS.
* gnu/java/net/SysInetAddressImpl.java:
DNS solver using native system call.
* native/jni/java-net/java_net_InetAddress.c,
native/jni/java-net/gnu_java_net_SysInetAddressImpl.c:
moved the implementation of getHostByAddr and getHostByName
from java.net.InetAddress to gnu.java.net.SysInetAddressImpl.
Index: gnu/java/net/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/gnu/java/net/Makefile.am,v
retrieving revision 1.6
diff -u -r1.6 Makefile.am
--- gnu/java/net/Makefile.am9 Oct 2003 16:04:22 - 1.6
+++ gnu/java/net/Makefile.am26 Oct 2003 07:55:35 -
@@ -5,5 +5,7 @@
EXTRA_DIST = \
HeaderFieldHelper.java \
PlainDatagramSocketImpl.java \
-PlainSocketImpl.java
+PlainSocketImpl.java \
+InetAddressImpl.java \
+SysInetAddressImpl.java
Index: java/net/InetAddress.java
===
RCS file: /cvsroot/classpath/classpath/java/net/InetAddress.java,v
retrieving revision 1.28
diff -u -r1.28 InetAddress.java
--- java/net/InetAddress.java 9 Oct 2003 15:59:56 - 1.28
+++ java/net/InetAddress.java 26 Oct 2003 07:55:37 -
@@ -39,6 +39,7 @@
package java.net;
import gnu.classpath.Configuration;
+import gnu.java.net.InetAddressImpl;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
@@ -114,6 +115,12 @@
*/
private static HashMap cache;
+ /**
+ * Real implementation for DNS resolution. This implementation is specified
+ * at run time.
+ */
+ private static InetAddressImpl impl;
+
static
{
// load the shared library needed for name resolution
@@ -121,7 +128,26 @@
{
System.loadLibrary (javanet);
}
+
+// Initialize DNS implementation
+String dnsImpl = System.getProperty(gnu.java.net.dns);
+if (dnsImpl == null)
+ {
+impl = new gnu.java.net.SysInetAddressImpl();
+ }
+else
+ {
+try
+ {
+impl = (InetAddressImpl) Class.forName(dnsImpl).newInstance();
+ }
+catch (Exception _)
+ {
+impl = new gnu.java.net.SysInetAddressImpl();
+ }
+ }
+
// Look for properties that override default caching behavior
cache_size = Integer.getInteger (gnu.java.net.dns_cache_size,
DEFAULT_CACHE_SIZE).intValue();
@@ -420,7 +446,7 @@
try
{
-hostName = getHostByAddr (addr);
+hostName = impl.getHostByAddr (addr);
return hostName;
}
catch (UnknownHostException e)
@@ -697,7 +723,7 @@
return addresses;
// Not in cache, try the lookup
-byte[][] iplist = getHostByName (hostname);
+byte[][] iplist = impl.getHostByName (hostname);
if (iplist.length == 0)
throw new UnknownHostException (hostname);
@@ -829,26 +855,6 @@
* Returns the value of the special address INADDR_ANY
*/
private static native byte[] lookupInaddrAny() throws UnknownHostException;
-
- /**
- * This method returns the hostname for a given IP address. It will
- * throw an UnknownHostException if the hostname cannot be determined.
- *
- * @param ip The IP address as a int array
- *
- * @return The hostname
- *
- * @exception UnknownHostException If the reverse lookup fails
- */
- private static native String getHostByAddr (byte[] ip)
-throws UnknownHostException;
-
- /**
- * Returns a list of all IP addresses for a given hostname. Will throw
- * an UnknownHostException if the hostname cannot be resolved.
- */
- private static native byte[][] getHostByName (String hostname)
-throws UnknownHostException;
/*
* Needed for serialization.
Index: native/jni/java-net/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/native/jni/java-net/Makefile.am,v
retrieving revision 1.5
diff -u -r1.5 Makefile.am
--- native/jni/java-net/Makefile.am 19 Sep 2003 06:12:39 - 1.5
+++
Re: CVS configure.in is broken
Hi, On Fri, 2003-10-24 at 14:33, Thomas Fitzsimmons wrote: On Fri, 2003-10-24 at 04:31, Dalibor Topic wrote: Anyway, thanks, I'll fetch them just for the macros. Any idea where the macros hide in those packages? They're defined in gtk-2.0.m4, glib-2.0.m4 and libart.m4. Stupid question no 2: why aren't those macros in the CVS archive? They are not generated files, as far as I can tell. Installing gtk2, glib2 and libart just to be able to compile Classpath's java classes with jikes seems like a bit of overkill ;) Yes, I agree. We should probably just check the macro files into Classpath's top-level directory. That's what we've done with libgcj. We should also update the HACKING file to recommend aclocal -I . That should solve the problem. Dalibor, did that do the trick for you? The files that libgcj uses can be found at http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ But I see they don't have a copyright notice or distribution permission. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
Hi, On Sat, 2003-10-25 at 19:43, Dalibor Topic wrote: One of the things I keep stumbling over whenever I merge code from Classpath into Kaffe is the different native library names. Would it be possible to separate those out into their own VMInterface class and use references instead? I'd prefer something like System.loadLibrary(VMNativeLibraries.IO); to what we have now, System.loadLibrary(javaio); I suggest to move the System.loadLibrary(javaio) calls completely into the VMInterface classes. We want to have a system where (at least for lang, net, io and util) we have the native calls in the VMInterface classes. We then provide a reference implementation that implements this with JNI using our own libraries. This will be a bit more work since we still have a few classes that do use native methods which don't have a VMInterface counterpart, but it is the cleanest solution in the long run. One thing that isn't split yet is java.io File and FileDescriptor. But Anthony Green already had a proposal for splitting that up on the libgcj mailinglist (he calls the VMInterface classes, Platform classes, but the idea is the same). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
Hi, On Mon, 2003-10-27 at 13:15, Bryce McKinlay wrote: On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote: I suggest to move the System.loadLibrary(javaio) calls completely into the VMInterface classes. We want to have a system where (at least for lang, net, io and util) we have the native calls in the VMInterface classes. We then provide a reference implementation that implements this with JNI using our own libraries. I don't think that is a good idea. IMO the VMInterface should define the interface to a particular VM, not the entire native interface for all classes. Things like java.net and java.io will typically have the same native interface across different VMs. Could you explain that a bit more? I don't understand why you think having the loadLibrary() call in the same (VMInterface) class as the native methods is not a good idea. Or do you mean that having loadLibrary() calls at all is a bad idea because VMs should just link against our default jni libraries (at least for lang/net/io/util)? The VMInterface classes define all methods that a particular VM might want to/has to implement to get a complete working core libraries implementation. We try to provide default implementations whenever possible in the VMInterface classes. A particular VM/Classpath system is then free to override/reimplement those VMInterface classes to work with their internals and system libraries, or to get more optimal performance then the generic implementations can provide. For VMs that actually use the tradition JNI based native methods we provide implementations that work with the native methods in those VMInterface classes. But VMs that don't use JNI or don't even have a concept of native methods can provide their own VMInterface classes. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: VMInterface addition: Make native library names part of VMInterface
On Oct 27, 2003, at 2:01 PM, Mark Wielaard wrote: On Mon, 2003-10-27 at 13:15, Bryce McKinlay wrote: On Oct 27, 2003, at 1:05 AM, Mark Wielaard wrote: I suggest to move the System.loadLibrary(javaio) calls completely into the VMInterface classes. We want to have a system where (at least for lang, net, io and util) we have the native calls in the VMInterface classes. We then provide a reference implementation that implements this with JNI using our own libraries. I don't think that is a good idea. IMO the VMInterface should define the interface to a particular VM, not the entire native interface for all classes. Things like java.net and java.io will typically have the same native interface across different VMs. Could you explain that a bit more? I don't understand why you think having the loadLibrary() call in the same (VMInterface) class as the native methods is not a good idea. Or do you mean that having loadLibrary() calls at all is a bad idea because VMs should just link against our default jni libraries (at least for lang/net/io/util)? Sorry, I think I misunderstood your message. I thought you were suggesting moving all the native methods (eg for IO classes) to separate VM* classes. What I was suggesting in my previous message was consolidating the javaio, javanet, javanio native libraries (and perhaps others) into a single .so. In that case, we could just load this library once during initialization, with just one System.loadLibrary() call. The VMInterface classes define all methods that a particular VM might want to/has to implement to get a complete working core libraries implementation. Right. I think there is a distinction, however, between what the VM must implement to operate with classpath - ie core VM classes like Class, Object, Throwable, Thread; and portable classes which happen to have native methods, such as java.io.File and java.net.PlainSocketImpl. The later are just normal classes with native methods, the implementations of which are typically be portable across different VMs. So, they a system/platform interface rather than the VM interface. To put it another way, just because a method is native doesn't mean it interfaces with the VM. Regards, Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
