Re: RFR JDK-8005120
John, socket_md.c:88,99,110 etc. could you change int len to size_t len as well? -Dmitry On 2012-12-21 02:47, John Zavgren wrote: Greetings: I modified my changes so that windows knows the definition of the POSIX data type: socklen_t, and now all the system calls are using the doctrinaire data types. Please consider the following update. http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/ Thanks! John Zavgren On 20/12/2012 13:49, John Zavgren wrote: Greetings: I agree that the correct way to fix this problem is to use POSIX data types, e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on windows machines: - build monologue - c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2146: syntax error : missing ')' before identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2081: 'socklen_t' : name in formal parameter list illegal c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2061: syntax error : identifier 'len' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ';' c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) : error C2059: syntax error : ')' - build monologue - I used alternative types, e.g., uint32_t, etc. as a way to avoid the limitations of windows. What is the recommended way to accommodate this windows limitation? Shall I use a typedef statement to define socklen_t? We don't suffer from this issue in the networking native code. The unix and windows implementations are distinct. I see the vm defines socklen_t in a windows specific header, hotspot/src/os/windows/vm/jvm_windows.h, as typedef int socklen_t; ...and it is then used in shared code, like jvm.cpp, and the hpi, by optionally including #ifdef TARGET_OS_FAMILY_windows # include jvm_windows.h #endif We could use a similar, but more simplistic, approach here. -Chris. Thanks! - Original Message - From: chris.hega...@oracle.com To: david.hol...@oracle.com Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net, john.zavg...@oracle.com, net-dev@openjdk.java.net Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR JDK-8005120 On 19/12/2012 20:52, David Holmes wrote: Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Yes, and the networking native code too. I think it is best to use socklen_t for the unix code. From what I can see making these changes, to use socklen_t, should be relatively localized. -Chris. Depending on the OS (and version?) we should be using socklen_t not int and not uint32_t. David On 20/12/2012 2:35 AM, Chris Hegarty wrote: John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected 'uint32_t *' but argument is of type 'int *' ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_accept': ../../../../src/share/transport/socket/socketTransport.c:371:33: warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected 'uint32_t *' but argument is of type 'int *' Do you see these in your build? -Chris. On 12/19/2012 03:42 PM, Alan Bateman wrote: John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15:36, John Zavgren wrote: Greetings: Please consider the following change to the two files: src/share/transport/socket/sysSocket.h src/solaris/transport/socket/socket_md.c that eliminate compiler warnings that stem from the fact that the variables that the native code passes to various system calls were not declared correctly. They were declared as integers, but they must be unsigned integers because they are used to define buffer lengths. Were one to supply a negative value as an argument, it would be cast into an unsigned Martian value and there'd be (hopefully) a system call error. Thanks! John Zavgren http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
Re: RFR JDK-8005120
John,
Much better, but I still see warnings when building with your patch. You
need to update (some) callers of these functions, see below ( these are
the only ones I see ).
---
diff -r 31d2f9995d6c src/share/transport/socket/socketTransport.c
--- a/src/share/transport/socket/socketTransport.c Thu Dec 20
15:04:53 2012 +
+++ b/src/share/transport/socket/socketTransport.c Fri Dec 21
09:40:30 2012 +
@@ -304,7 +304,7 @@ socketTransport_startListening(jdwpTrans
{
char buf[20];
-int len = sizeof(sa);
+socklen_t len = sizeof(sa);
jint portNum;
err = dbgsysGetSocketName(serverSocketFD,
(struct sockaddr *)sa, len);
@@ -324,7 +324,8 @@ static jdwpTransportError JNICALL
static jdwpTransportError JNICALL
socketTransport_accept(jdwpTransportEnv* env, jlong acceptTimeout,
jlong handshakeTimeout)
{
-int socketLen, err;
+socklen_t socketLen;
+int err;
struct sockaddr_in socket;
jlong startTime = (jlong)0;
---
Also, I think the windows version of these functions should be updated
to use socklen_t ( now that we have it defined for windows), in
windows/transport/socket/socket_md.c
Can you confirm that this code now compiles warning free on all
platforms? That was the original intent, right?
-Chris.
On 12/20/2012 10:47 PM, John Zavgren wrote:
Greetings:
I modified my changes so that windows knows the definition of the POSIX data type:
socklen_t, and now all the system calls are using the doctrinaire data types.
Please consider the following update.
http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/webrev.01/
Thanks!
John Zavgren
On 20/12/2012 13:49, John Zavgren wrote:
Greetings:
I agree that the correct way to fix this problem is to use POSIX data types,
e.g., socklen_t. However, when I switch to the doctrinaire data type, the build fails on
windows machines:
- build monologue -
c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) :
error C2146: syntax error : missing ')' before identifier 'len'
c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) :
error C2081: 'socklen_t' : name in formal parameter list illegal
c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) :
error C2061: syntax error : identifier 'len'
c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) :
error C2059: syntax error : ';'
c:\jprt\t\p1\032220.jzavgren\s\jdk\src\share\transport\socket\sysSocket.h(39) :
error C2059: syntax error : ')'
- build monologue -
I used alternative types, e.g., uint32_t, etc. as a way to avoid the
limitations of windows.
What is the recommended way to accommodate this windows limitation? Shall I use a typedef
statement to define socklen_t?
We don't suffer from this issue in the networking native code. The unix
and windows implementations are distinct.
I see the vm defines socklen_t in a windows specific header,
hotspot/src/os/windows/vm/jvm_windows.h, as
typedef int socklen_t;
...and it is then used in shared code, like jvm.cpp, and the hpi, by
optionally including
#ifdef TARGET_OS_FAMILY_windows
# include jvm_windows.h
#endif
We could use a similar, but more simplistic, approach here.
-Chris.
Thanks!
- Original Message -
From: chris.hega...@oracle.com
To: david.hol...@oracle.com
Cc: alan.bate...@oracle.com, serviceability-...@openjdk.java.net,
john.zavg...@oracle.com, net-dev@openjdk.java.net
Sent: Thursday, December 20, 2012 7:41:07 AM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8005120
On 19/12/2012 20:52, David Holmes wrote:
Real sense of deja-vu here. Didn't we go through this same thing with
the HPI socket routines?
Yes, and the networking native code too.
I think it is best to use socklen_t for the unix code. From what I can
see making these changes, to use socklen_t, should be relatively localized.
-Chris.
Depending on the OS (and version?) we should be using socklen_t not int
and not uint32_t.
David
On 20/12/2012 2:35 AM, Chris Hegarty wrote:
John,
I grabbed your patch, and with it I now see different warnings.
../../../../src/share/transport/socket/socketTransport.c: In function
'socketTransport_startListening':
../../../../src/share/transport/socket/socketTransport.c:310:40:
warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName'
differ in signedness [-Wpointer-sign]
../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected
'uint32_t *' but argument is of type 'int *'
../../../../src/share/transport/socket/socketTransport.c: In function
'socketTransport_accept':
../../../../src/share/transport/socket/socketTransport.c:371:33:
warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ
in signedness [-Wpointer-sign]
../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected
JEP 110: New HTTP Client: Please drop from JDK 8
JEP 110: New Http Client is a feature intended for Java SE 8 which aims to provide a new client API for http, and which leverages some of the new features in recent releases of Java SE, such as asynchronous sockets in NIO and Lambda expressions. A significant amount of work has been done so far, with a draft API and implementation hosted as a java.net project (http://java.net/projects/http-client). Additionally, a number of rounds of API review were done over recent months and much useful feedback was received. However, it has become apparent that the API is significantly larger than is normal for Java SE features without their own JSR. Given we have come to this realisation late in the JDK 8 project, we have reluctantly decided to ask that it be dropped from Java SE 8. We will either reduce the scope of the API, and/or start a JSR with its current scope for the work to continue, so that it can be considered for Java SE 9. I'd like to thank all of the contributors and reviewers for their work so far, and we hope to continue this good work, as soon as we decide exactly what direction it will take. Regards, Michael
java.net.URL.getBasePath() -- time to have it?
Hey folks, To be able to get the basePath of a URL so they can load other stuff that came from a relative path, it is usual to see people coding stuff like this: https://gist.github.com/4355670 I don't know if there's something in the Java API that offers this, but it would be a great increment to the URL class (and perhaps URI as well), to offer this out of the box. Thoughts? -- Bruno Borges Principal Product Manager | JavaEE WebLogic GlassFish Oracle LAD PM Team| Cloud Application Foundation +55 11 5187 6514 (Work) | +55 11 99564 9058 (Mobi)
