From Alan.Bateman at Sun.COM Thu Oct 4 08:40:10 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 04 Oct 2007 09:40:10 +0100 Subject: [PATCH] java.nio/6593946 ByteBuffer.compact does not clear mark In-Reply-To: <46F9661F.60800@redhat.com> References: <46F9661F.60800@redhat.com> Message-ID: <4704A6EA.1040503@sun.com> Keith Seitz wrote: > 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 Keith - I think Iris is going to get back to you shortly on this. One thing that needs to be figured out here is the implication for any existing applications that might depend on the current (broken) behavior. Unfortunately we have to worry about such things. In this case, if there is existing code that (perhaps unknowingly) depends on the current behavior then we might break it by a reset throwing an invalid mark exception in cases where it isn't thrown today. In the past we've had to introduce system properties to allow for "bug compatibility" with previous releases. I'm not saying we need it here but we need to think about it. -Alan. From twisti at complang.tuwien.ac.at Thu Oct 4 19:21:22 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 04 Oct 2007 21:21:22 +0200 Subject: fdlibm behaviour on non-HotSpot platforms In-Reply-To: <46B362E4.8000004@sun.com> References: <200708031153.49928.gnu_andrew@member.fsf.org> <46B362E4.8000004@sun.com> Message-ID: <1191525682.20037.21.camel@localhost.localdomain> On Fri, 2007-08-03 at 10:16 -0700, Joe Darcy wrote: > The Java language and vm require support for the full set of IEEE 754 > floating-point values, including NaN and infinity. At least older Alpha > chops did not have full hardware support for these values and compiler > options were needed to enable their use. More recent Alphas do have > more complete hardware support but compiler options may be needed. > (Also note that the Alpha hardware uses a weaker memory model than > required by Java so some work would be needed in a vm to insert fences, > etc. as appropriate.) Hi! I don't know what I did, maybe some things I had to add to the build systems, who knows, but it seems to work now. I can tell for sure it works on PowerPC and PowerPC64. I still have problems to get the whole thing built on Alpha, which is also a floating point problem, but that's another story... - twisti From Joe.Darcy at Sun.COM Sat Oct 6 01:03:34 2007 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 05 Oct 2007 18:03:34 -0700 Subject: [PATCH] java.math/4428022 Float/Double.toString trailing zeros In-Reply-To: <46F964B3.9090807@redhat.com> References: <46F964B3.9090807@redhat.com> Message-ID: <4706DEE6.3090907@sun.com> Hi Keith. Thanks for your patch with test. I'll try to look into incorporating this soon (I'm busy with OpenJDK 6). -Joe Keith Seitz wrote: > 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 From roman at kennke.org Wed Oct 10 20:42:21 2007 From: roman at kennke.org (Roman Kennke) Date: Wed, 10 Oct 2007 22:42:21 +0200 Subject: PlainSocketImpl.socketGetOption1() ? Message-ID: <1192048941.6995.59.camel@mercury> 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/ From Alan.Bateman at Sun.COM Wed Oct 10 20:49:04 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 10 Oct 2007 21:49:04 +0100 Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?] Message-ID: <470D3AC0.5090006@sun.com> It may be used in the Windows implementation - the networking group will know. -------------- next part -------------- An embedded message was scrubbed... From: Roman Kennke Subject: PlainSocketImpl.socketGetOption1() ? Date: Wed, 10 Oct 2007 22:42:21 +0200 Size: 5319 URL: From roman at kennke.org Thu Oct 11 18:30:41 2007 From: roman at kennke.org (Roman Kennke) Date: Thu, 11 Oct 2007 20:30:41 +0200 Subject: Bug#6546113 StringCharBuffer fix In-Reply-To: <1190919093.7478.12.camel@mercury> References: <1190919030.7478.10.camel@mercury> <1190919093.7478.12.camel@mercury> Message-ID: <1192127441.2826.17.camel@mercury> Hi there > > This fixes a problem with sliced StringCharBuffers. See: > > > > http://bugs.sun.com/view_bug.do?bug_id=6546113 > > > > Feel free to integrate this in the repository. Ping, any opinions on this? /Roman -- http://kennke.org/blog/ From Christopher.Hegarty at Sun.COM Wed Oct 10 21:36:35 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems) Date: Wed, 10 Oct 2007 22:36:35 +0100 Subject: [Fwd: PlainSocketImpl.socketGetOption1() ?] In-Reply-To: <470D3AC0.5090006@sun.com> References: <470D3AC0.5090006@sun.com> Message-ID: <470D45E3.4080300@sun.com> Hi Roman, This method was added as part of the changes for 4868820: "IPv6 support for Windows XP and 2003 server", back in 1.5. But I cannot see anywhere that it is called, or as you said even implemented, even when it was originally added. I suspect that it was left over from some redesign when adding the IPv6 support. I actually noticed this went adding support for the dual TCP/IP stack in vista, DualStackPlainSocketImpl, and even added a comment to remind me to remove it! I will file a new bug against this to have it removed and update this mailing list with the bug number when I have it. -Chris. Alan Bateman wrote: > > It may be used in the Windows implementation - the networking group will > know. > > ------------------------------------------------------------------------ > > Subject: > PlainSocketImpl.socketGetOption1() ? > From: > Roman Kennke > Date: > Wed, 10 Oct 2007 22:42:21 +0200 > To: > Core-Libs-Dev > > To: > Core-Libs-Dev > > > 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 > From Christopher.Hegarty at Sun.COM Fri Oct 12 12:04:14 2007 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 12 Oct 2007 13:04:14 +0100 Subject: [Fwd: Strange problem w/ RMI HTTP to CGI socket factory] Message-ID: <470F62BE.5040705@sun.com> 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 To: net-dev at 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 From Alan.Bateman at Sun.COM Fri Oct 12 13:01:28 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 12 Oct 2007 14:01:28 +0100 Subject: Bug#6546113 StringCharBuffer fix In-Reply-To: <1192127441.2826.17.camel@mercury> References: <1190919030.7478.10.camel@mercury> <1190919093.7478.12.camel@mercury> <1192127441.2826.17.camel@mercury> Message-ID: <470F7028.6080607@sun.com> Roman Kennke wrote: > Hi there > > >>> This fixes a problem with sliced StringCharBuffers. See: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=6546113 >>> >>> Feel free to integrate this in the repository. >>> > > Ping, any opinions on this? > > /Roman > I think Iris has been meaning to get back to you on this for a while (she has been busy). It's a bug that she & I spoke about a few months ago and she had planned to fix. All the better that you are now taking time to address it. If you look at 4997655 you will see that slicing a CharBuffer that wraps a char sequence has been problematic since day one. The changes for that bug in jdk6 fixed some problems but also lead to this problem. Unfortunately, the bug wasn't caught by existing tests so one thing that would be good to do as part of 6546113 is to add or improve the regression tests for char buffers that wrap a char sequence. Are you interested in doing that as part of the fix to this bug? Anyway, your changes look like a reasonable fix for the get methods. Did you check the toString, subSequence, and duplicate methods in case they have the same problem? One small concern is that the offset field was originally the offset into the backing array for heap buffers. Now it is used as the offset into the char sequence in the wrapped case. We should probably comment that for the sake of future maintainers or else add a new strOffset field to StringCharBuffer to make it easier to understand. -Alan. From peter.jones at Sun.COM Fri Oct 12 17:21:35 2007 From: peter.jones at Sun.COM (Peter Jones) Date: Fri, 12 Oct 2007 13:21:35 -0400 Subject: [Fwd: Strange problem w/ RMI HTTP to CGI socket factory] In-Reply-To: <470F62BE.5040705@sun.com> References: <470F62BE.5040705@sun.com> Message-ID: <20071012172135.GA14796@east> On Fri, Oct 12, 2007 at 01:04:14PM +0100, Christopher Hegarty - Sun Microsystems Ireland wrote: > 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. Thanks for the forward, 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 > To: net-dev at 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. First I should caution that the sun.rmi.transport.proxy package is a relatively delicate old corner of the implementation (it has barely been touched in 11 years)-- extending it is both somewhat risky and not supported by public Java SE APIs (for better or for worse). I suspect what your problem is: The implementation of the HTTP tunnelling provided by this package is presented (to the higher RMI/JRMP protocol implementation code) using java.net.Socket as an abstraction for an HTTP request/response pair, which is really not a very fitting abstraction, because with a Socket one can normally assume a full-duplex connection. The JRMP implementation code must understand what kind of "Socket" it is using in order to know whether to use JRMP's StreamProtocol (for a regular TCP connection or equivalent) or the SingleOpProtocol (for an HTTP-tunnelled remote invocation).[1] The implementation actually makes this distinction based on whether the Socket is an instance of the sun.rmi.transport.proxy.RMISocketInfo interface, and if it is, what an invocation of its isReusable() method returns-- if it is an instance of that interface and if isReusable returns false, HTTP tunnelling is assumed and the SingleOpProtocol is used; otherwise, a normal Socket is assumed and the StreamProtocol is used. So, if you completely cloned the sun.rmi.transport.proxy package, then your HttpSendSocket class presumably implements an incompatible RMISocketInfo interface, and thus it will not be recognized as only supporting request/response usage. If you make the class implement the original sun.rmi.transport.proxy.RMISocketInfo interface, that should fix this problem, but all of the caveats of depending on sun.* APIs would apply.[2] Some previous discussion of a similar problem is here: http://archives.java.sun.com/cgi-bin/wa?A2=ind0104&L=rmi-users&P=35726 -- Peter [1] These modes are described here: http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-protocol3.html [2] http://java.sun.com/products/jdk/faq/faq-sun-packages.html From roman.kennke at aicas.com Fri Oct 12 13:24:47 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Fri, 12 Oct 2007 15:24:47 +0200 Subject: Bug#6546113 StringCharBuffer fix In-Reply-To: <470F7028.6080607@sun.com> References: <1190919030.7478.10.camel@mercury> <1190919093.7478.12.camel@mercury> <1192127441.2826.17.camel@mercury> <470F7028.6080607@sun.com> Message-ID: <1192195487.6144.2.camel@mercury> Hi, > >>> This fixes a problem with sliced StringCharBuffers. See: > >>> > >>> http://bugs.sun.com/view_bug.do?bug_id=6546113 > >>> > >>> Feel free to integrate this in the repository. > >>> > > > > Ping, any opinions on this? > > > > /Roman > > > I think Iris has been meaning to get back to you on this for a while > (she has been busy). It's a bug that she & I spoke about a few months > ago and she had planned to fix. All the better that you are now taking > time to address it. If you look at 4997655 you will see that slicing a > CharBuffer that wraps a char sequence has been problematic since day > one. The changes for that bug in jdk6 fixed some problems but also lead > to this problem. Unfortunately, the bug wasn't caught by existing tests > so one thing that would be good to do as part of 6546113 is to add or > improve the regression tests for char buffers that wrap a char sequence. > Are you interested in doing that as part of the fix to this bug? Sure I can do that. > Anyway, > your changes look like a reasonable fix for the get methods. Did you > check the toString, subSequence, and duplicate methods in case they have > the same problem? No, but I'll do that too. Good point. > One small concern is that the offset field was > originally the offset into the backing array for heap buffers. Now it is > used as the offset into the char sequence in the wrapped case. We should > probably comment that for the sake of future maintainers or else add a > new strOffset field to StringCharBuffer to make it easier to understand. I'd reuse the existing field and comment on this. I'll come back when I've looked at the above points. Thanks, Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From harishsati at agiline.com Mon Oct 15 06:08:32 2007 From: harishsati at agiline.com (h Sati) Date: Sun, 14 Oct 2007 23:08:32 -0700 (PDT) Subject: Confirmation Message-ID: <455519.80761.qm@web807.biz.mail.mud.yahoo.com> hi all, i already subscribed to core lib mailing list.what should i do next to get more involved.i m looking forward to get reply. harish -------------- next part -------------- An HTML attachment was scrubbed... URL: From i30817 at gmail.com Wed Oct 17 17:33:32 2007 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 17 Oct 2007 18:33:32 +0100 Subject: Capitulo 14 parte 1 In-Reply-To: <212322090710171032q3fd67894ya19ec7caa08fd6d7@mail.gmail.com> References: <212322090710171032q3fd67894ya19ec7caa08fd6d7@mail.gmail.com> Message-ID: <212322090710171033p582959c4xed348585931b5e41@mail.gmail.com> Sorry about this. Wrong mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcilhar at yahoo.com Tue Oct 23 03:15:17 2007 From: rmcilhar at yahoo.com (Robert McIlhargie) Date: Mon, 22 Oct 2007 20:15:17 -0700 (PDT) Subject: BUG: 4681995 add support zipping/unzipping large files Message-ID: <209796.93864.qm@web38204.mail.mud.yahoo.com> Is anyone working on this? I currently get an exception "invalid entry size(expected ..." when I try to unzip files that are larger than 4.29GB (0xFFFFFFFF) bytes that have been compressed using PKZip. In looking at the code for ZipInputStream, its not parsing out the Zip64 information in the extra information area for the ZipEntry. I've read through the PKZip specification and written some code to parse out the byte array of extra information that is stored in the ZipEntry class to get the 64-bit file sizes. Is there anyone I should coordinate on fixing this with? Thanks. -- Rob. From roman.kennke at aicas.com Wed Oct 24 08:27:04 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 24 Oct 2007 10:27:04 +0200 Subject: [PATCH] Load currency.data via ClassLoader Message-ID: <1193214424.6891.18.camel@mercury> Hi there, in java.util.Currency, the currency.data is loaded from $JRE_DIR/lib. I'm having a problem with this in the JamaicaVM, when an application is built into a single bundle for use on an embedded machine. There is no JRE installed on that machine, and this file can't be loaded. I suggest to fall back to loading this file via the ClassLoader. See attached patch. This should affect normal behaviour, and only adds the option to put this file in the (boot) classpath instead. What do you think? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk-currency-patch.txt Type: text/x-patch Size: 1392 bytes Desc: not available URL: From Alan.Bateman at Sun.COM Wed Oct 24 08:42:10 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 24 Oct 2007 09:42:10 +0100 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] Message-ID: <471F0562.3050000@sun.com> Locale related utility classes are maintained by the i18n group - right? -------------- next part -------------- An embedded message was scrubbed... From: Roman Kennke Subject: [PATCH] Load currency.data via ClassLoader Date: Wed, 24 Oct 2007 10:27:04 +0200 Size: 8921 URL: From roman.kennke at aicas.com Wed Oct 24 08:51:13 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 24 Oct 2007 10:51:13 +0200 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] In-Reply-To: <471F0562.3050000@sun.com> References: <471F0562.3050000@sun.com> Message-ID: <1193215873.6891.24.camel@mercury> Hi, Am Mittwoch, den 24.10.2007, 09:42 +0100 schrieb Alan Bateman: > Locale related utility classes are maintained by the i18n group - right? Sorry, I'm a little lost with all those groups and mailing lists. By now I should be subscribed to almost all OpenJDK lists... /Roman > E-Mail-Nachricht-Anlage ([PATCH] Load currency.data via > ClassLoader.eml) > > -------- Weitergeleitete Nachricht -------- > > Von: Roman Kennke > > An: Core-Libs-Dev > > Betreff: [PATCH] Load currency.data via ClassLoader > > Datum: Wed, 24 Oct 2007 10:27:04 +0200 > > > > Hi there, > > > > in java.util.Currency, the currency.data is loaded from $JRE_DIR/lib. > > I'm having a problem with this in the JamaicaVM, when an application is > > built into a single bundle for use on an embedded machine. There is no > > JRE installed on that machine, and this file can't be loaded. I suggest > > to fall back to loading this file via the ClassLoader. See attached > > patch. This should affect normal behaviour, and only adds the option to > > put this file in the (boot) classpath instead. What do you think? > > > > /Roman > > -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From David.Bristor at Sun.COM Wed Oct 24 17:24:27 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Wed, 24 Oct 2007 10:24:27 -0700 Subject: BUG: 4681995 add support zipping/unzipping large files In-Reply-To: <209796.93864.qm@web38204.mail.mud.yahoo.com> References: <209796.93864.qm@web38204.mail.mud.yahoo.com> Message-ID: <471F7FCB.6090109@sun.com> Hi Rob, We have bug 4681995 open (since 2002!) for this kind of thing. If you're interested in contributing, could you please take a look at http://openjdk.java.net/contribute I'd be happy to coordinate a fix with you. Thanks, Dave Robert McIlhargie wrote: > Is anyone working on this? > > I currently get an exception "invalid entry size(expected ..." when I try to unzip files that are larger than 4.29GB (0xFFFFFFFF) bytes that > have been compressed using PKZip. In looking at the code for ZipInputStream, its not parsing out the Zip64 information > in the extra information area for the ZipEntry. I've read through the PKZip specification and written some code to parse out the byte array > of extra information that is stored in the ZipEntry class to get the 64-bit file sizes. > > Is there anyone I should coordinate on fixing this with? > > Thanks. > -- > Rob. > > > > > > From keiths at redhat.com Tue Oct 23 22:04:19 2007 From: keiths at redhat.com (Keith Seitz) Date: Tue, 23 Oct 2007 15:04:19 -0700 Subject: PATCH: java.nio.channels.DatagramChannel/NotBound.java test patch Message-ID: <471E6FE3.9000602@redhat.com> Hi, While playing with the j2se testsuite, I ran across some problems executing the test in $SUBJECT. Most specifically, the test will generate an error when run on jtreg since the class is not declared public. Additionally: as written, the testcase doesn't really make a whole lot of sense: it tests the same condition twice, despite the fact that it would (at first glance) appear to do two different tests. I'm attaching a patch to simplify this testcase to do the only logical thing it can do (at least as I could figure it out): test that an unbound, non-blocking DatagramChannel connection will return null when the receive method is called. Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: java_nio_channels_DatagramChannel_NotBound.patch Type: text/x-patch Size: 675 bytes Desc: not available URL: From Alan.Bateman at Sun.COM Wed Oct 24 20:57:22 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 24 Oct 2007 21:57:22 +0100 Subject: PATCH: java.nio.channels.DatagramChannel/NotBound.java test patch In-Reply-To: <471E6FE3.9000602@redhat.com> References: <471E6FE3.9000602@redhat.com> Message-ID: <471FB1B2.4080506@sun.com> Keith Seitz wrote: > Hi, > > While playing with the j2se testsuite, I ran across some problems > executing the test in $SUBJECT. Most specifically, the test will > generate an error when run on jtreg since the class is not declared > public. > > Additionally: as written, the testcase doesn't really make a whole lot > of sense: it tests the same condition twice, despite the fact that it > would (at first glance) appear to do two different tests. > > I'm attaching a patch to simplify this testcase to do the only logical > thing it can do (at least as I could figure it out): test that an > unbound, non-blocking DatagramChannel connection will return null when > the receive method is called. > > Keith Thanks Keith. As it happens, I also ran into this one a few days ago. The test is >5 years old and only recently started failing for me when I picked up the most recent jtreg. Anyway, making the class public, as you suggest, fixes the problem so that the test runs. The original intent seems to have been to test both the blocking and non-blocking cases and there was probably a typo in the original test that went unnoticed. I'll get the fix for the test in once the transition to Mercurial is done and we start integrating fixes again. Test aside, we also need to clarify the specification for the receive method to state the required behavior when invoked on a channel that is unbound. I'll create a bug to track that. -Alan. From roman.kennke at aicas.com Thu Oct 25 17:10:09 2007 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 25 Oct 2007 19:10:09 +0200 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] In-Reply-To: <4720C75F.9080308@Sun.COM> References: <471F0562.3050000@sun.com> <1193215873.6891.24.camel@mercury> <4720C75F.9080308@Sun.COM> Message-ID: <1193332209.6586.42.camel@mercury> Hi Naoto, > As to the issue, I have a question. Under jre/lib directory, there are > other files that are not read via the ClassLoader method. For example, > there are data files for time zones under jre/lib/zi, which are read via > FileInputStream, the same way currency.data is read. My question is how > the JamaicaVM is dealing with those files? I would expect that the same > issue should have been observed with those files. Exactly. The currency data was the first that has bitten me, but I would have to go through all of them of course. But let's start with this one and take them step by step. :-) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Alan.Bateman at Sun.COM Thu Oct 25 18:04:23 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 25 Oct 2007 19:04:23 +0100 Subject: PATCH: java.nio.channels.DatagramChannel/NotBound.java test patch In-Reply-To: <471E6FE3.9000602@redhat.com> References: <471E6FE3.9000602@redhat.com> Message-ID: <4720DAA7.8020201@sun.com> Keith Seitz wrote: > Hi, > > While playing with the j2se testsuite, I ran across some problems > executing the test in $SUBJECT. Most specifically, the test will > generate an error when run on jtreg since the class is not declared > public. > > Additionally: as written, the testcase doesn't really make a whole lot > of sense: it tests the same condition twice, despite the fact that it > would (at first glance) appear to do two different tests. > > I'm attaching a patch to simplify this testcase to do the only logical > thing it can do (at least as I could figure it out): test that an > unbound, non-blocking DatagramChannel connection will return null when > the receive method is called. > > Keith Keith - I've created 6621691 to track fixing the test, and 6621689 to deal with the DatagramChannel#receive specification issue that I mentioned in the reply yesterday. They should be visible on bugs.sun.com by tomorrow. -Alan. From Naoto.Sato at Sun.COM Thu Oct 25 16:42:07 2007 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Thu, 25 Oct 2007 09:42:07 -0700 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] In-Reply-To: <1193215873.6891.24.camel@mercury> References: <471F0562.3050000@sun.com> <1193215873.6891.24.camel@mercury> Message-ID: <4720C75F.9080308@Sun.COM> Hi Roman, Thank you for bringing this up. Yes, it's a bit unclear but the Currency class belongs to the i18n group. As to the issue, I have a question. Under jre/lib directory, there are other files that are not read via the ClassLoader method. For example, there are data files for time zones under jre/lib/zi, which are read via FileInputStream, the same way currency.data is read. My question is how the JamaicaVM is dealing with those files? I would expect that the same issue should have been observed with those files. Thanks, Naoto Roman Kennke wrote: > Hi, > > Am Mittwoch, den 24.10.2007, 09:42 +0100 schrieb Alan Bateman: >> Locale related utility classes are maintained by the i18n group - right? > > Sorry, I'm a little lost with all those groups and mailing lists. By now > I should be subscribed to almost all OpenJDK lists... > > /Roman > >> E-Mail-Nachricht-Anlage ([PATCH] Load currency.data via >> ClassLoader.eml) >>> -------- Weitergeleitete Nachricht -------- >>> Von: Roman Kennke >>> An: Core-Libs-Dev >>> Betreff: [PATCH] Load currency.data via ClassLoader >>> Datum: Wed, 24 Oct 2007 10:27:04 +0200 >>> >>> Hi there, >>> >>> in java.util.Currency, the currency.data is loaded from $JRE_DIR/lib. >>> I'm having a problem with this in the JamaicaVM, when an application is >>> built into a single bundle for use on an embedded machine. There is no >>> JRE installed on that machine, and this file can't be loaded. I suggest >>> to fall back to loading this file via the ClassLoader. See attached >>> patch. This should affect normal behaviour, and only adds the option to >>> put this file in the (boot) classpath instead. What do you think? >>> >>> /Roman >>> -- Naoto Sato From jeroen at sumatra.nl Fri Oct 26 04:27:03 2007 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Fri, 26 Oct 2007 06:27:03 +0200 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] In-Reply-To: <4720C75F.9080308@Sun.COM> References: <471F0562.3050000@sun.com> <1193215873.6891.24.camel@mercury> <4720C75F.9080308@Sun.COM> Message-ID: Naoto Sato wrote: > Hi Roman, > > Thank you for bringing this up. Yes, it's a bit unclear but the > Currency class belongs to the i18n group. > > As to the issue, I have a question. Under jre/lib directory, there are > other files that are not read via the ClassLoader method. For example, > there are data files for time zones under jre/lib/zi, which are read > via FileInputStream, the same way currency.data is read. My question > is how the JamaicaVM is dealing with those files? I would expect that > the same issue should have been observed with those files. As another data point, in IKVM.NET I ran into this issue as well. I worked around it by virtualizing the java.home directory. This is a bit of a hack, but it works well. Regards, Jeroen From matthias at mernst.org Mon Oct 29 10:52:25 2007 From: matthias at mernst.org (Matthias Ernst) Date: Mon, 29 Oct 2007 11:52:25 +0100 Subject: 6436458: eliminate synchronization from Pattern / separate compilation from pattern class / code cleanup Message-ID: <22ec15240710290352k65a2f02ehc4d045828c71514c@mail.gmail.com> [This is a followup to https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=19386&forumID=1463] xshen wrote on 2007-04-05 19:54:38 GMT: >Thanks for the suggested fix. I will try to pull in >your stuff into the Pattern class when I begin to >integrate my JDK7 regex stuff (including new feature, >bugfix and some cleanup as well) into the workspace. Any news on this? I cannot see it in svn. Matthias From Naoto.Sato at Sun.COM Mon Oct 29 18:11:17 2007 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Mon, 29 Oct 2007 11:11:17 -0700 Subject: [Fwd: [PATCH] Load currency.data via ClassLoader] In-Reply-To: <1193332209.6586.42.camel@mercury> References: <471F0562.3050000@sun.com> <1193215873.6891.24.camel@mercury> <4720C75F.9080308@Sun.COM> <1193332209.6586.42.camel@mercury> Message-ID: <47262245.10100@Sun.COM> Hi Roman, If that's the case, I believe some of them would require not only implementation change, but also the spec change. And I am even not sure whether they are actually doable or not. I'd like to find out whether it would be practically feasible, before fixing them one by one. Thanks, Naoto Roman Kennke wrote: > Hi Naoto, > >> As to the issue, I have a question. Under jre/lib directory, there are >> other files that are not read via the ClassLoader method. For example, >> there are data files for time zones under jre/lib/zi, which are read via >> FileInputStream, the same way currency.data is read. My question is how >> the JamaicaVM is dealing with those files? I would expect that the same >> issue should have been observed with those files. > > Exactly. The currency data was the first that has bitten me, but I would > have to go through all of them of course. But let's start with this one > and take them step by step. :-) > > /Roman > -- Naoto Sato