- core-libs-dev - openjdk.org

[Fwd: Strange problem w/ RMI HTTP to CGI socket factory]
by Christopher Hegarty - Sun Microsystems Ireland 12 Oct '07

12 Oct '07

Forwarding this mail to the core libs mailing list as they are most probably in a better position to answer it as they own the sun.rmi package. -Chris. -------- Original Message -------- Subject: Strange problem w/ RMI HTTP to CGI socket factory Date: Thu, 11 Oct 2007 15:57:48 -0400 From: Sarel Botha <sarel(a)botha.us> To: net-dev(a)openjdk.java.net Hi All, This problem seems strange to me and I don't know where to look to resolve it. The RMIHttpToCGISocketFactory class is working well for me. I call RMISocketFactory.setSocketFactory(new RMIHttpToCGISocketFactory ()), then Naming.lookup() and all is well. However, I need to customize this class a little, so I got a copy of the source code for the package sun.rmi.transport.proxy, then renamed the package for these classes to sun.rmi.transport.proxy2 (also tried openjdk.sun.rmi.transport.proxy). If I try to use the same class in this package I get this error when it tries to establish the RMI connection: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: java.io.IOException: attempt to write on HttpSendSocket after request has been sent at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286) What's happening is that the underlying RMI code is calling HttpSendOutputStream.write() and passing only 7 bytes. This is immediately sent to the server which responds with only about 18 bytes. Then, it tries to call write() again, which should never happen, so it throws the exception you see above. When it works (using the socket factory that ships with JRE6) it first sends 58 bytes and the server responds with 217 bytes. You can also see the name of the RMI service in the request and the server response contains the name of the stub and the IP where the service is running. It seems like the underlying implementation is treating this socket factory totally differently from the one it ships with. Must the code be compiled with different switches maybe? Must the socket factory be registered somewhere? Any pointers would be appreciated. Thanks, Sarel

2 1

[Fwd: PlainSocketImpl.socketGetOption1() ?]
by Alan Bateman 10 Oct '07

10 Oct '07

It may be used in the Windows implementation - the networking group will know.

2 1

PlainSocketImpl.socketGetOption1() ?
by Roman Kennke 10 Oct '07

10 Oct '07

Hi list, The PlainSocketImpl family of classes have a method socketGetOption1(), which is required by the AbstractPlainSocketImpl class, and implemented by the subclasses, but apparently never used. There isn't even a native implementation for the native method in PlainSocketImpl. Could this method be removed, or is there another story behind this? /Roman -- http://kennke.org/blog/

1 0

[PATCH] java.math/4428022 Float/Double.toString trailing zeros
by Keith Seitz 06 Oct '07

06 Oct '07

Hi, I believe the attached patch fixes the trailing zero problem mentioned in several bugs (in addition to $SUBJECT), including 4511638, 6575880, and 4191279. The problem arises because sun.misc.FloatingDecimal.getChars and sun.misc.FloatingDecimal.dtoa disagree about when numbers are represented in E-form and when they are not. As a result, dtoa stuffs one too many numbers (a '0' in this case) into digits[], and getChars blindly returns them to FloatingDecimal.toJavaFormatString. I have also attached a jtreg test for this, based on various testcases given in several bug requests. Keith

2 1

fdlibm behaviour on non-HotSpot platforms
by gnu_andrew＠member.fsf.org 04 Oct '07

04 Oct '07

Hi, Christian Thalinger (twisti) of the CACAO project has recently been looking at using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, alpha). I've just been testing this on ppc64 this morning. The trigonometric functions (sin, cos, tan) seem to run into difficulties on these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct answer of 0.644217687237691. On alpha, the same test gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc and ppc64. Ironically, gij on ppc64 gives the correct answer. This was spotted when running SPECs check: 5$ cacao -cp ./check.jar spec/jbb/validity/PepTest LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=HUP LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=INT LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=TERM LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! testIf: OK testArray: OK testBitOps: OK testFor: OK testDiv: OK testTableSwitch: OK testLookupSwitch: OK testHiddenField: OK checkRemainders: long double OK checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 cos(0.7) evaluated to: 1.0, expected: 0.764842 acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 atan(0.7) evaluated to: 0.7, expected: 0.610726 ****************************************** Some math function failed ****************************************** Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 testExc1(simple throw/catch): OK testExc2(skip catch clauses): OK testExc3(catch in inner): OK testExc4(catch in outer): OK testExc5(rethrow): OK testExc6(throw accross call): OK testExc7(throw accr. 2 calls): OK loopExitContinueInExceptionHandler: OK testStringHash: OK testClone: OK testObjectArray: OK checkInstanceOf: OK checkInterfaceInstanceOf: OK testWaitNull: OK testVarAndMethodNameClash: OK testMisk: OK testGC: OK testRandom : OK PepTest: error Any idea what the problem may be and when this may be rectified? Thanks, -- Andrew :)

3 2

[PATCH] java.nio/6593946 ByteBuffer.compact does not clear mark
by Keith Seitz 04 Oct '07

04 Oct '07

Hi, The attached patch should fix the mark problem with ByteBuffer.compact, which simply was not following the API specification. I'm also attaching a simple jtreg testcase for this. Keith

2 1

Improved List initialisation
by Richard Warburton 12 Sep '07

12 Sep '07

I hope this is the correct mailing list to discuss such an idea, please correct me if I'm wrong, but core-libs sounded like it included collections api. Within Java we have a sugared syntax for initialising arrays, so for example we can write this: int[] intArray = {1,2,3}; However, list initialisation requires a very handed approach, for example: List<Integer> intList = new ArrayList<Integer>(); intList.add(1); intList.add(2); intList.add(3); Certain other languages have some sugar for this kind of thing, the general jist of: List l = [1,2,3]; In java we could get a similarly concise effect, with no hacking in syntactic sugar to solve these problems, I am thinking of a syntax along the lines of: List<Integer> intList = new ArrayList<Integer>(1,2,3); This could be trivially implemented as such: public ArrayList(T ... args) { for (T t : args) { this.add(t); } } The same approach could be used for Vector and the Set collections classes I am also not aware of the process of proposing library changes, eg would I need to do something in conjunction with the JCP? Perhaps someone more knowledgable could advise me. Awaiting commentary with interest. Richard Warburton

2 1

Re: JDK GNU/Linux SPARC and MIPS
by Volker Simonis 11 Sep '07

11 Sep '07

On 9/11/07, steve goldman <Steve.Goldman(a)sun.com> wrote: > Sunil Amitkumar Janki wrote: > > Am I naive to think that Solaris and Linux SPARC should be > > almost the same? I have copied the solaris_sparc directory > > to linux_sparc and changed all references to Solaris to Linux. > > That is certainly how thing usually go. > > Now if I can put a project in someone's head one of the things we've > wanted to for a long time is to have an os directory "*nix" where most > os the solaris/linux code would go and eliminate the redundancy. Then > add something like os_flavor to the MakeDeps macros and platform files > to cover the place where linux and solaris differ. I don't know if this > then causes factoring <os_cpu> into both <os_cpu> and <os_flavor_cpu> or > not. I suspect it does. > This sounds like nice to have, although it will be probably quite a lot of work. Perhaps it would be a better idea to clean up the native parts in the j2se/src/solaris directory first. It currently contains the native Solaris AND the Linux sources, separeted only by '#ifdef'. (Notice that j2se/src/linux only contains the Linux man-pages). As OpenJDK will be ported to more "*nix"-like os-platforms, this will be probably a major point of confusion. Volker

2 1

[PATCH] 4153167: separate between ANSI and OEM code pages on Windows
by Křištof Želechovski 24 Aug '07

24 Aug '07

I am unable to compile JRE from source and therefore this patch is not really a patch but it can easily become one. In my opinion, it should. The following code fixes the OEM encoding problem. It is applied only when the corresponding standard handle is not bound to a regular file. I considered patching it for character devices only but it turns out that Microsoft Visual Studio reads tool output on the fly and recodes it on the fly. Therefore I decided that only regular files should be excluded. The patch consists of two files: OEM.Setup.java and OEMSetup.cpp. The other file contains C++ code that should be compiled to oemsetup.dll; is required because the the OEM code page and the underlying file type can only be determined from native code. FILE OEM.Setup.java BEGINS package OEM; import java.io.*; /** Handles localization to OEM legacy encoding used by the Windows console */ public class Setup { /** * The class initializer loads the native method getCodePage from a dynamic library. * The library must be in the operating system path. * It should be incorporated into the VM. */ static { System.loadLibrary("oemsetup"); } /** * Changes System.out and System.err to use the OEM character set. * Should be called before the streams are used. * Should be incorporated into the system initialization routine. */ public static void setup() { int codePage = getCodePage(01); if(codePage != -01) try { System.setOut(encodeStream(FileDescriptor.out, codePage)); } catch(UnsupportedEncodingException e) { System.err.println(e); } if((codePage = getCodePage(02)) != -01) try { System.setErr(encodeStream(FileDescriptor.err, codePage)); } catch(UnsupportedEncodingException e) { System.err.println(e); }} /** Converts the Windows code page number to Java character set name */ static String formatCodePage(int p) { return "CP" + p; } /** * Creates the stream to replace the standard stream corresponding to the file descriptor * using the code page */ static PrintStream encodeStream(FileDescriptor fd, int cp) throws UnsupportedEncodingException { return new PrintStream(new FileOutputStream(fd), fd != FileDescriptor.err, formatCodePage(cp)); } /** * Returns the Windows code page number corresponding to the standard file descriptor. * Returns -1 if the file descriptor is invalid or redirected to a regular file */ native static int getCodePage(int fd); } FILE OEM.Setup.java ENDS FILE OEMSetup.cpp BEGINS #include "stdafx.h" #include "OEM_Setup.h" JNIEXPORT jint JNICALL Java_OEM_Setup_getCodePage(JNIEnv *, jclass, jint p_ix) { C_ASSERT(STD_INPUT_HANDLE - 01 == STD_OUTPUT_HANDLE); C_ASSERT(STD_OUTPUT_HANDLE - 01 == STD_ERROR_HANDLE); auto HANDLE a_h(::GetStdHandle(STD_INPUT_HANDLE - p_ix)); return a_h == INVALID_HANDLE_VALUE || ::GetFileType(a_h) == FILE_TYPE_DISK? -01: (p_ix? ::GetConsoleOutputCP: ::GetConsoleCP)(); } FILE OEMSetup.cpp ENDS TEST CASE BEGINS class Main { public static void main(String args[]) { OEM.Setup.setup(); for(String arg:args) System.out.println(arg); }} TEST CASE ENDS

1 0

Using system tzdata
by Keith Seitz 09 Aug '07

09 Aug '07

Hi, The JRE contains pre-compiled timezone information files. As an OS vendor, Red Hat would prefer not to respin or repackage the JRE every time tzdata changes somewhere in the world. In order to facilitate this, we're in the process of modifying our tzdata package to include pre-compiled zoneinfo files for use with JREs. I have created a patch to the openjdk JRE that would optionally use these files instead of the pre-packaged ones in the JRE. We would really like to solicit advice/comments about how to get something like this accepted upstream so that other distros can use this. Keith

2 1