Hi all
Could you please review fix for 8049055
Problem:
java/util/logging/TestLoggingWithMainAppContext.java is designed to use
awt,which is in full jre
javax/xml/ws/clientjar/TestWsImport.java tests API that is only in full jre
Tests were running on compacts and failed.
Solution:
Both tests a
On Jul 3, 2014, at 11:08 PM, Stuart Marks wrote:
> On 7/3/14 5:03 AM, Paul Sandoz wrote:
>>
>> On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov wrote:
>>
>>> Paul, would you please include a few more typo fixes, if it's not too late?
>>>
>>
>> Thanks for doing this, the changes look good.
>>
>>
Re-attached lost diff
Also, just for sure, diff as plain text (really small)
diff -r fafb06b35f05 test/TEST.groups
--- a/test/TEST.groupsSun Jun 22 18:50:35 2014 -0400
+++ b/test/TEST.groupsThu Jul 03 16:23:05 2014 +0400
@@ -369,7 +369,9 @@
javax/crypto/Cipher/CipherStreamClose.java \
Hi Evgeniya,
This looks OK for java/util/logging/TestLoggingWithMainAppContext.java,
but by looking at javax/xml/ws/clientjar/TestWsImport.java I get
the impression that this tests depends on the jdk, rather
than on the JRE:
public class TestWsImport {
public static void main(String[] args)
Daniel, you are right. Test fail on jre
Test removed from needs_jre group and added to the needs_jdk one
New diff attached
Thank you!
On 04.07.2014 13:57, Daniel Fuchs wrote:
Hi Evgeniya,
This looks OK for java/util/logging/TestLoggingWithMainAppContext.java,
but by looking at javax/xml/ws/cl
On 7/4/14 12:21 PM, Evgeniya Stepanova wrote:
Daniel, you are right. Test fail on jre
Test removed from needs_jre group and added to the needs_jdk one
New diff attached
Thank you!
The new diff looks good!
-- daniel
On 04.07.2014 13:57, Daniel Fuchs wrote:
Hi Evgeniya,
This looks OK for
On Jul 3, 2014, at 6:33 PM, Alan Bateman wrote:
> On 03/07/2014 09:43, Peter Levart wrote:
>> Hi,
>>
>> I noticed a data race in java.net.URL:
>>
>>https://bugs.openjdk.java.net/browse/JDK-8049220
>>
>> I propose the following simple patch:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-de
On 01/07/2014 10:25, Daniel Fuchs wrote:
Hi Jason, Alan,
Here is an updated version of the fix that does a bounded
retry (retries once - and if it fails, proceeds with the next
name). I have also added NO_FOLLOW_LINKS - for the case where
we try to open an existing Lockfile, and suppressed the
On 7/4/14 6:35 PM, Alan Bateman wrote:
On 01/07/2014 10:25, Daniel Fuchs wrote:
Hi Jason, Alan,
Here is an updated version of the fix that does a bounded
retry (retries once - and if it fails, proceeds with the next
name). I have also added NO_FOLLOW_LINKS - for the case where
we try to open a
Thanks David for looking at the change!
On 04.07.2014 8:14, David Holmes wrote:
Hi Ivan,
I find the change to capacity somewhat obfuscating and I can't see
what the actual bug was.
The bug was in rounding in the expression minCapacity = (3 *
expectedMaxSize)/2.
Suppose, we want the expected
On 04/07/2014 18:25, Daniel Fuchs wrote:
Given that nothing is going to be written to the file then maybe I
don't need APPEND.
I just don't want the call to FileChannel.open() to truncate the file.
APPEND should be harmless here, just not needed.
Also you catch FileNotFoundException (which
On 25/06/2014 21:21, Mandy Chung wrote:
This patch is also intended to target for 8u40 backport. It fixes
the following issues:
JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK
internal API
JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs
JDK-8031092 jd
On 7/4/14 7:58 PM, Alan Bateman wrote:
On 04/07/2014 18:25, Daniel Fuchs wrote:
Given that nothing is going to be written to the file then maybe I
don't need APPEND.
I just don't want the call to FileChannel.open() to truncate the file.
APPEND should be harmless here, just not needed.
Als
On 04/07/2014 19:10, Daniel Fuchs wrote:
hmmm. yes - you're right. I should catch that to and break the loop in
that case.
So that would become:
465 } catch (NoSuchFileException x) {
466 // Race condition - retry once, and if
that
On 07/04/2014 01:33 PM, Ivan Gerasimov wrote:
On 04.07.2014 8:14, David Holmes wrote:
Hi Ivan,
I find the change to capacity somewhat obfuscating and I can't see what the
actual bug was.
The bug was in rounding in the expression minCapacity = (3 * expectedMaxSize)/2.
Suppose, we want the expe
>Here is the updated webrev:
>http://cr.openjdk.java.net/~igerasim/6904367/2/webrev/
There is another bug with the initial implementation:
if put throws, the element is still put (and the size incremented accordingly),
and if putting a new mapping after the throwing one, the table gets full
and
On 4/07/2014 8:21 PM, Evgeniya Stepanova wrote:
Daniel, you are right. Test fail on jre
Yes wsimport is a JDK binary.
Test removed from needs_jre group and added to the needs_jdk one
Looks okay to me.
I'll sponsor this for into jdk9/dev/jdk and then arrange the backport
for 8u.
David
--
Ivan,
Fields like MAXIMUM_CAPACITY are compile-time constants. Their values
are placed directly into the code that uses them - there is no
associated getField to load it. Hence changing the field via reflection
has no affect on any existing code that references the field.
I'm still uncomfort
18 matches
Mail list logo
