Hi Paul, Alan,
I'm back on this change.
On 6/25/2012 12:19 PM, Joe Wang wrote:
On 6/25/2012 9:34 AM, Paul Sandoz wrote:
H Joe,
I just focused on javax.xml.datatype and assumed the rest follows the
same pattern :-)
Yeah, they are mostly similar, except Schema and XPath that do a
little e
- Original Message -
> On 07/27/2012 10:37 AM, Andrew Hughes wrote:
> > - Original Message -
> >> The zip64 support (total_in/out) part probably can be done at Java
> >> level
> >> (ignore
> >> the total_in/out in z_tream_s). Need to remove this dependency.
> >> Will
> >> take a lo
HI David,
I can't comment on the details of the actual expansion logic, nor the
tests.
Akhil and I have gone over this.
Looking at the overall structure I'm still unclear why more of this
isn't just hidden in win32 only files. Why do the new JLI_* methods
have to be JLI methods? I would h
- Original Message -
> Two other obvious candidates are the bundled jpeg and gif libraries.
> Please suggest a patch for build-infra/jdk8!
>
> Backporting the new build system for jdk7/jdk6 is not even on the
> horizon. It
> would be nice though, and probably not impossible.
>
> //Fredrik
Hi Kumar,
I'm always uncomfortable when I see common code that is effectively a
no-op on all but one platform - as it means it isn't really common, we
just factored it that way. But I'm not vehemently opposed. :)
David
On 30/07/2012 10:32 PM, Kumar Srinivasan wrote:
HI David,
I can't comm
Hi David,
Hi Kumar,
I'm always uncomfortable when I see common code that is effectively a
no-op on all but one platform - as it means it isn't really common, we
just factored it that way. But I'm not vehemently opposed. :)
I hear you, but this is the way have managed to eliminate cpp condit
Hi David,
Here are the changes you suggested, removed 2 scopes in
main.c
The delta from last reviewed revision:
http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/webrev.delta/index.html
The full webrev:
http://cr.openjdk.java.net/~ksrini/7146424/webrev.1/index.html
Thanks
Kumar
Hi Kumar,
Hi Kumar,
Don't meant to be difficult but a global int i shared across the two
loops is not what I was suggesting rather that the loop variable be
declared in the loop eg:
114 for (int i = 0 ; i < margc ; i++) {
115 margv[i] = stdargs[i].arg;
116 }
then you can change 117
On 07/29/2012 11:17 PM, David Holmes wrote:
Hi Dan,
On 30/07/2012 2:20 PM, Dan Xu wrote:
Thank you, Alan. I see the change is already pushed into the repository.
I am going to move the bug status to 10-Fix Delivered. But I don't know
what values I need put into "Commit To Fix In Build", "Fixed
Hi David,
Hi Kumar,
Don't meant to be difficult but a global int i shared across the two
loops is not what I was suggesting rather that the loop variable be
declared in the loop eg:
114 for (int i = 0 ; i < margc ; i++) {
115 margv[i] = stdargs[i].arg;
116 }
then you can
Changeset: 38263aa28324
Author:michaelm
Date: 2012-07-30 22:32 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38263aa28324
7120665: Change Java SE spec so that external networking not required
Reviewed-by: alanb
! src/share/classes/java/net/NetworkInterface.java
! src/share/
On 31/07/2012 7:32 AM, Kumar Srinivasan wrote:
Hi David,
Hi Kumar,
Don't meant to be difficult but a global int i shared across the two
loops is not what I was suggesting rather that the loop variable be
declared in the loop eg:
114 for (int i = 0 ; i < margc ; i++) {
115 margv[i] = stdargs[i]
On Jul 30 2012, at 14:43 , David Holmes wrote:
> On 31/07/2012 7:32 AM, Kumar Srinivasan wrote:
>> Hi David,
>>> Hi Kumar,
>>>
>>> Don't meant to be difficult but a global int i shared across the two
>>> loops is not what I was suggesting rather that the loop variable be
>>> declared in the loop
On Jul 30, 2012, at 2:43 PM, David Holmes wrote:
>> Ah!, oh sorry that won't fly this is c code :-( , not c++, MSC does not
>> allow it.
>
> Wow that is unbelievable! for-loop variable declarations are part of C99 :(
Until recently we told the Solaris compilers to not allow any C99 features so
Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev
can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.
The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test
throws ClassCastException due to the Throwable not being of type Error
in TCPTr
Hi all,
In OpenJDK 8, some support has already been added for using the system
installation of zlib
(see the thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html),
which is very similar to the support we've had in IcedTea for the last five
years (wow, has
it really
Hi Darryl,
On 31/07/2012 8:27 AM, Darryl Mocek wrote:
Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev
can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00.
The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test
throws ClassCastException d
totalbytes_Read/Written are being tested though not the size > 4G. That
test mainly tests
the > 64K entries and total size > 4G (lots of > 32-bit offsets...), but
the total bytes read/
written are all < 4G (for each entry). An easy manual test I always do
after run that test is to
jar the resu
On 31/07/2012 00:24, Andrew Hughes wrote:
Ok for the build forest?
Once reviewed then I think jdk8/tl would be better as that's the route
that the changes to the zip code take.
-Alan.
19 matches
Mail list logo
