Hi guys,
I am reading the SocketPermission source code recently and find some
thing strange. Below is a simple test case to describe the strange thing:
SocketPermission star_All = new SocketPermission("*.java.net",
"listen,accept,connect");
SocketPermission www_All = new SocketPermission("jav
On 02/18/2011 11:57 PM, Alan Bateman wrote:
Charles Lee wrote:
Hi guys,
I am reading the SocketPermission source code recently and find some
thing strange.
It might be better to bring this to the net-dev list as that is where
the networking code, including SocketPermission, is maintained
Hi guys,
I have noticed AsynchronousDatagramChannel has been removed. I am
curious about this. So It comes to me that I can not find such topic in
the mailing list. I know the archive is
http://mail.openjdk.java.net/pipermail/jdk7-dev/, but there is no search
function there. Does anyone has s
On 03/02/2011 04:46 PM, David Holmes wrote:
Charles Lee said the following on 03/02/11 18:32:
I have noticed AsynchronousDatagramChannel has been removed. I am
curious about this. So It comes to me that I can not find such topic
in the mailing list. I know the archive is
http
On 03/02/2011 05:03 PM, Alan Bateman wrote:
Charles Lee wrote:
Hi guys,
I have noticed AsynchronousDatagramChannel has been removed. I am
curious about this. So It comes to me that I can not find such topic
in the mailing list. I know the archive is
http://mail.openjdk.java.net/pipermail
Hi guys,
We have some problems about the accessibility things. Where should these
problems go to? this mailing list?
Thanks.
On 03/24/2011 04:17 PM, Roger Yeung wrote:
On 3/24/11 12:59 AM, Charles Lee wrote:
Hi guys,
We have some problems about the accessibility things. Where should
these problems go to? this mailing list?
Thanks.
Is this regarding the new AB2.0.2 ( http://jdk6.java.net/6uNea.html )?
Please
On 03/24/2011 04:35 PM, Alan Bateman wrote:
Charles Lee wrote:
Hi guys,
We have some problems about the accessibility things. Where should
these problems go to? this mailing list?
Thanks.
Do you mean accessibility issues with Swing components (in which case
swing-dev), or something else
On 03/25/2011 02:53 AM, Roger Yeung wrote:
On 3/24/11 1:27 AM, Charles Lee wrote:
On 03/24/2011 04:17 PM, Roger Yeung wrote:
On 3/24/11 12:59 AM, Charles Lee wrote:
Hi guys,
We have some problems about the accessibility things. Where should
these problems go to? this mailing list
On 03/25/2011 11:53 AM, Roger Yeung wrote:
On 3/24/11 7:54 PM, Charles Lee wrote:
On 03/25/2011 02:53 AM, Roger Yeung wrote:
On 3/24/11 1:27 AM, Charles Lee wrote:
On 03/24/2011 04:17 PM, Roger Yeung wrote:
On 3/24/11 12:59 AM, Charles Lee wrote:
Hi guys,
We have some problems about the
On 08/18/2011 03:23 AM, Sebastian Sickelmann wrote:
Hi,
after pulling from both sources
http://hg.openjdk.java.net/jdk8/tl/jdk/
http://hg.openjdk.java.net/jdk8/jdk8/jdk/
i see that i got two heads.
Is it because in all the other repositorys jdk8/*/jdk there are also
many changes to the jdk-su
Hi guys,
sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the
POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have
changed them to unistd.h and fcntl.h. The patch has been tested on both
linux and aix.
I also change the header file in solaris, though I
On 10/12/2011 02:26 PM, Charles Lee wrote:
Hi guys,
sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to
the POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I
have changed them to unistd.h and fcntl.h. The patch has been tested
on both linux and aix.
I also
On 10/12/2011 03:12 PM, David Holmes wrote:
Hi Charles,
On 12/10/2011 4:26 PM, Charles Lee wrote:
sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the
POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have
changed them to unistd.h and fcntl.h. The patch has
On 10/12/2011 03:36 PM, David Holmes wrote:
On 12/10/2011 5:23 PM, Charles Lee wrote:
On 10/12/2011 03:12 PM, David Holmes wrote:
On 12/10/2011 4:26 PM, Charles Lee wrote:
sys/unistd.h, sys/fcntl.h are not supported in AIX. And according
to the
POSIX.1-2008 (http://pubs.opengroup.org
On 10/12/2011 10:16 PM, Alan Bateman wrote:
David Holmes wrote:
:
We'll need to verify the changes for in the
genUnixConstants code. There tends to be a reason (often historical
and possibly no longer applicable) for using the sys variants (though
sometimes it was just that the non-sys vers
On 10/13/2011 01:11 PM, David Holmes wrote:
Hi Charles,
On 13/10/2011 2:54 PM, Charles Lee wrote:
Thanks Alan. Below is the patch I am failed to attach. It is trivial...
Do you need someone to sponsor this for you, or are you able to drive
this via other IBM folk that can generate webrevs
On 10/20/2011 10:06 PM, Neil Richards wrote:
On Thu, 2011-10-13 at 18:34 +0100, Chris Hegarty wrote:
Neil,
All builds complete with your patches (on top of the latest JDK8 TL
repo) from :
http://cr.openjdk.java.net/~ngmr/ojdk-243.1/webrev.01/
http://cr.openjdk.java.net/~ngmr/ojdk-243.2/
On 10/29/2011 02:13 AM, Seán Coffey wrote:
This is a second stab at cleaning up the close() and finalize()
methods for FileInputStream / FileOutputStream / RandomAccessFile
classes so that all parents/referents sharing the same native
FileDescriptor are closed out correctly.
With Alan's assi
.
regards,
Sean.
On 01/11/2011 13:54, Charles Lee wrote:
On 10/29/2011 02:13 AM, Seán Coffey wrote:
This is a second stab at cleaning up the close() and finalize()
methods for FileInputStream / FileOutputStream / RandomAccessFile
classes so that all parents/referents sharing the same native
On 11/01/2011 11:09 PM, Seán Coffey wrote:
If FileDescriptor is still
/*
* If FileDescriptor is still in use by another stream, the
finalizer
* will not close it.
*/
if ((useCount <= 0) || !isRunningFinalize()) {
close0();
}
Hi S
it.
*/
if ((useCount <= 0) || !isRunningFinalize()) {
close0();
}
regards,
Sean.
On 01/11/2011 14:57, Charles Lee wrote:
Does it change the original mechanism? IIRC, the original will remain
the other FileInputStream function well (can read from the un
On 05/27/2011 03:18 AM, Naoto Sato wrote:
It simply sounds like a bug to me. The behavior should not be different.
Naoto
(5/26/11 12:25 AM), Sean Chou wrote:
Hi all,
I found TextArea's/TextField's enableInputMethods is not working on
linux,
even enableInputMethods(false) is invocated, the
On 12/13/2011 06:50 AM, Darryl Mocek wrote:
Hello. Please review this patch to fix InetAddress.getLocalHost fails
if the host name is larger HOST_NAME_MAX. The fix is to use strncpy,
and supply the max length the host name can be, instead of using
strcpy. There is no test supplied for this f
On 12/13/2011 11:02 AM, David Holmes wrote:
It seems that 7089443 is fixed as a by-product of your changes Charles
- provided getnameinfo does the right thing :)
David
--
On 13/12/2011 12:26 PM, Charles Lee wrote:
On 12/13/2011 06:50 AM, Darryl Mocek wrote:
Hello. Please review this
Hi guys,
I have a small test case[1] and the two invokes of putAll have different
behaviors: the first invocation does not use the override put but the
second invocation does.
The root cause about this can be find in the TreeMap code:
/if (size==0 && mapSize!=0 && map instanceof SortedMap) {
() as that should be part of the implementation note, not
the actual spec. Subclasses should be free to implement putAll in the
most efficient manner possible as TreeMap does.
David
On 2/03/2012 6:17 PM, Charles Lee wrote:
Hi guys,
I have a small test case[1] and the two invokes of putAll have
s not allow for a non-put() based
implementation then TreeMap is in violation of the spec. In which case
TreeMap should not extend AbstractMap.
David
-
On 5/03/2012 1:42 PM, Charles Lee wrote:
Hi David,
I also notice that in the AbstractMap doc, it also says:
"The documentation for e
Hi guys,
Sorry for the late reply.
I agree with David. There are two types of "effect" in my mind:
1. "Associates the specified value with the specified key in this map
(optional operation). If the map previously contained a mapping for the
key, the old value is replaced by the specified value
On 03/21/2012 10:47 AM, Shi Jun Zhang wrote:
On 3/12/2012 11:28 AM, Shi Jun Zhang wrote:
On 3/9/2012 6:05 PM, David Holmes wrote:
On 9/03/2012 7:04 PM, Alan Bateman wrote:
On 09/03/2012 08:01, Shi Jun Zhang wrote:
The situation in NativeThread.c is more complicated than other 2
files. I'm not
Hi guys,
I am trying to push the changeset to the gate, but no matter how I
change the Contributed-by list, I always get:
/searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 2 changes to 2 files
remote: [jcheck a
Hi Sean,
The the patch has been committed @
Changeset: e06ea0dd9207
Author:littlee
Date: 2012-04-10 10:17 +0800
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e06ea0dd9207
7121314: Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec
Reviewed-by: dholmes, mduigou
Con
On 04/11/2012 03:44 PM, Deven You wrote:
On 04/10/2012 04:12 PM, Alan Bateman wrote:
On 09/04/2012 10:32, Deven You wrote:
:
The issue is reported by one of our test team which maintains a set
of ORB test cases.
Okay but I guess I'm still a bit curious as it's not obvious that
rmic (or rmic
On 04/12/2012 04:26 PM, Alan Bateman wrote:
On 12/04/2012 08:22, Deven You wrote:
I have verified this commit. Thanks Alan and Charles!
The change-set that Charles pushed added test/sun/tools/classpath/
RMICClassPathTest.java but I didn't see it in the original webrev. I
see now that your ori
On 04/13/2012 04:45 PM, Alan Bateman wrote:
On 13/04/2012 03:21, Charles Lee wrote:
On 04/12/2012 04:26 PM, Alan Bateman wrote:
On 12/04/2012 08:22, Deven You wrote:
I have verified this commit. Thanks Alan and Charles!
The change-set that Charles pushed added test/sun/tools/classpath
On 04/19/2012 04:05 PM, Sean Chou wrote:
Thanks David and Alan, shall I find some one to commit it ?
On Thu, Apr 19, 2012 at 8:53 AM, David Holmeswrote:
On 19/04/2012 4:05 AM, Alan Bateman wrote:
On 18/04/2012 14:02, David Holmes wrote:
On 18/04/2012 10:23 PM, Sean Chou wrote:
Hi David,
Hi guys,
In the Implementation notes of WeakHashMap[1], says:
/One way to deal with this is to wrap values themselves within
WeakReferences before inserting, as in: m.put(key, new
WeakReference(value)), and then unwrapping upon each get./
However, it is not concise and a little misleading. B
Hi guys,
Does anyone interested in this issue?
On 05/03/2012 02:52 PM, Charles Lee wrote:
Hi guys,
In the Implementation notes of WeakHashMap[1], says:
/One way to deal with this is to wrap values themselves within
WeakReferences before inserting, as in: m.put(key, new
WeakReference(value
Thanks David :-)
On 05/07/2012 11:45 AM, David Holmes wrote:
Hi Charles,
On 7/05/2012 1:05 PM, Charles Lee wrote:
Does anyone interested in this issue?
Interest and time are two different things :)
A shorter form would be:
"If the values in the map do not rely on the map holding s
05/07/2012 11:45 AM, David Holmes wrote:
Hi Charles,
On 7/05/2012 1:05 PM, Charles Lee wrote:
Does anyone interested in this issue?
Interest and time are two different things :)
A shorter form would be:
"If the values in the map do not rely on the map holding strong
references to them,
Thanks David. Do I need another review?
On 06/03/2012 06:15 AM, David Holmes wrote:
Hi Charles,
I have no problem with this clarification in the implementation notes
being added. I've checked with Joe and it does not require CCC approval.
David
-
On 28/05/2012 5:36 PM, Charle
Thanks David. Thanks Mike.
The patch has been committed.
On 06/04/2012 11:33 AM, Mike Duigou wrote:
The change looks good to me.
On Jun 3 2012, at 20:05 , David Holmes wrote:
On 4/06/2012 11:55 AM, Charles Lee wrote:
Thanks David. Do I need another review?
Yes. Someone from TL - Mike or
42 matches
Mail list logo
